RE: system level device information apis in Browser when there is trust relationship - fingerprinting

I wasn't suggesting different APIs.  I meant the APIs to be developed in this WG.  Just to keep in mind when creating APIs that some parts of them may be useful in the browser context if there is a trust relationship, so modularize them so that part can be adopted if they want to adopt it.  That particularly applies to system information APIs that are excluded from DAP (and in this group) only due to fingerprinting concerns.

>-----Original Message-----
>From: Adam Barth [mailto:w3c@adambarth.com]
>Sent: Friday, May 25, 2012 2:49 PM
>To: Carr, Wayne
>Cc: public-sysapps@w3.org
>Subject: Re: system level device information apis in Browser when there is trust
>relationship - fingerprinting
>
>My sense is that we shouldn't focus on these sorts of APIs in this working group,
>at least for the time being.  The sorts of APIs that can be useful in the browse-by
>web are better suited for the Device API or WebApps working groups.  In this
>group, we're more concerned with system-level APIs that aren't appropriate for
>the browse-by web.
>
>Adam
>
>
>On Fri, May 25, 2012 at 1:09 PM, Carr, Wayne <wayne.carr@intel.com> wrote:
>> There are cases in the Browser where the server knows the identity of
>> the user and they have a trusted relationship.  In those cases,
>> fingerprinting concerns do not apply.  An example is a web page where
>> a user interacts with their mobile phone account from their mobile
>> phone.  The server really does know who they are and what device they
>> are using.  It would be OK for JavaScript to know they're connecting over wifi or
>what sensors they have.
>>
>>
>>
>> I would hope that some of these System Level APIs could be adopted in
>> Web Browsers, but be unavailable unless it is for a web page where the
>> user allows it in some way.  Like using Do Not Track or log in where
>> the user agrees that server can know about the device.  Otherwise,
>> we’re preventing capabilities to avoid tracking where there isn’t
>> going to be any tracking or the user wants it.
>>
>>
>>
>> It would be something to consider in APIs -- a variant perhaps in some
>> APIs that would be appropriate for in the browser for use with trusted
>> web sites (but not including apis that erase the disk).  It isn't
>> crucial, because it should be possible to use standalone apps instead
>> (we hope), but may be worth considering.
>>
>>
>>
>> It would be useful to know, for instance, what the level is of WebGL
>> performance to know if you should even try to display something
>> (rather than have the experience where the display is so slow it
>> clearly appears broken).  But that will be blocked due to
>> fingerprinting.  It shouldn't be if the user is logged into some game
>> site where they want the site to pick games appropriate for their
>> hardware and where the site has promised to use information only in ways the
>user has approved.
>>
>>
>>
>> Should something related to this be in the charter?
>>
>>

Received on Friday, 25 May 2012 23:08:04 UTC