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

[Boris Zbarsky]

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