On 2/7/12 12:32 PM, Matthew Wilcox wrote:
This is a case of browser vendors (or at least me with my browser
implementor had on) thinking that sending this sort of information
will hurt their users' privacy
Can you clarify how this hurts privacy? I'm not sure how reporting back
things like connection speed or screen size constitutes a genuine
privacy issue?
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
and similar resources for details.
, will cause their users to get more broken pages (which is what
happens in many cases with browser sniffing right now), will lock
new devices out of the market (which is what happens with new UA
strings right now). And hence that the proposal is bad for the web
in various ways.
I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers
aren't there anyway
Maybe it would be _sensible_, but would people do it? I suggest trying
to browse the web with an empty UA string and seeing what fraction of
servers serve "some default" for that as opposed to the fraction that
completely break and return error pages for everything or return
severely malformed pages... Last I tried this, double-digit percentages
of the sites I visited broke.
In what circumstances might this cause breakages?
Whenever the server developer makes dumb assumptions. Which they do all
the time. _All_ the time.
And how could it possibly lock out any devices?
See my earlier example of a "desktop-class" touchscreen system that's
shipping right now. Every single concrete proposal I've seen so far in
this thread would lock it out of actually using its touch capabilities
on sites that would support such capabilities fine on other devices.
This is a progressive-enhancement type tech, not a "if you don't have the
ability
to notify the server you can't get any info" type tech. Surely?
Surely not, in my experience with other things servers look for.
Now obviously it's also good for the web in various ways, if people
use the information "correctly" and such. My faith in this is
somewhat tarnished by the fact that every concrete proposal for
using it that I've seen seems to be broken by design, which means
that chances of anyone using it "correctly" are vanishingly small.
Can you tell us how they're broken so we can fix it?
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?
Absolutely agree, but I don't see how a server requesting and then
getting a header is rocket sceince
The rocket science lies in deciding what to do with the information.
Especially if the current solution
is to connect to some massive device database to query potential points
of reference and then act accordingly.
Which is just as broken, yes. We've run into problems with the breakage
of this database a good bit at Mozilla.
I can see your point, but there isn't any impact for users unless the
author has "opted in" and requested headers. Right? The defaults are
"server gets no headers". Put it another way - how can an author tailor
things for a user if the user isn't able to report anything to the
server?
I didn't say the user shouldn't report anything. I said that the
particular things people have asked to be reported so far (screen size,
"device class") are broken by design.
Yes, but "size" and "performance" are not necessarily a function of
the actual device. They can be a function of the device, the
network, the currently attached peripherals, etc. Importantly, they
are not time-invariant. The question is what we can do about that...
Agreed - which is *exactly* why I think headers are the only viable
solution.
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.
The other solutions operate by detecting the device and making
assumptions about those variables based on the device specifications.
Assuming you can detect the device at all, which I think servers should
not be able to do.
Exactly! Hence the need for the browser to report *as a header* with
each request what the current values are for those variables.
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.
-Boris
