[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

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