Compiling use case detections

use-case-UA-detection.md

Draft for Issue 152

User Agent Detection Use Cases

Before being able to freeze and reduce parts of the browser User Agent string, we need to clearly lay down the different ways the user agent strings is being used on the Web by users and developers.

The User Agent String detection is the mechanism by which a piece of software will change its behavior according to the interpretation of the value of the User Agent String.

User Agent Strings Scope

Here we are limiting the scope of this document to the values returned by:

• HTTP UserAgent
• DOM navigator.userAgent

These are the two commonly used mechanisms for identifying the browser.

\ What is it? \ Who Benefits? \ Examples

Use Cases

Mobile vs Desktop site redirection

While responsive design has helped web developers to create websites adjusting themselves to any devices form factors, there are still a lot of domain owners having one or multiple mobile websites and a desktop websites.

People reaching these websites are often redirected based on the user agent string using some convoluted regexes and libraries to determine if the browser is a mobile browser or a desktop browser. The tablet environment makes that redirection even more difficult by blurring the lines in between the different form factors.

Why does it still go on? Not every places, persons in the world have access to a modern device able to process a responsive design correctly.

Marketshare Analytics

Browser Marketshare Analytics is mostly used by web developers and QA testing department to determine the level of support they want to dedicate to a browser. While a website which has been conceived with resilience and flexibility in mind, the analytics will determine the level of quality control a project receives. If a browser market share is becoming too low, the website owners will ignore testing on this specific browser.

Unfortunately, by fear of providing a bad service, some web developers will choose to deny the access to the website based on the browser user agent string.

Browser features and bugs

Browsers have limitations and bugs. Some features are not deployed evenly at the same in all browsers. Shim libraries and site web developers will use user agent detection to tailor the response and the code path according to the version number of the browser or the type of rendering engine the browser is using. For example, it's very common in the case of videos.

TODO: An example of a feature which can't be detected through feature detection. TODO: An example of a bug which can be avoided only with user agent sniffing.

OS integration for native applications, Addons, Web extensions

Some websites provides links to access an OS native version of a software. For example, a website advertises an application software which exists on both Android and iOS. They provide a link to open directly the appstore for the reader's OS. To identify which link to create for the right OS, they need to identify the platform of the reader. This is done through user agent detection.

The same applies for web extensions. A lot of progress has been made to level the space of web extensions, but we are not there yet.

Browser Upgrades

When someone is using a specific version of the browser, some websites developers (including browser implementers) will advertise a message to upgrade the browser to benefit from more recent features and avoid security issues. They will use the user agent string information and detect the version number and the platform of the browser to suggest the right download for the user.

Fingerprinting

Some ads services and marketing services are using the user agent string as an additional vector of identification for a specific user. The more data they collect, the more efficient their targeting is. This technique is often privacy hostile.

Blocking Crawlers and bots (Server side benefits)

This type of user agent identification is helping website developers to block access to abusive or buggy bots and scripts. It may have some unwanted side effects for users who would happen to share the same user agent string.

@@here to think about organizing this part@@

Device/Software capabilities

    Send anterior version of a browser to a simpler version of the Web site. The new Web site using technologies unsupported on old browsers, the user will get a bad experience.
    Block the access to an anterior version of browser and recommend the user to download a new version of the browser.
    Redirect the browser to the (feature phone|smartphone|tablet|desktop|tv|wearable) Web site or provide directly content optimized for the device.
    Customizing content such as the choice of video formats, the UI elements size, Ads.
    Plugin and framework supports such as J2ME, DRM.
    Device own material performance

Network Performances

    Server-side optimization of media (size and formats). Certain devices type are believed to access the Web through a type of connection. The assumption is often triggered by if it's a mobile the network bandwidth and/or latency is either bad or expensive.

Technical

    Blocking some abusive bots
    A/B testing during feature deployments
    Fallback: Once features detection has failed to be able to customize the user experience: Incomplete support of features, support not optimized for a specific feature, misleading user agent with regards to support

Business

    Delivering specific content (Premium, documentation, help) for certain devices
    Native app: Encouraging to download the platform native app for capturing an audience
    Upgrading the user agent: Proposing the right software to download when upgrading
    Analytics and statistics reporting

Here we are limiting the scope of this document to the values returned by:

HTTP UserAgent
DOM navigator.userAgent

Are the navigator.platform and navigator.oscpu APIs out of scope? They expose a subset of the information exposed in navigator.userAgent and could probably be mentioned as just a special case of navigator.userAgent. (They return "Win32" and "Windows NT 10.0; Win64; x64" in my Firefox.)

Another use case: some sites remember (information from) your UA string to show a logged-in user's recent logins or to force a 2FA re-authentication when the site doesn't recognize a login's UA string.

Some examples:

• Google Account: Recent security activity just lists OS name without version like “macOS”.
• Gmail: Activity on this account lists full UA string.
• When I log into my credit union's site, it shows a “Recent Login Activity” message with my previous login's date/time and browser name and version (but no OS name or version).

btw, the Markdown formatting of this doc is busted starting with the ###　Fingerprinting section header.

Thanks @cpeterso

fixed the finger printing section.
The rest is normal. It's a different way to organize similar information, I'm still wondering what would be the best.

TODO: An example of a feature which can't be detected through feature detection.

Right now font feature support across OSes and versions doesn't have a great story for feature detection - the UA string can serve as a proxy for that, especially if you want to Vary the CSS you serve.

TODO: An example of a bug which can be avoided only with user agent sniffing.

https://bugs.webkit.org/show_bug.cgi?id=216593#c9 seems to be an example (possibly of both).

Are the navigator.platform and navigator.oscpu APIs out of scope?
They're probably worth including.

navigator.oscpu seems to be Gecko-only these days. There's also navigator.appVersion which leaks some UA info (Blink and WebKit behavior similary, Gecko does something different).

Looking at https://github.com/WICG/ua-client-hints#use-cases, I think the only one missing is downloads - that could probably fit in the "OS integration for native applications, Addons, Web extensions" section with a little nudging.