> From: [email protected]
> 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
