W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2012

RE: PING - please volunteer - Ambient Light Events

From: Fred Andrews <fredandw@live.com>
Date: Wed, 19 Dec 2012 12:22:45 +0000
Message-ID: <BLU002-W182FBD3E0BE99069A75C451AA300@phx.gbl>
To: W3C Public Privacy <public-privacy@w3.org>

If there were a known purpose for using the sensor then it may well be possible to design this without leaking the private ambient light level.  For example, if the light level is needed to adjust the display contrast then a website could include some rules that the UA might choose to follow to adjust the display output levels etc, and this could all be done without being visible to scripts that have a capability to leak this light level.  The proposed design gives unprivileged scripts an API to read and leak the light level.

There is a deeper problem with such approaches - a lack of separation of capabilities.  Some solutions are being explored by the PUA CG, for example 'private contexts' that would have access to such APIs but would not have the capability to leak this state.  A server could send along a script that runs in a 'private context' and handles the ambient light events and uses them to adjust the display colors to suit without leaking this state.

But how to handle content in an iframe?  Can the parent translate the framed contents output colors?  Would this break some of the proposed CSP UI Safety checks?  Is each iframe expected to handle the events and individually adjust its colors?  If so then every third party widget on the page needs to know the ambient light level.   There seems to be lots of issues here that need more thought.

Accepting that the UA can leak the state to a server and pushing the privacy issues back onto server side policy is a poor outcome for the user as the only security they have is their trust in the server.  Perhaps it would help to rename 'privacy by design' to 'private information security by design'.

I think we need to get the security of the current specs. sorted out before guidance can be given to new specs. because the solutions will help guide new work.  We don't even have a framework in which to test the security of private information read from such APIs.  The current answer must be that if scripts can read it then it can be leaked - so such APIs must either be restricted to trusted privileged code or must handle the security themselves by design by making sure that the state is not visible to scripts and does not have any externally detectable effect.


Received on Wednesday, 19 December 2012 12:23:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:23:55 UTC