librelist archives

« back to archive

Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Paul Frazee
Date:
2014-03-08 @ 22:01
Wrote a post summarizing an interface model I've been researching for the
past two years. In the scheme of redecentralizing, it's part of an
architecture which supports social extension of web applications in order
to provide autonomy from hosting organizations. If anybody has questions on
the approach, feel free to ask; I'll post a few more articles in the near
future.

http://pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html

Be well,
Paul F

Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Jörg F. Wittenberger
Date:
2014-03-09 @ 09:40
Am 08.03.2014 23:01, schrieb Paul Frazee:
> Wrote a post summarizing an interface model I've been researching for 
> the past two years. In the scheme of redecentralizing, it's part of an 
> architecture which supports social extension of web applications in 
> order to provide autonomy from hosting organizations.

That "autonomy" piece caught my interest.  After all, it's what 
askemos.org is about.

> If anybody has questions on the approach, feel free to ask; I'll post 
> a few more articles in the near future.
>
> http://pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html

After reading I can see that this is pretty much in line with the model 
proposed under the name Askemos.  From a practical point of view it also 
looks much like the way we program our agents.

However I'm left with one question: how does this relates to autonomy 
from hosting organizations?

Towards this end we require active replication of the "server" end, such 
that any peer may fail (with malice) any time harming at most itself.

Best

/Jörg

Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Paul Frazee
Date:
2014-03-09 @ 14:25
Yes, they are similar. To answer, I'll first mention that two additional 
posts were uploaded that explain more of the architecture:

"In-Application Sandboxing with Web Workers" 
http://pfraze.github.io/2014/03/08/in-application-sandboxing-with-web-workers.html
"Communicating with Web Workers using HTTP" 
http://pfraze.github.io/2014/03/08/communicating-with-web-workers-using-http.html

Askemos appears to solve trust in distributed application-state, correct? 
I'll need to read more deeply.

The trust question I'm investigating is application-integrity during 
third-party extension. Autonomy means, in this case, freedom to introduce 
new software without the host's blessing, like how an OS protects its 
kernel so that 3rd party code can execute without auditing by the OS 
vendor. Like an OS, the effectiveness will then rely on a well-designed 
permissions model.

Regarding shared state, the client/server model is continued, and so 
server nodes still maintain state authority, but the user may change which
servers are used. Likewise, the permission model is still origin-based, 
but it treats all components of the app (page, remote hosts, worker 
plugins) as part of the network, and so origin is more granular. Servers 
may apply clustering algorithms to share state authority, and so (I 
suspect) Askemos' protocols should be applicable to them. Servers remain a
network primitive for more complex topologies.

Another notable aspect of trust is data-containment, which Workers solve 
by executing in the user's environment, with all APIs removed but for 
postMessage (no xhr). This excites me for applications like Mint.com, 
which really needs proper isolation to function ethically.

I'm having trouble loading some of Askemos' docs, but I look forward to 
digging in a bit. Ping me in #stackvm on freenode (pfraze) sometime.

Be well,
Paul F

> On Mar 9, 2014, at 4:40 AM, "Jörg F. Wittenberger" 
<Joerg.Wittenberger@softeyes.net> wrote:
> 
> Am 08.03.2014 23:01, schrieb Paul Frazee:
>> Wrote a post summarizing an interface model I've been researching for 
>> the past two years. In the scheme of redecentralizing, it's part of an 
>> architecture which supports social extension of web applications in 
>> order to provide autonomy from hosting organizations.
> 
> That "autonomy" piece caught my interest.  After all, it's what 
> askemos.org is about.
> 
>> If anybody has questions on the approach, feel free to ask; I'll post 
>> a few more articles in the near future.
>> 
>> http://pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html
> 
> After reading I can see that this is pretty much in line with the model 
> proposed under the name Askemos.  From a practical point of view it also 
> looks much like the way we program our agents.
> 
> However I'm left with one question: how does this relates to autonomy 
> from hosting organizations?
> 
> Towards this end we require active replication of the "server" end, such 
> that any peer may fail (with malice) any time harming at most itself.
> 
> Best
> 
> /Jörg

Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Jörg F. Wittenberger
Date:
2014-03-10 @ 13:51
Am 09.03.2014 15:25, schrieb Paul Frazee:

<metatalk>I originally intended to reply to Paul's posting in private 
mail, just accidentally hit the wrong button. By now I could imagine 
that other members of the list might actually like to follow or at least 
know that they don't miss a related discussion.  So I keep posting via 
the list. Those who are annoyed: please let us know.</metatalk>

> Yes, they are similar. To answer, I'll first mention that two additional
posts were uploaded that explain more of the architecture:
>
> "In-Application Sandboxing with Web Workers" 
http://pfraze.github.io/2014/03/08/in-application-sandboxing-with-web-workers.html
> "Communicating with Web Workers using HTTP" 
http://pfraze.github.io/2014/03/08/communicating-with-web-workers-using-http.html

Thanks for these.  It still looks related.  Though I feel I'm missing 
something basic.  Like a super-simplified paragraph of the over-all idea.

> Askemos appears to solve trust in distributed application-state, 
correct? I'll need to read more deeply.

I'm not a native English speaker. Notably here I'm inclined to say 
"yes", but then in turn I might have gotten your sentence the wrong way 
around.  I rather explain:

Assumptions:

A) There is no trust in any remote machine and at most temporary trust 
in local machines. (If self-owned and self-administrated - however 
eventually left to the users judgment.)

B) From (A) we conclude: there is no trust in any (remote) servers state.

Goal: trustworthy applications, hence some application state we can 
reasonably assume/agree to be correct.

Method: stolen from (modeled after) the legal system: don't aim for 
absolute truth.  Rely on judgment and witness.

So Askemos is somewhat like the web with the servers removed.  (And not 
restricted to Web, though that's the easiest model to explain it).  
Instead of those servers, caches cooperate.  A group of "cache" nodes 
execute what traditional web apps do at the server. However updates are 
coordinated among those nodes assigned to the app: they are only 
executed if the majority of assigned nodes agrees.  That is all those 
nodes always audit each other.

In this setting we are no longer forced to trust any single machine or 
operator.  Malicious or not: malfunction is spotted and handled 
(ignored). (At least while there are less than 1/3 bad nodes.)

Hence I'm inclined to say "Askemos solves trust BY distributing 
application state".  Especially by distributing it to parties having a 
stake in either a) correct results b) conflicting interests iff they 
where trying to play foul.


In an ideal world, we would integrate some Askemos-compliant cache code 
right into the users browser.  In practice we run a process for the user 
close to the browser, typically at the same machine.


Autonomy in this case mean: applications are autonomous from any party's 
dissenting interest. (Only majority dissent will stop them.)

Since we guarantee (by a simple, yet clever rule how permissions might 
be assigned) that no person can impersonate any other,


> The trust question I'm investigating is application-integrity during 
third-party extension. Autonomy means, in this case, freedom to introduce 
new software without the host's blessing, like how an OS protects its 
kernel so that 3rd party code can execute without auditing by the OS 
vendor. Like an OS, the effectiveness will then rely on a well-designed 
permissions model.

I see.  This is basically the same question we had to solve when looking 
into "how do those nodes run application code?".

Askemos - being only the protocol level - just goes so far to say: (a) 
an app might have local state, the implementation is responsible to 
apply updates requested by the application (after having run the 
agreement protocol) and (b) no app shall be able modify other app's 
state or even it's own state bypassing the agreement step.

Insofar your sandboxing text reads very related to our implementation.  
Obviously.

Ah, yeah: applications in Askemos can communicate with each other. By 
passing asynchronous messages. The implementation makes sure that in - 
case the group of nodes maintaining the receiving application is not the 
same as the group of the sending app - messages are transparently  
forwarded to all nodes commissioned to run the receiving app.

> Regarding shared state, the client/server model is continued, and so 
server nodes still maintain state authority, but the user may change which
servers are used.

Hm.  This seems like "almost identical".  Correct?  Except that I've got 
the impression that your "server switch" would wholesale switch from one 
server to another.  While Askemos lets you add/remove peers from the 
list supporting any particular application.

So there would be a special case in Askemos, which would match your 
model: having an application running at peer X initially, then add peer 
Y and then drop peer X.  Thus effectively always have only one peer run 
the app at the same time, though a different one after the move.  Correct?

(BTW: that special case is really not how you would like to run our apps 
in general.  Instead you would normally have at least four [better seven 
to ten] peers assigned to run an app.)

> Likewise, the permission model is still origin-based, but it treats all 
components of the app (page, remote hosts, worker plugins) as part of the 
network, and so origin is more granular.

I see.  That's about the point where app development became kinda 
confusing in our context.  After all the server is virtually there even 
though physically not.

(Another - related - confusion might be interesting to readers looking 
at it from a legal background: in such a network new objects are created 
at all nodes running the creating application at the same time and 
independently.  Hence there is no such relationship like original vs. 
copy of the object.  That's interesting to look at when it comes to 
copyright.  After all the all-so-crucial act of copying never happened, 
still there are multiple copies...)

> Servers may apply clustering algorithms to share state authority, and so
(I suspect) Askemos' protocols should be applicable to them. Servers 
remain a network primitive for more complex topologies.

Looks still more interesting.

> Another notable aspect of trust is data-containment, which Workers solve
by executing in the user's environment, with all APIs removed but for 
postMessage (no xhr).

Exactly the same with Askemos.

> This excites me for applications like Mint.com, which really needs 
proper isolation to function ethically.

Great!  I did not know about mint.com

However

a) this functioning ethically is exactly why we did Askemos in the first 
place

b) What I'm seeing in the first five minutes from the mint.com web 
pages, that's about an application as we had it in mind when we started.

So maybe our experiences (and code?) might be for you.

Where is the users data kept in the case of mint.com?  At (one or more 
of) the users computer(s) or at mint.com's machines?

> I'm having trouble loading some of Askemos' docs,

Please send details to me off-list.  I'll shall investigate.

Right now let me tell you: there are some old docs still linked, which 
we would like to drop since we broke the underlying implementation 
during development harming some objects to the extend that we can't 
modify them anymore.  Dev time...

Furthermore we're running the askemos.org and other web sites from our 
own software and test network.  That is we actually test that we can run 
it from cheap peers behind consumer grade ADSL lines at home.  Most 
nodes are plug computers, some are behind apache-vhosts we don't control 
directly.  At least those tonido-plugs have a bug which requires them to 
be rebooted to be fixed.  Etc. etc.  so we know: at any time there might 
be nodes registered with the DNS, which are not functioning anymore.  
Depending on you clinet (browser) this might be a problem.

Best

/Jörg

>   but I look forward to digging in a bit. Ping me in #stackvm on 
freenode (pfraze) sometime.
>
> Be well,
> Paul F
>
>> On Mar 9, 2014, at 4:40 AM, "Jörg F. Wittenberger" 
<Joerg.Wittenberger@softeyes.net> wrote:
>>
>> Am 08.03.2014 23:01, schrieb Paul Frazee:
>>> Wrote a post summarizing an interface model I've been researching for
>>> the past two years. In the scheme of redecentralizing, it's part of an
>>> architecture which supports social extension of web applications in
>>> order to provide autonomy from hosting organizations.
>> That "autonomy" piece caught my interest.  After all, it's what
>> askemos.org is about.
>>
>>> If anybody has questions on the approach, feel free to ask; I'll post
>>> a few more articles in the near future.
>>>
>>> http://pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html
>> After reading I can see that this is pretty much in line with the model
>> proposed under the name Askemos.  From a practical point of view it also
>> looks much like the way we program our agents.
>>
>> However I'm left with one question: how does this relates to autonomy
>> from hosting organizations?
>>
>> Towards this end we require active replication of the "server" end, such
>> that any peer may fail (with malice) any time harming at most itself.
>>
>> Best
>>
>> /Jörg

Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Paul Frazee
Date:
2014-03-10 @ 16:51
Askemos docs are working for me again - it may have been my wifi at fault,
so I wouldn't worry about it.

Reading your response and reading Askemos' docs, I'm inclined to say our
projects solve fairly different problems. Let me step through the Mint.com
example to hopefully clarify the differences.

Mint's application is hosted by remote servers which proxy to your bank's
host servers. The details may have changed by now but, at one point, they
asked for your username and password, then crawled your bank interface with
an HTML-scraper. The issue with this system is, of course,
data-containment: you give up your financial information to Mint in order
to power the app.

In the runtime-extension architecture I'm suggesting, the banking site
(let's say Citibank) behaves like a miniature OS. When a user goes to
citibank.com, they'd use an in-site UI to load Mint.com's application into
a Web Worker. Now contained on the client-side, Mint would be given
readonly access to the financial information, and read/write access to a
section of the DOM for rendering its UI, and no other privileges. This
solves the data-containment issue.

The User-Agent behaviors and HTTP messaging handle the question of IPC
between the Citibank page and the Mint worker. Typed links are used to
export/discover the interfaces between those two threads.

I don't attempt to solve the need to trust Citibank's remote service, but I
do offer a way to extend Citibank's software at runtime without
compromising its integrity. Mint, in this case, is one such extension ("now
with more graphs!"). What Web applications choose to make alterable is at
their discretion, but, because integrity of the host page is always
preserved, and because typed links can be used to do behavior- and
security-reasoning, it should be safe for users to share extensions with
each other (like they share pages now). Users, therefore, have the autonomy
to develop and personalize Web applications without belonging to the host
organization. Following our example, you don't have to be a Citibank dev to
dev Citibank.

I'd need to research it more deeply, but I suspect that Askemos' protocols
could be implemented in this extensions-architecture as a set of reltypes.
It might be used to cluster multiple Worker scripts and remote services
which all implement the same reltypes, but which are all written by
different authors, in order to compare the integrity of their output. Does
that sound correct?

Be well,
Paul F

On Mon, Mar 10, 2014 at 8:51 AM, Jörg F. Wittenberger <
Joerg.Wittenberger@softeyes.net> wrote:

> Am 09.03.2014 15:25, schrieb Paul Frazee:
>
> <metatalk>I originally intended to reply to Paul's posting in private
> mail, just accidentally hit the wrong button. By now I could imagine
> that other members of the list might actually like to follow or at least
> know that they don't miss a related discussion.  So I keep posting via
> the list. Those who are annoyed: please let us know.</metatalk>
>
> > Yes, they are similar. To answer, I'll first mention that two additional
> posts were uploaded that explain more of the architecture:
> >
> > "In-Application Sandboxing with Web Workers"
> 
http://pfraze.github.io/2014/03/08/in-application-sandboxing-with-web-workers.html
> > "Communicating with Web Workers using HTTP"
> 
http://pfraze.github.io/2014/03/08/communicating-with-web-workers-using-http.html
>
> Thanks for these.  It still looks related.  Though I feel I'm missing
> something basic.  Like a super-simplified paragraph of the over-all idea.
>
> > Askemos appears to solve trust in distributed application-state,
> correct? I'll need to read more deeply.
>
> I'm not a native English speaker. Notably here I'm inclined to say
> "yes", but then in turn I might have gotten your sentence the wrong way
> around.  I rather explain:
>
> Assumptions:
>
> A) There is no trust in any remote machine and at most temporary trust
> in local machines. (If self-owned and self-administrated - however
> eventually left to the users judgment.)
>
> B) From (A) we conclude: there is no trust in any (remote) servers state.
>
> Goal: trustworthy applications, hence some application state we can
> reasonably assume/agree to be correct.
>
> Method: stolen from (modeled after) the legal system: don't aim for
> absolute truth.  Rely on judgment and witness.
>
> So Askemos is somewhat like the web with the servers removed.  (And not
> restricted to Web, though that's the easiest model to explain it).
> Instead of those servers, caches cooperate.  A group of "cache" nodes
> execute what traditional web apps do at the server. However updates are
> coordinated among those nodes assigned to the app: they are only
> executed if the majority of assigned nodes agrees.  That is all those
> nodes always audit each other.
>
> In this setting we are no longer forced to trust any single machine or
> operator.  Malicious or not: malfunction is spotted and handled
> (ignored). (At least while there are less than 1/3 bad nodes.)
>
> Hence I'm inclined to say "Askemos solves trust BY distributing
> application state".  Especially by distributing it to parties having a
> stake in either a) correct results b) conflicting interests iff they
> where trying to play foul.
>
>
> In an ideal world, we would integrate some Askemos-compliant cache code
> right into the users browser.  In practice we run a process for the user
> close to the browser, typically at the same machine.
>
>
> Autonomy in this case mean: applications are autonomous from any party's
> dissenting interest. (Only majority dissent will stop them.)
>
> Since we guarantee (by a simple, yet clever rule how permissions might
> be assigned) that no person can impersonate any other,
>
>
> > The trust question I'm investigating is application-integrity during
> third-party extension. Autonomy means, in this case, freedom to introduce
> new software without the host's blessing, like how an OS protects its
> kernel so that 3rd party code can execute without auditing by the OS
> vendor. Like an OS, the effectiveness will then rely on a well-designed
> permissions model.
>
> I see.  This is basically the same question we had to solve when looking
> into "how do those nodes run application code?".
>
> Askemos - being only the protocol level - just goes so far to say: (a)
> an app might have local state, the implementation is responsible to
> apply updates requested by the application (after having run the
> agreement protocol) and (b) no app shall be able modify other app's
> state or even it's own state bypassing the agreement step.
>
> Insofar your sandboxing text reads very related to our implementation.
> Obviously.
>
> Ah, yeah: applications in Askemos can communicate with each other. By
> passing asynchronous messages. The implementation makes sure that in -
> case the group of nodes maintaining the receiving application is not the
> same as the group of the sending app - messages are transparently
> forwarded to all nodes commissioned to run the receiving app.
>
> > Regarding shared state, the client/server model is continued, and so
> server nodes still maintain state authority, but the user may change which
> servers are used.
>
> Hm.  This seems like "almost identical".  Correct?  Except that I've got
> the impression that your "server switch" would wholesale switch from one
> server to another.  While Askemos lets you add/remove peers from the
> list supporting any particular application.
>
> So there would be a special case in Askemos, which would match your
> model: having an application running at peer X initially, then add peer
> Y and then drop peer X.  Thus effectively always have only one peer run
> the app at the same time, though a different one after the move.  Correct?
>
> (BTW: that special case is really not how you would like to run our apps
> in general.  Instead you would normally have at least four [better seven
> to ten] peers assigned to run an app.)
>
> > Likewise, the permission model is still origin-based, but it treats all
> components of the app (page, remote hosts, worker plugins) as part of the
> network, and so origin is more granular.
>
> I see.  That's about the point where app development became kinda
> confusing in our context.  After all the server is virtually there even
> though physically not.
>
> (Another - related - confusion might be interesting to readers looking
> at it from a legal background: in such a network new objects are created
> at all nodes running the creating application at the same time and
> independently.  Hence there is no such relationship like original vs.
> copy of the object.  That's interesting to look at when it comes to
> copyright.  After all the all-so-crucial act of copying never happened,
> still there are multiple copies...)
>
> > Servers may apply clustering algorithms to share state authority, and so
> (I suspect) Askemos' protocols should be applicable to them. Servers remain
> a network primitive for more complex topologies.
>
> Looks still more interesting.
>
> > Another notable aspect of trust is data-containment, which Workers solve
> by executing in the user's environment, with all APIs removed but for
> postMessage (no xhr).
>
> Exactly the same with Askemos.
>
> > This excites me for applications like Mint.com, which really needs
> proper isolation to function ethically.
>
> Great!  I did not know about mint.com
>
> However
>
> a) this functioning ethically is exactly why we did Askemos in the first
> place
>
> b) What I'm seeing in the first five minutes from the mint.com web
> pages, that's about an application as we had it in mind when we started.
>
> So maybe our experiences (and code?) might be for you.
>
> Where is the users data kept in the case of mint.com?  At (one or more
> of) the users computer(s) or at mint.com's machines?
>
> > I'm having trouble loading some of Askemos' docs,
>
> Please send details to me off-list.  I'll shall investigate.
>
> Right now let me tell you: there are some old docs still linked, which
> we would like to drop since we broke the underlying implementation
> during development harming some objects to the extend that we can't
> modify them anymore.  Dev time...
>
> Furthermore we're running the askemos.org and other web sites from our
> own software and test network.  That is we actually test that we can run
> it from cheap peers behind consumer grade ADSL lines at home.  Most
> nodes are plug computers, some are behind apache-vhosts we don't control
> directly.  At least those tonido-plugs have a bug which requires them to
> be rebooted to be fixed.  Etc. etc.  so we know: at any time there might
> be nodes registered with the DNS, which are not functioning anymore.
> Depending on you clinet (browser) this might be a problem.
>
> Best
>
> /Jörg
>
> >   but I look forward to digging in a bit. Ping me in #stackvm on
> freenode (pfraze) sometime.
> >
> > Be well,
> > Paul F
> >
> >> On Mar 9, 2014, at 4:40 AM, "Jörg F. Wittenberger" <
> Joerg.Wittenberger@softeyes.net> wrote:
> >>
> >> Am 08.03.2014 23:01, schrieb Paul Frazee:
> >>> Wrote a post summarizing an interface model I've been researching for
> >>> the past two years. In the scheme of redecentralizing, it's part of an
> >>> architecture which supports social extension of web applications in
> >>> order to provide autonomy from hosting organizations.
> >> That "autonomy" piece caught my interest.  After all, it's what
> >> askemos.org is about.
> >>
> >>> If anybody has questions on the approach, feel free to ask; I'll post
> >>> a few more articles in the near future.
> >>>
> >>> http://pfraze.github.io/2014/03/08/applying-user-agent-behaviors.html
> >> After reading I can see that this is pretty much in line with the model
> >> proposed under the name Askemos.  From a practical point of view it also
> >> looks much like the way we program our agents.
> >>
> >> However I'm left with one question: how does this relates to autonomy
> >> from hosting organizations?
> >>
> >> Towards this end we require active replication of the "server" end, such
> >> that any peer may fail (with malice) any time harming at most itself.
> >>
> >> Best
> >>
> >> /Jörg
>
>

Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Jörg F. Wittenberger
Date:
2014-03-11 @ 10:15
Am 10.03.2014 17:51, schrieb Paul Frazee:
> Reading your response and reading Askemos' docs, I'm inclined to say 
> our projects solve fairly different problems. Let me step through the 
> Mint.com example to hopefully clarify the differences.

Reading your message I'd agree.  Looks like our projects solve kinda 
complementary problems, which makes us deal with similar issues. Just 
you're concerned with them at the client/browser side of the game, while 
we were looking at the service side (avoiding to say "server" here since 
it's yet another client/peer).

> Mint's application is hosted by remote servers which proxy to your 
> bank's host servers. The details may have changed by now but, at one 
> point, they asked for your username and password, then crawled your 
> bank interface with an HTML-scraper. The issue with this system is, of 
> course, data-containment: you give up your financial information to 
> Mint in order to power the app.

I see.  That's something we'd never suggest.  Instead we'd move the part 
of the app dealing with the users personal data to a peer the user owns 
and controls.  - Though I dunno how much room that would leave for the 
business model mint.com conducts.

> In the runtime-extension architecture I'm suggesting, the banking site 
> (let's say Citibank) behaves like a miniature OS. When a user goes to 
> citibank.com <http://citibank.com>, they'd use an in-site UI to load 
> Mint.com's application into a Web Worker. Now contained on the 
> client-side, Mint would be given readonly access to the financial 
> information, and read/write access to a section of the DOM for 
> rendering its UI, and no other privileges. This solves the 
> data-containment issue.

This really clarified things to me.  Thanks.  It's a nice example to 
show where our approaches take a different route to the same result.  
(While using the same "miniature OS" analogy.)

With Askemos the roles would be reversed.  As I understand your words, 
citibank would have to prepare their website with some kind of 
"extension area" where mint.com is going to be embedded.  Though the 
embedding itself is done under control of the user at the client side, 
correct?

With Askemos we'd have two alternatives:

A) citibank too could be an application run in byzantine fault 
tolerance.  (This had pros and cons: four or more banks would have to 
cooperate to run citibank.com - would make it much harder to break into 
an tamper with the data; but also those banks would have to share 
information about users balances, which they might not want to.)  This 
case could be arranged to run the users account at the users peer too.

B) citibank.com could be just a single entity reachable via HTTPS as it 
is the normal case these days.

In case (A) mint and citibank would be equivalent wrt. the question 
which one embeds the other.  In case (B) it would always be mint.com 
doing the embedding.

The embedding itself however would not require any support from the 
embedded side.  Assuming (B), mint.com would read citibank's data/HTML 
and rearrange it.  However that would happen before the resulting HTML 
is feed into the browser for display/interaction.

> The User-Agent behaviors and HTTP messaging handle the question of IPC 
> between the Citibank page and the Mint worker. Typed links are used to 
> export/discover the interfaces between those two threads.
>
> I don't attempt to solve the need to trust Citibank's remote service, 
> but I do offer a way to extend Citibank's software at runtime without 
> compromising its integrity. Mint, in this case, is one such extension 
> ("now with more graphs!"). What Web applications choose to make 
> alterable is at their discretion, but, because integrity of the host 
> page is always preserved, and because typed links can be used to do 
> behavior- and security-reasoning, it should be safe for users to share 
> extensions with each other (like they share pages now). Users, 
> therefore, have the autonomy to develop and personalize Web 
> applications without belonging to the host organization. Following our 
> example, you don't have to be a Citibank dev to dev Citibank.
>
> I'd need to research it more deeply, but I suspect that Askemos' 
> protocols could be implemented in this extensions-architecture as a 
> set of reltypes. It might be used to cluster multiple Worker scripts 
> and remote services which all implement the same reltypes, but which 
> are all written by different authors, in order to compare the 
> integrity of their output. Does that sound correct?

That sounds correct.

Though to be sure I'd have to understand your "reltypes" better.

Plus: there has to be a way for those worker scripts to talk to each 
other while running at different peers/browsers.  Would this be 
supported?  Right now I'm not sure how I would do this among web pages.

/Jörg

Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension

From:
Paul Frazee
Date:
2014-03-11 @ 15:45
>
> As I understand your words, citibank would have to prepare their website
> with some kind of "extension area" where mint.com is going to be
> embedded.  Though the embedding itself is done under control of the user at
> the client side, correct?


Yes, that's correct. For the sake of brevity, I'll respond to Askemos' A)
and B) alternatives by saying, they make sense, and so long as the
integrity of each component is maintained (which I expect is what Askemos
uses VMs to ensure) then it's a similar approach. The client uses a trust
hierarchy, in which the Page is most-privileged, and all Workers are given
least-possible privilege. Deciding which participant is the Page is mainly
a question of who should be trusted with the information. In the
Citibank/Mint example, you'd never want Mint to be the Page, but you could
potentially have a 3rd participant supply the Page (perhaps a
general-purpose banking program) which runs Citibank and Mint as workers.

Regarding reltypes, they are much like the types in a programming language,
but they are designed to coordinate IPC. They don't use any formal
description language to provide analysis by an IDE, and that's currently
viewed as an advantage (IDLs have never been very successful on the Web).
Instead, reltypes indicate an informal (but complete!) specification which
is published online, and which acts like a contract between two nodes. A
consumer of a Web service (a User Agent) then fetches links, queries the
links by looking for reltypes that it understands, and then begins
communicating with the endpoints of those links according to their reltype
specs.

By publishing Askemos' protocols as reltypes, you standardize the
protocols. For a simple example, if Askemos used a "heartbeat" protocol in
which ping messages need to be exchanged regularly, you'd write a spec for
the client and the server and upload it at, say, askemos.org/rel/heartbeat.
A server which follows the protocol would link to itself with `rel="
askemos.org/rel/heartbeat"`. A client which uses heart-beating servers
would seek out that link, then (for instance, if this were the protocol:)
subscribe to Server-Sent Events stream in order to receive the pings. The
client can assume that subscription will work, otherwise the server is
mis-implemented and should be avoided.

For communicating between peers and browsers, there's WebRTC, which acts as
an HTTPL channel just like the Workers' postMessage channel.


On Tue, Mar 11, 2014 at 5:15 AM, Jörg F. Wittenberger <
Joerg.Wittenberger@softeyes.net> wrote:

>  Am 10.03.2014 17:51, schrieb Paul Frazee:
>
> Reading your response and reading Askemos' docs, I'm inclined to say our
> projects solve fairly different problems. Let me step through the Mint.com
> example to hopefully clarify the differences.
>
>
> Reading your message I'd agree.  Looks like our projects solve kinda
> complementary problems, which makes us deal with similar issues.  Just
> you're concerned with them at the client/browser side of the game, while we
> were looking at the service side (avoiding to say "server" here since it's
> yet another client/peer).
>
>
>  Mint's application is hosted by remote servers which proxy to your
> bank's host servers. The details may have changed by now but, at one point,
> they asked for your username and password, then crawled your bank interface
> with an HTML-scraper. The issue with this system is, of course,
> data-containment: you give up your financial information to Mint in order
> to power the app.
>
>
> I see.  That's something we'd never suggest.  Instead we'd move the part
> of the app dealing with the users personal data to a peer the user owns and
> controls.  - Though I dunno how much room that would leave for the business
> model mint.com conducts.
>
>
>  In the runtime-extension architecture I'm suggesting, the banking site
> (let's say Citibank) behaves like a miniature OS. When a user goes to
> citibank.com, they'd use an in-site UI to load Mint.com's application
> into a Web Worker. Now contained on the client-side, Mint would be given
> readonly access to the financial information, and read/write access to a
> section of the DOM for rendering its UI, and no other privileges. This
> solves the data-containment issue.
>
>
> This really clarified things to me.  Thanks.  It's a nice example to show
> where our approaches take a different route to the same result.  (While
> using the same "miniature OS" analogy.)
>
> With Askemos the roles would be reversed.  As I understand your words,
> citibank would have to prepare their website with some kind of "extension
> area" where mint.com is going to be embedded.  Though the embedding
> itself is done under control of the user at the client side, correct?
>
> With Askemos we'd have two alternatives:
>
> A) citibank too could be an application run in byzantine fault tolerance.
> (This had pros and cons: four or more banks would have to cooperate to run
> citibank.com - would make it much harder to break into an tamper with the
> data; but also those banks would have to share information about users
> balances, which they might not want to.)  This case could be arranged to
> run the users account at the users peer too.
>
> B) citibank.com could be just a single entity reachable via HTTPS as it
> is the normal case these days.
>
> In case (A) mint and citibank would be equivalent wrt. the question which
> one embeds the other.  In case (B) it would always be mint.com doing the
> embedding.
>
> The embedding itself however would not require any support from the
> embedded side.  Assuming (B), mint.com would read citibank's data/HTML
> and rearrange it.  However that would happen before the resulting HTML is
> feed into the browser for display/interaction.
>
>
>  The User-Agent behaviors and HTTP messaging handle the question of IPC
> between the Citibank page and the Mint worker. Typed links are used to
> export/discover the interfaces between those two threads.
>
>  I don't attempt to solve the need to trust Citibank's remote service,
> but I do offer a way to extend Citibank's software at runtime without
> compromising its integrity. Mint, in this case, is one such extension ("now
> with more graphs!"). What Web applications choose to make alterable is at
> their discretion, but, because integrity of the host page is always
> preserved, and because typed links can be used to do behavior- and
> security-reasoning, it should be safe for users to share extensions with
> each other (like they share pages now). Users, therefore, have the autonomy
> to develop and personalize Web applications without belonging to the host
> organization. Following our example, you don't have to be a Citibank dev to
> dev Citibank.
>
>  I'd need to research it more deeply, but I suspect that Askemos'
> protocols could be implemented in this extensions-architecture as a set of
> reltypes. It might be used to cluster multiple Worker scripts and remote
> services which all implement the same reltypes, but which are all written
> by different authors, in order to compare the integrity of their output.
> Does that sound correct?
>
>
> That sounds correct.
>
> Though to be sure I'd have to understand your "reltypes" better.
>
> Plus: there has to be a way for those worker scripts to talk to each other
> while running at different peers/browsers.  Would this be supported?  Right
> now I'm not sure how I would do this among web pages.
>
> /Jörg
>
>
>