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.


Jörg F. Wittenberger [LibreList] Re: [redecentralize] Applying User-Agent Behaviors in Web Applications to Enable Runtime Extension 2014-03-11 11:15:55 (6 years 11 mons 24 days 03:04: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.