Subject: RFC: draft-brown-device-stock-ua-00.txt

From: "Tiffany B. Brown" <[email-masked]>
Date: Wed, 07 Nov 2012 10:04:27 -0800

Hello all,

I've recently submitted an RFC for a new HTTP header: Device-Stock-UA. 
Feedback is welcome.

http://www.ietf.org/staging/draft-brown-device-stock-ua-00.txt

Abstract

    This document standardizes an HTTP extension header field that allows
    third-party HTTP clients and embeddable HTTP client components to
    include the user agent string of the HTTP-client that is bundled with
    the device operating system.

Thanks so much,

- Tiffany

-- 
Tiffany Brown, Developer Relations & Tools
Opera Software ASA (www.opera.com)
Twitter / AIM: webinista * Skype: tiffanybbrown

---

From: Eitan Adler <[email-masked]>
Date: Wed, 7 Nov 2012 13:17:30 -0500

> http://www.ietf.org/staging/draft-brown-device-stock-ua-00.txt

It isn't at all clear to me that this solves the problem:

- the stock services may have been changed. just because a browser
comes with a device by default doesn't mean it wasn't removed.
- the capabilities of the third party browser may differ from the
capabilities of the stock browser
- user agent shouldn't be use for capability detection in the first place
- what does the (stock) user agent string have to do with "other
software that may be running in addition to the user agent"?

-- 
Eitan Adler

---

From: "Tiffany B. Brown" <[email-masked]>
Date: Wed, 07 Nov 2012 11:26:22 -0800

>> http://www.ietf.org/staging/draft-brown-device-stock-ua-00.txt

Brief aside: I've been informed that I should have called this an 
Internet Draft (because it is). For the sake of following the 
discussion, I am keeping the original subject line.

> capabilities of the stock browser

This header should be used in conjunction with feature detection if used 
at all. Perhaps that's worth mentioning in an implementation notes or 
similar?

> - user agent shouldn't be use for capability detection in the first place

Agreed. However, this is precisely how the user agent string is being 
used. This is particularly true for sites and applications that support 
hand-held devices (mobile phones, tablets, etc). Developers are relying 
on the user agent string to determine which image and CSS files to serve.

> software that may be running in addition to the user agent"?

Developers are also using the user agent string to infer things such as 
the presence of audio and video codecs, plugin availability, and whether 
the OS permits file system access.

- Tiffany

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 08 Nov 2012 11:50:14 +1300

On 08.11.2012 07:17, Eitan Adler wrote:
> On 7 November 2012 13:04, Tiffany B. Brown wrote:
>> Hello all,
>>

... and why must a new header be added with identical usage, syntax and 
handling as User-Agent be created to perform User-Agent operations?

In section 4 the example does not match the BNF.

Following the format:
    Device-Stock-UA = "Device-Stock-UA" ":" (User-Agent)
    User-Agent = <Defined in RFC2616 Section 14.43>

We get:
        Device-Stock-UA: User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Correcting that mistake the uselessness of creating this header becomes 
completely obvious:

{{
   Device-Stock-UA = "Device-Stock-UA" ":" 1*( product | comment )
   User-Agent      = "User-Agent"      ":" 1*( product | comment )
}}

You might as well define this as a listing of ALL software, Java class, 
active component, and hardware chip serial number installed on the 
device. Just in case some marketer or website wigit *might* want to 
know. Do you see the problem? If not have a look at IE6 UA string after 
a few hundred KB patches have been applied - utter mess useful only to 
help malicious attackers target specific missing patches.

The operating UA is already free to embed the device stock UA into its 
own UA string using the same format. If it is making use of that UA 
capabilities to generate the request that is reasonable.

I for one see zero benefit from creating this header.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 08 Nov 2012 12:05:12 +1300

On 08.11.2012 08:26, Tiffany B. Brown wrote:
> This header should be used in conjunction with feature detection if
> used at all. Perhaps that's worth mentioning in an implementation
> notes or similar?

Feature detection of *what* exactly? that is important. critical even. 
Being informed about a piece of software which is not related to the 
transaction underway is useless. And I say this with my experienced web 
developer hat on.

For example;
   when opening a Z format object in Browser 'X' do I need to know the 
image processing capabilities of browser 'Y', or the fact that Picassa 
versus Photoshop are installed?

  No. I need to know that the browser X has a Z interpreter and is using 
it to handle the processing of the response I about to send back.

If browser X requests an image object, I still don't need to know that 
browser Y was installed, or even that the imaging software is installed. 
Just that the browser has *an* image processing component *it is making 
use of*.

There is nothing more annoying to both developer and user than to have 
a browser send explicit mention of capability Z, only to display that Z 
format response using a text processor and dump raw binary out at the 
viewing user.

> used. This is particularly true for sites and applications that
> support hand-held devices (mobile phones, tablets, etc). Developers
> are relying on the user agent string to determine which image and CSS
> files to serve.
>
> Developers are also using the user agent string to infer things such
> as the presence of audio and video codecs, plugin availability, and
> whether the OS permits file system access.

*This* is the problem. Your header is making zero progress on fixing 
it.

Those websites are ignoring the Accept* headers content where such 
codec and media type support is listed in annoyingly great detail. And 
instead depending on the browser agent name string.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Nov 2012 05:36:04 +1100

For those who haven't seen it, Ilya (cc:ed) is working on something related that he's calling "client hints".

http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0053.html

Cheers,

On 08/11/2012, at 5:04 AM, Tiffany B. Brown <[email-masked]> wrote:

> Hello all,
> 
> I've recently submitted an RFC for a new HTTP header: Device-Stock-UA. Feedback is welcome.
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Ilya Grigorik <[email-masked]>
Date: Thu, 8 Nov 2012 23:04:50 -0800

On Thu, Nov 8, 2012 at 10:36 AM, Mark Nottingham <[email-masked]> wrote:

> For those who haven't seen it, Ilya (cc:ed) is working on something
> related that he's calling "client hints".
>

Thanks Mark. We had a good discussion on the Clients Hints proposal earlier
today at the W3C perf workshop.. Will be updating the document with all the
feedback and suggestions shortly. If anyone has feedback on what's there
already, please let me know!

This might lack context without the audio, but a quick presentation on the
proposal for today's discussion:
https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/present

Ilya

---

From: "Martin Nilsson" <[email-masked]>
Date: Fri, 09 Nov 2012 15:04:23 +0100

One should also keep in mind that one common usage of the user agent  
header is to identify the physical device/firmware to select a compatible  
download (like j2me application), that have nothing to do with browser  
features.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: "Martin Nilsson" <[email-masked]>
Date: Fri, 09 Nov 2012 15:13:50 +0100

> https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/present

Nice presentation. The end proposal looks very similar to UAProf, which is  
supported by a large number of mobile devices. (  
http://www.openmobilealliance.org/tech/affiliates/wap/wap-248-uaprof-20011020-a.pdf  
)

It would be interesting to have a discussion on why UAProf failed.

/Martin Nilsson

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 9 Nov 2012 09:53:54 -0800

> http://www.openmobilealliance.**org/tech/affiliates/wap/wap-**
> 248-uaprof-20011020-a.pdf<http://www.openmobilealliance.org/tech/affiliates/wap/wap-248-uaprof-20011020-a.pdf>)
>

"Large" is a relative term :-) .. AFAIK, Nokia and a few other device
vendors provide the UAProf header, but unfortunately it just didn't get any
adoption from the (new) dominant smartphone vendors. The URL + dictionary
structure it provides is (I believe) way too complicated for what it needs
to be (RDF dicts + entire process to define them, questions about who and
what maintains them, and so on). I think we can get 95% of the value with
95% less overhead, and we do need a solution..

ig

---

From: "Tiffany B. Brown" <[email-masked]>
Date: Mon, 12 Nov 2012 08:27:45 -0800

>    User-Agent      = "User-Agent"      ":" 1*( product | comment )

It's the identical usage, syntax, and handling, but for two different 
products installed on the same device.  It's an optional header and  not 
without precedent; transcoders also use this model. Perhaps most 
importantly, it's compatible with existing device adaptation practices.

> help malicious attackers target specific missing patches.

Again: this header, if sent, would reveal marginally more than what the 
native HTTP client reveals. It would certainly reveal no more than what 
client-side feature detection reveals (the navigator.plugins object, for 
example). It's about the same risk that exists with any sort of user 
agent string change.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Nov 2012 09:29:39 +1100

FYI, further discussion here:
  https://bugzilla.mozilla.org/show_bug.cgi?id=799899

... and background (with more discussion) here:
  http://my.opera.com/ODIN/blog/2012/10/08/introducing-device-stock-ua

Regards,