[whatwg] Why won't you let us make our own HTML5 browsers?

[Fred Andrews]

> From: bhawkeslewis at googlemail.com
> Date: Wed, 29 Aug 2012 08:34:47 +0100
...
> > Javascript is just too general a programming language for easy management and is heading in the direction of Java.
> 
> I'm not sure how far the problem is Javascript, rather than the
> browser and document object models exposed to JS. HTML does now offer
> improved sandboxing (see the sandbox attribute on iframe). But see
> also http://www.adsafe.org/ for some more ideas about sandboxing JS.

Interesting perspective, thanks.

The privacy of a mashup seems easier to solve as it need not 
modify the source document and could just sandbox the source websites 
leaving them unmodified and consuming the content to build a new page to
 present.  Some of the iframe extensions go some way to solving 
the privacy of mashups and I see a path to improving it further.

Access to the DOM does cause a big privacy leakage.  Some popular 
privacy and safety add-ons for Firefox modify the DOM and even place 
their UI within the DOM  making their presence and some of their state 
visible to websites.  For example Ghostery seems to do this and this 
appears to allow a website to detect the add-on and even to see the list
 of blocked sites.  The Ghostery UI should be moved to the Chrome 
context, but some of these add-ons still need to modify the document and 
while these modifications are visible there remains privacy leakage.  Can a 
solution be found to make the operation of these add-ons a 
private matter?

A path to protecting the privacy of webpage modifications that are applied by privacy and safety add-ons is not clear.  I've not been able to think up an approach that can not be subverted.  The solution would seem to require the language to not have the capability to reflect on its own code and to not be able to implement its own language that it can observe, and this would seem to preclude Javascript.

Perhaps this is not a problem that can be solved, and perhaps privacy and safety will need to be addressed in other ways rather than hacking on the document Javascript.  Perhaps reducing the opportunities for fingerprinting and storing state would go some way to limiting unwanted tracking and I am look at ways that iframe extensions could assist this.
 
> > For example a lot could be done with data-flow computations.
> 
> Are you talking about something like the "calculate" property from XForms?

I had declarative data-flow languages in mind.   Something that could handle simple event processing such as drop down menus and calculations for fluid website designs.   This could just be a limited subset of Javascript.  There may be some utility in working out a subset of Javascript that preserves privacy - this could give another option between enabling and disabling JS and some websites could likely work within this, certainly a larger subset than those that work without JS.

> > This could implement equations for layout,
> 
> Layout deficiencies are best addressed by adding CSS features, no?

Yes, but fluid layout could use some calculations and is it likely that declarative calculations would ever be added to CSS?

cheers
Fred