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
