W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] Proposal: navigator.cores

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 5 May 2014 18:31:27 +0000 (UTC)
To: Rik Cabanier <cabanier@gmail.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Adam Barth <w3c@adambarth.com>, Eli Grey <me@eligrey.com>, David Young <dyoung@pobox.com>
Message-ID: <alpine.DEB.2.00.1405051814360.11724@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org, Tobie Langel <tobie.langel@gmail.com>
On Sun, 4 May 2014, Rik Cabanier wrote:
> >
> > Right. You have to install the application. At that point, game over.
> 
> No, you misunderstood.
> The admin install the application and has all privileges.

And in doing so, grants the application permission to fingerprint the 
user in various ways, e.g., counting cores.


> A guest user with the most limited set of privileges can still call this
> API since it is considered so low risk. (This is likely also why Chrome can
> use it since it's process run in a very restricted sandbox.)

Sure. But by this point, someone has already granted the app the privilege 
to do what I'm saying we do _not_ want to grant to Web apps, since merely 
visiting a URL is not a privilege-granting step on par with installing an 
application.


On Mon, 5 May 2014, Adam Barth wrote:
> 
> I feel a bit like I'm repeating myself, but I'll try to present my two 
> arguments again concisely:

I don't think anyone misunderstands your arguments.


> 1) There is no privacy issue today.

I disagree with this statement. There is a privacy issue today: we are 
exposing too many fingerprinting bits.


> The only privacy concern people have raise is in regards to 
> fingerprinting.

Yes.


> Today, fingerprinting is already possible with a high degree of accuracy 
> regardless of navigator.cores.

Yes. We should make this better, not worse.


> The fingerprinting concern with navigator.cores only degrades privacy in 
> a hypothetical future world in which we're removed all the existing 
> fingerprinting vectors in the platform.

Well technically it would degrade it today as well, just not much, 
relatively speaking.

But yes. I hold out hope that we are still headed to that future.


> I don't believe we'll ever live in that world, and I'm no longer willing 
> to withhold useful tools from developer to keep that dream alive.

That is your prerogative. I'm not responsible for what you implement.

Personally, I think we should be trying to live in that world. I have made 
efforts to highlight APIs that are problematic in the HTML spec, and I've 
tried to put in allowances in the spec for browsers to reduce 
fingerprinting bits. For example, browsers, per spec, are encouraged to 
not provide information in navigator.appName and navigator.appVersion.


> 2) In 2009, as well as today, you've argued that we should hold out for 
> a better solution.  I agree that we should provide developers with a 
> better solution (e.g., something analogous to Grand Central Dispatch).  
> However, I also believe we should provide developers with a worse 
> solution [1], and I'm sad that we didn't do that in 2009.  If we had 
> provided developers with a worse solution in 2009, they would be better 
> off today.  Similarly, developers will be better off if we provide 
> navigator.cores today even if we manage to ship a better solution 
> sometime before 2019.

I agree that navigator.cores is a better solution for authors than 
nothing.

Authors aren't whom I'm worried about here.

If multiple vendors are interested in a more elaborate solution that 
doesn't expose more fingerprinting bits, I'm happy to try to spec that. 
Since this is not my area of expertise, I would welcome detailed 
descriptions of use cases, common pitfalls, experience with existing 
systems like Apple's GCD, to guide me in such work.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 5 May 2014 18:31:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC