- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 07 Feb 2012 15:19:58 -0500
On 2/7/12 2:52 PM, Matthew Wilcox wrote: > Reporting more information about the user's hardware and software to > the server allows better fingerprinting and hence tracking. See > https://www.eff.org/deeplinks/__2010/01/primer-information-__theory-and-privacy > <https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy> > and similar resources for details. > > > Agreed. But this already happens. And browsers are working on mitigating the ways it already happens. Which means they're reluctant to add new fingerprinting surface. > Your point is the user must be able to > opt in and out, as they might be turning off JS (which, frankly, how > many non-webnerd people do?) Just wait until UAs start shipping with JS disabled for certain domains by default, just like they're already shipping with other capabilities turned on or off with certain domains by default. > So you're saying the problem isn't the > tech but the user control? Can we not give that to them? I'm saying that the _default_ behavior should ideally be as user-friendly as possible. That includes user privacy concerns. There can be additional knobs to enable more privacy features, of course, but a lot of what goes on in the privacy space on the web right now basically depends on user ignorance about the information websites are getting out of them. When I actually describe the underlying technology to non-technical users, they're almost uniformly horrified... > Point taken. Though it irks me no end that various technologies get > canned because of how inept people can mis-use them. I'd rather see > those inept people shoot themselves in the foot and pay the price. The problem is that the price ends up being paid by someone else. Classic example of externalities... If we could make people fully internalize the consequences of their own incompetence, a lot of things would ure be easier! > Did you read my earlier mails with examples of devices that are > shipping right now that violate the various assumptions people > trying to create these "device class" bins are making? > > > I don't believe we should ever use "classes" of device. We've been down > that route, it's a fail in and of itself. We should be using actual > data, not assumed data based on some other data. OK, good. We agree on that. :) > Absolutely agree on "device class". I don't understand why screen-size > is broken. Because half the people asking for it explicitly say they plan to use it as a proxy for other device characteristics. It's not broken per se, of course, just the way people plan to use it. > My point is that we should perhaps be thinking about how to make > things work when these device characteristics change while a page is > loaded. Headers do NOT allow you to handle that, for obvious reasons. > > Ah, loaded as in mid-stream? That's a problem too, but a small one as you note. I was thinking "as in between when onload fires and when onunload fires". For some web pages, this time is typically measured in weeks for me (my web-based RSS reader, for example). > See above. I don't see how just putting it in the headers helps. > It just encourages websites to assume that the information won't > be changing after the request is done. > > How does it encourage website that? That would involve using sessions to > track the user and know which request had what data the last time. And > manually writing some session tracking to do that. I see this as a per > request thing. New data every time. My RSS reader loads its user interface precisely once over the course of several weeks. If it based this interface on device characteristics at time of load (which it actually does, by the way, insofar as it sniffs the UA string and then guesses as you point out), then it would be broken if I ever change those device characteristics (which I do, and it is). It'd be nice if we could create something that would not lead the people writing the RSS reader to end up with exactly the setup they have now... -Boris
Received on Tuesday, 7 February 2012 12:19:58 UTC