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

Re: PING - please volunteer - Ambient Light Events

From: Joseph Lorenzo Hall <joe@cdt.org>
Date: Wed, 19 Dec 2012 09:06:58 -0500
Message-ID: <50D1CA02.2030105@cdt.org>
To: Fred Andrews <fredandw@live.com>
CC: W3C Public Privacy <public-privacy@w3.org>
I don't think I'd want to endorse a privacy review that said ambient 
light events (or proximity events) are personal data because either 1) 
we assume there is a much more rich device with lots of personal data 
attached; and/or, 2) because light or proximity events can be leaked to 
other scripts that might have more global scope. It's probably the 
USA'n in me that would better want to qualify in what combinations 
these kinds of signals should implicate privacy concerns.

That being said, I don't know yet how I would want to illustrate that 
and I'm not sure where that guidance/commentary best would lie (I doubt 
specifically in these draft specs).

Am I crazy? best, Joe

On Wed Dec 19 07:22:45 2012, Fred Andrews wrote:
> 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.
> cheers
> Fred

Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
PGP: https://josephhall.org/gpg-key
Received on Wednesday, 19 December 2012 14:07:29 UTC

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