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

On 7 Feb 2012, at 20:19, Boris Zbarsky wrote:

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.

Fair enough. This then becomes a cost/benefit issue. But there's
nothing to stop this working if the user's default is an opt out and a
prompt is given to allow. In exactly the same way that things
currently work for geo-location data. Right?

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.

I browse with NoScript and regularly come across people that haven't
coded site's responsibly (it drives me nuts). While I applaud this
notion because it'll bring more attention to the issue - i highly
doubt it'll have any impact on the larger spectrum of sites. JS is now
relied on and if certain UA's deliver a broken web-page to users, the
users are just going to blame the software, not the website. Why?
Because the site works in every *other* browser, including their old
ones...

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.

Absolutely agree. I'm all for this being disabled by default and
opted-in as servers request. Or opted in via a user setting in the UA.

 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?

They should be. But at the same time a hell of a lot of people have
read that FaceBook watches their every move, and yet happily continue
to use it. Users don't weigh the issue in the same way we do.

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!

Agreed! It's still my inclination to default to more permissive things
though. If people build poor sites, users stop going, the site fails,
and either the author learns (I hope) or switches to a job with less
requirement on skill level. It's like in business - if you're not
providing a decent product, you don't survive. The government doesn't
just disallow people from making rubbish with the resources they have.

   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.

In that case I completely agree. But the answer is educate them to
test the right thing. The *only* reason they say that they'll use it
that way right now is because that's what they *have* to do to guess
the information. Classic case being CSS media queries, where screen
size is a proxy for bandwidth and device processing power. It's a
mentality they're in because there is no other solution. Let's provide
one.

   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).

Ooo, interesting. OK, doesn't SPDY allow pushing content and open
connections? Can't we hijack that? And, given that any and all new
info is triggered by a request of some sort, why wouldn't the browser
send updated headers with those requests? (Again, may be a daft
question, I am not familiar with how this stuff works on any real
level of detail)

   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).

Interesting example. OK, how could this be fixed? Could hooks not be
provided for JS so that the site author could watch for these changes
and re-request as needed?

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?

While I agree, it's with a wry smile on my face that I note RSS is
already dying. It's been decided it's "too confusing" for users and
pulled from UI's on browsers. Discoverability of RSS is near zero in
modern browsers. The only people who'll know to look are already
au-fait with it. And that is a shame.

-Boris

Received on Tuesday, 7 February 2012 12:59:58 UTC