- From: Fred Andrews <fredandw@live.com>
- Date: Wed, 24 Oct 2012 07:48:35 +0000
- To: "public-pua@w3.org" <public-pua@w3.org>
- Message-ID: <BLU002-W693F9BA1B56BBF3F809072AA780@phx.gbl>
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
Received on Wednesday, 24 October 2012 07:49:02 UTC