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

Thanks again, you make some good points :)

More responses inline...

On 7 February 2012 17:59, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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<https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy>and similar resources for details.


Agreed. But this already happens. 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?). So you're saying the problem isn't the tech but
the user control? Can we not give that to them?


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


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. Personal philosophy
there.


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


I don't think I have enough knowledge of the case in point to argue either
way, but I'm confused how this would be the case at the moment.


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


Fair enough :s


>     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?


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.


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


Ugh, I wrote 'rocket science'. Sorry.


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


Cool so we agree databases are a bad solution and we should aim for better
:)


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


Absolutely agree on "device class". I don't understand why screen-size is
broken. Report back the maximum screen size used by the device at the
current moment. This allows us to plug iPads into TVs and have it all still
work.


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


Ah, loaded as in mid-stream? Agreed, it can't. But then how much is likely
to change in the few fractions of seconds it takes to complete transmission
of one resource? Vs what can change in the comparative eons between
resource requests? Surely per-resource-request is granular enough?


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


Ah, but they do. All the time. They see a UA string and guess. Badly.
Catastrophically badly. Then they take their poor guess and extrapolate the
info they *actually* wanted to know from it. The fact is it's being done,
and it will contiinue to be done until there's a more reliable solution. If
we supply headers, we do NOT detect the device. We supply the exact
information the server is after. connection speed. etc.


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


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.


> -Boris
>

Received on Tuesday, 7 February 2012 11:52:56 UTC