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 , 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. `._.-(,_..'--(,_..'`-.;.'