Re: PING - please volunteer - Ambient Light Events

Not crazy at all: this is just a reflection of the fact that a spec is an attempt to document something in as context-independent a way as possible, and privacy/persona data are highly contextual… ;^'

R

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: wilton@isoc.org
Phone: +44 705 005 2931
Twitter: @futureidentity




On 19 Dec 2012, at 14:06, Joseph Lorenzo Hall wrote:

> 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
> joe@cdt.org
> PGP: https://josephhall.org/gpg-key
> 
> 
>