Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home
Paul Frazee [LibreList] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-08 16:01:47 (7 years 28 days 17:31:00 ago)
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
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-09 09:25:35 (7 years 28 days 00:07:00 ago)
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
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-09 10:40:18 (7 years 27 days 22:52:00 ago)
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
Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-10 11:51:10 (7 years 26 days 21:42:00 ago)
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


Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-10 14:51:13 (7 years 26 days 18:42:00 ago)
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

Paul Frazee [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 10:45:08 (7 years 25 days 22:48:00 ago)
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



Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 11:15:55 (7 years 25 days 22:17:00 ago)
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


:
: