Draft ideas: private and shared JS contexts with different DOM views.

Thank you all for your support, and to the new members.

Some draft ideas are available at: http://www.w3.org/community/pua/wiki/Draft

This document is probably rather incomprehensible but if you have a little time
to look over the ideas then feedback would be appreciated.

There is a W3C TPAC meeting next week and privacy and fingerprinting and the
impact of these on w3c standards are topics on the agenda and I would like to
get a draft of some PUA proposals in as good a shape as possible to help make a
case that UA privacy is not a lost cause.  See:
http://www.w3.org/wiki/TPAC2012/SessionIdeas#Is_user_agent_Fingerprinting_a_lost_cause.3F

One idea is to add support for a JS 'private context' and a JS 'shared context'.

The 'private context' would have access to private UA state, which has not been
defined but I would expect that a lot of information that could fingerprint the user
or that could identify the use of extensions would be defined as private state.
For example, the computed style, window size.  This state would be protected
from leakage by restricting this context from affecting the timing or content of
outgoing requests, or otherwise leaking the state out.

The 'shared context' would have access to interface sthat can affect outgoing
requests, such as XHR, but would not have access to the private state.  This
context would be conceded state, and it would not be expected that a UA could
customize this state without being observed. It is provided to support AJAX content.

One approach to passing state between these contexts is a shared DOM that
has different views from each context.  A shared context would be able to write
to the DOM and the change could be seen in the private context.  A change
made to the DOM from a private context would be flagged as tainted and would
not be seen from the shared context.

One option for using the contexts is for the page top level document to support
a JS shared context, with iframes containing JS private contexts.  This architecture
needs more work and it would be great to have input from an expert in the browser
security architecture, but I'll keep working through it and are studying the Firefox
source code.

Cookies received from a server for a session would not be private state, but
cookies or storage created from a private context would be private state.

I think this architecture could support both rich JS driven UIs and AJAX powered
pages while reducing the risk of leaking a much larger range of UA state.

cheer
Fred