Should we re-evaluate the definition of 'mobile' and 'desktop'?

[colinbendell]

It's 2020. The large majority of 'desktop' are really laptop devices. Laptops are just like mobile devices in that they are used while on busses, coffee shops and on the couch. Laptops are also often tethered on cellular when users are commuting in an uber and the like (at least in pre-covid era they were).

Complicating the situation we have Tablets, Chromebooks and many devices in between.

There are a few common shorthand interpretations for 'mobile'. It is to mean: 1) viewport with ~320 CSS pixels, and a ~9x6 aspect ratio 2) 2x+ DPR and a viewing distance of ~32cm (vs laptops which have a viewing distance of 50cm or watches at a viewing distance of 20cm) 3) lower power device on expensive 'cellular' internet

If "mobile" is to mean 1) then perhaps we should either a) define mobile as a shorthand for orientation and aspect ratio of a display port and/or b) use something like Sec-CH-Portrait: ?1

If "mobile" is to mean 2) then like the above, we should introduce a viewing distance CH that like DPR reflects an expected viewing distance. (would also be useful for situations like: Is this a TV on a living room wall or a TV showing a map in the mall?). However, unlike DPR, this will need a lot of debate. At minimum it would need to be segmented into buckets for watches, tvs, laptops, desktops, tablets and game consoles. But the bigger problem will be landing on a consistency for the unit of measure in space - should we use the metric system or the US system? Would Sec-CH-ViewingDistance: 32 mean cm or inches? For this reason, I'd want to explicitly define mobile as NOT implying viewing distance.

Finally, if "mobile" is to also mean 3) then we have a problem because laptops are very commonly on cellular. Informal data points I've collected in the past revealed 1/3 of cell data was from tethered laptops (varies by geo and time of day). For this reason I'd want to discourage mobile from implicitly meaning 'cellular' by explicitly defining mobile as NOT cellular or satellite.

[amtunlimited]

I think it's important to note that the definition used in the proposal is based on what browsers are currently doing, which is almost entirely based on platform (i.e. Android/iOS vs Windows/Mac/Linux). Each of your other suggestions can be problematic in that they rely on values that are both arguable and are very likely to shift over time.

For example, basing mobile-iness on viewport width can be an issue because:

1. As the size and resolutions of phones shift over time, so will what would be considered a "reasonable" indicator, and therefore probably shouldn't be ossified.

2. What even constitutes a "reasonable" indicator will probably be different from person to person and even app to app, and so should probably be left up to the developer

(It should also be noted that both viewport-width and estimated connection type (ECT) are also available as hints)

Signifying whether a screen is in portrait mode might actually be an interesting hint, although I don't know if it would help as I know many developers (myself included) use vertically oriented screens on desktop.

Viewing distance brings with it it's own problems, depending on how you gather that data. If it's just ossified to model or platform, it might be better to get those values directly. If it's actually measured (either through sensors or configuration) than it would be a significant fingerprinting vector, even if it were bucketed.

There has been discussion of some sort of "form-factor" type hint (e.g. phone, tablet, desktop, watch) but problems come in when you want to introduce a new value.

The mobile-ness hint comes at an interesting crossroad where most major browsers on different platforms all indicate it in some way, and indicate it on basically the same signal, but it hasn't actually been standardized.

TL;DR Developer and app has different needs and wants for defining when to give a "mobile" vs "desktop" UX, and we should let the developer decide what signals to pay attention to and how much to pay attention to them. The definition in the UA-CH spec is based on what most browsers currently agree on, which is bucketing by platform.

[yoavweiss]

What @amtunlimited said :)

• viewport with ~320 CSS pixels, and a ~9x6 aspect ratio

• 2x DPR and a viewing distance of ~32cm (vs laptops which have a viewing distance of 50cm or watches at a viewing distance of 20cm)

• lower power device on expensive 'cellular' internet

Because this is a complex and fluid-over-time definition, it seems like a better long term strategy is to expose the dimensions that can influence the decision. (while minimizing the exposed entropy, using bucketing where it makes sense)

b) use something like Sec-CH-Portrait: ?1

That seems reasonable, but orthogonal to "mobile"

[colinbendell]

I think it's important to note that the definition used in the proposal is based on what browsers are currently doing, which is almost entirely based on platform (i.e. Android/iOS vs Windows/Mac/Linux). Each of your other suggestions can be problematic in that they rely on values that are both arguable and are very likely to shift over time.

You are right that the mobile: ?1 is currently a proxy for OS. But what I'm getting at is that the reason why devs use this coarse grained proxy is for the reasons above. Devs will use mobile == 1 to make orientation, device-power, network assumptions etc.

This is why I was proposing that we at minimum be declarative of what sec-ch-mobile means and more specifically that it shouldn't be used to answer 'orientation', 'dpr', 'device power', 'network', etc.

[yoavweiss]

Would a non-normative note indicating the above address your concerns?

[colinbendell]

amtunlimited wrote:

The mobile-ness hint comes at an interesting crossroad where most major browsers on different platforms all indicate it in some way, and indicate it on basically the same signal, but it hasn't actually been standardized.

The signal is interesting, but what I'm probing at is the 'why'. Why are devs using this signal? Is the signal useful in itself, or is it being used as a proxy for other purposes.

I submit that it is really a proxy to adapt content which evolved organically because of the lack of other signals. It is the 'why' I think is worth digging into.

yoavweiss wrote:

Would a non-normative note indicating the above address your concerns?

Certainly it would be directional. However, with the absence of alternative signals it will result in no changes in behaviors by devs. Which result in fragile and inconsistent experiences for users. As a bridge to alternatives, sec-ch-mobile does seem natural. But I fear it is just promoting the same classification system of yesteryear that are problematic for the continued evolution of the web.

What I'd like to get general agreement on is: a) is mobile useful for devs in of itself or is it actually just a proxy signal. If the latter then: b) what are the most common uses for the 'mobile' signal? I proposed 3 (orientation, dpr / viewing distance, device-power + network) which are commonly used in adapting layout, content and functionality. Or are there other dimensions or uses that are common? c) are there alternative hints or patterns we should advocate for each of these signals. (eg: sec-ch-portrait, NetInfo, etc). Based on agreement from b) I'll spin up other issues to expand the discussion.

IMHO, I am hard pressed to come up with a use case for 'mobile' that isn't an indirection to one of the above actual uses.

[amtunlimited]

Will write a better, more thought out response later (Because I do think you bring up some good discussion points), but real quick:

IMHO, I am hard pressed to come up with a use case for 'mobile' that isn't an indirection to one of the above actual uses.

One use case you might not have thought about is that the "mobile" signal is, at least somewhat, a user-controlled preference. At least in Chrome, basically the only thing the "request desktop? button does is go back through any redirects from the last navigation and send the same request without the "Mobile" keyword in the user agent string.

c) are there alternative hints or patterns we should advocate for each of these signals. (eg: sec-ch-portrait, NetInfo, etc). Based on agreement from b) I'll spin up other issues to expand the discussion.

There already exist client hints for viewport width, estimated connection type, and dpr (which you mentioned above)

[colinbendell]

One use case you might not have thought about is that the "mobile" signal is, at least somewhat, a user-controlled preference. At least in Chrome, basically the only thing the "request desktop? button does is go back through any redirects from the last navigation and send the same request without the "Mobile" keyword in the user agent string.

Yes, but why are these platforms doing adaptive outputs of markup for "laptop" v. "mobile"? The reasons are because they a) have a different DOM because of the orientation, b) they have a different viewing distance (plus orientation) or c) they are simplified DOM + javascript because of the assumption of lower power cpu + network. mDot websites and the like of responsive server side use the mobile signal as a crutch and a proxy for these other reasons and because there aren't better patterns to follow.

This is why I think there exists an opportunity for us to assist developers for the next decade to adopt better patterns and avoid the 'mobile' fallacy. (I call it a fallacy because the very need for a 'load desktop version' highlights the problem that the mobile signal doesn't work as users expect and so browsers have patched the behavior of the server by impersonating a windows/macos UA)

c) are there alternative hints or patterns we should advocate for each of these signals. (eg: sec-ch-portrait, NetInfo, etc). Based on agreement from b) I'll spin up other issues to expand the discussion.

There already exist client hints for viewport width, estimated connection type, and dpr (which you mentioned above)

Yes, viewport and dpr exist as client hints. Connection Type is still broken not useful in practical sense to adapt content because of the fingerprinting concerns. Perhaps there is an evolution of a meta hint that might wrap cpu + gpu + network strength + battery into a device "power" scoring system? (not to be debated here, just flagging as a causation reason for adapting content). Viewing distance and orientation are also missing.

What I'm hoping get consensus on is that there also exists motivations for adapting content for 'mobile' because the developer is actually meaning other factors such as device power, viewing distance, orientation.

[yoavweiss]

I'm highly supportive of breaking up non-direct signals into more direct ones (e.g. orientation, viewing distance, etc), providing more granular content adaptation, which is more likely to be what both the developer and the user want.

Might be interesting to spin up issues or proposals on those fronts, to kick off such alternative paths. At the same time, I think we'd need to keep "mobile" as is to provide a quick migration path for legacy apps.

[ronancremin]

As suggested in the ua-client-hints README, the proposal has struggled with the definition of mobile to the point that the current meaning of the term is defined only implicitly by a holdover behaviour in browsers. This doesn't seem like a good thing to bake into a new standard.

The term mobile user experience had a clear enough meaning about ten years ago—smaller screens, lower bandwidth, limited inputs, limited processing power—but the web landscape has changed so much (inverted even) that this term no longer has much descriptive power and it's likely to become less clear. In some cases "mobile user experience" might mean a super-rich experience the better to take advantage of a smartphone's sensors, 5G connectivity and rich media capture; in other cases it may mean a bare bones representation to deliver a minimal experience to a poorly connected device.

Also, implying a binary choice between mobile and desktop isn't helpful either. Is the opposite of mobile desktop? Some fixed devices are not desktops—how should a set-top box connected to a large screen be classified? The spectrum of connected device types is only going to grow; some may not have screens or conventional input methods.

[yoavweiss]

Again - the main reason for including "mobile" and exposing it by default is to enable an easy migration path from UA-string-based content negotiation (which currently includes "mobile" indications - as inaccurate as they may be). Once that migration happened, we can and should think of future-facing ways to split up the different dimensions into their own hints.

[CyberAP]

I have originally wanted to post in #43, but this discussion seems to be a more approprate place for that.

---

The spec is kind of uncertain in the regard of what mobileness actually means. Right now it says:

The Sec-CH-UA-Mobile request header field gives a server information about whether or not a user agent prefers a "mobile" user experience.

But the mobile user experience meaning is never defined (or I might be just missing something, though there is a section for Content Adaptation). And that mobileness term might mean different things to different people.

If this hint is actually supposed to provide touch-only related hints (just judjing from this comment) then I'd suggest maybe renaming it to Sec-CH-UA-Touch-Features? Because mobileness doesn't always corellate with touch support (Surface Studio is a common example of that).

---

the main reason for including "mobile" and exposing it by default is to enable an easy migration path from UA-string-based content negotiation

I am actually not really sure how that migration path should look like? What features can we extract from the mobileness client hint that have their direct counterparts in the User-Agent string guesses?

---

I don't think that current mobileness client hint actually solves the problem its aimed at (if I am correct to assume it should solve this problem), citing 1.2.3.2. Mobile specific site:

...

For those cases, serving mobile-specific sites to users on mobile devices can be helpful. For that to work, the server needs to be aware, at HTML serving time, whether the user is on a mobile device or not.

Sites that wish to serve mobile-specific sites using UA-CH can do that using the Sec-CH-UA-Mobile headers that are sent by default on every request.

I would argue here that we don't actually try to target mobile devices specifically when serving HTML. We want to give client the best possible experience no matter if that's a mobile device or not. If the viewport width we're aiming on at server render time doesn't approximately match client viewport we're not delivering a good experience, and this is related to any kind of device, not just mobile ones.

---

Maybe that should be its own issue, but I'll post it here first. What I would rather hope to see in the spec as well is a client hint for the viewport width (yes like in the suggestion above), using fixed breakpoint list that device's logical pixels fit into.

Example:

Sec-CH-UA-Viewport-Width: 320

With breakpoints defined as: 320|720|1024|>1024, or any reasonable list that's most commonly used and agreed upon.

That would solve these problems:

• SSR best-fit layout: no need to rebuild much of the UI after the initial render
• Developer friendliness: we don't have to guess\remember what Mobile means in actual pixels for example
• Security: device's actual screen width is not exposed

And I'd like to highlight SSR there because I think this is the key missing part here. Right now the best way of marrying responsive design with SSR is just to guess what kind of resolution client might have (absolutely disregarding orientation for example) using User-Agent string. If Clients Hints are to replace User-Agent I think this should also make it into the spec because mobileness can not safely replace User-Agent string in its current state unfortunately.

[amtunlimited]

What I would rather hope to see in the spec as well is a client hint for the viewport width

You're in luck! Sec-CH-Viewport-Width already exists. The other currently defined hints are in Client Hints Infrastructure, this repo is strictly hints that mimic the User Agent string in functionality.

I would agree that "mobiliness" is rather ill defined, but I would also argue that there really isn't a definition, or at least a single useful one. The reason Sec-CH-UA-Mobile exists is simply because it exists in current user agent strings. Right now those are all tied to platform: Chromium, Firefox, and Safari all append "Mobile" to the user agent string on iOS and Android. I personally think this is a pretty reasonable approximation right now.

I think definition of "mobile" is really just in search of something more specific and nothing would be universal. You're right in that the delineation is already becoming a spectrum.

As for one of your other comments, input mode has also been discussed on WICG/client-hints-infrastructure#82. I personally think it's worth looking into.

[CyberAP]

You're in luck! Sec-CH-Viewport-Width already exists. The other currently defined hints are in Client Hints Infrastructure, this repo is strictly hints that mimic the User Agent string in functionality.

Thank you so much for that, I knew I wasn't the first who came up with the idea! Really hope this gets defined and implemented on the first iteration of Client Hints.

I personally think this is a pretty reasonable approximation right now.

My only serious concern here is that in its current state, mobileness can not be used as a direct substitute for User-Agent to tell the server which experience the user expects (as suggested in 1.2.3.2). I am personally missing a way to detect tablets there, and I am certain there are people who already depend on a more fine-grained device detection, which will not work when this change takes place (by that I mean reduction in User-Agent detalization). As far as I understand a Sec-CH-UA-Model client hint can be disabled by the user, so if they want to increase their privacy they will in return get a degradation in user experience (which I think should not be the case). So my conclusion here is simple: if Client Hints should replace User-Agent then the experience should not change for the end-user.

[abeyad]

Thank you so much for that, I knew I wasn't the first who came up with the idea! Really hope this gets defined and implemented on the first iteration of Client Hints.

Sec-CH-Viewport-Width is already available in Chrome.

As far as I understand a Sec-CH-UA-Model client hint can be disabled by the user, so if they want to increase their privacy they will in return get a degradation in user experience (which I think should not be the case).

Are you referring to the fact that user agents can chose to not send a client hint for privacy reasons, even when requested? https://wicg.github.io/ua-client-hints/#fingerprinting

If a user wants to limit the data sent to the server in exchange for a potentially degraded user experience, then that's a choice that the browser should respect. The problem is they don't have that control right now with the User-Agent string, which the client hints mechanism hopes to help solve. Otherwise, you can get all the information from client hints that you can get from the User-Agent string, so I don't think there's a gap in available information.

[amtunlimited]

My only serious concern here is that in its current state, mobileness can not be used as a direct substitute for User-Agent to tell the server which experience the user expects (as suggested in 1.2.3.2). I am personally missing a way to detect tablets there

This hint is only to mimic the information of whether or not Mobile would be present in the User-Agent string and nothing more. It's the hints combined that serve to "replace" the User Agent string.

and I am certain there are people who already depend on a more fine-grained device detection, which will not work when this change takes place (by that I mean reduction in User-Agent detalization).

Genuine question (always trying to find new use cases): what information do you use from the model? And of that information, what cannot be gather from other, direct sources?

That's sort of the goal here, to be able to just get the information you need without the massive privacy tradeoff that is revealing the device model, which is a very high source of entropy, especially if you only need something as trivial as the screen dimensions.

As far as I understand a Sec-CH-UA-Model client hint can be disabled by the user,

The same can be done for the User-Agent, with command line flags, or through developer tools, orone of many many extensions. User-Agent spoofing happens all the time, often in the name of privacy.

so if they want to increase their privacy they will in return get a degradation in user experience (which I think should not be the case).

Same with plugins that disable cookies or block forms of JavaScript. I think the tradeoff is well known to the kinds of people who would make those choices. If would be preferred if there wasn't a UX tradeoff, but that takes work from both sides.

So my conclusion here is simple: if Client Hints should replace User-Agent then the experience should not change for the end-user.

That is the hope.

[CyberAP]

Sec-CH-Viewport-Width is already available in Chrome.

Could I ask you to point to the specific page where I can verify that? Because my current Chrome installation doesn't send it by default and from what the MDN says it is actually no longer recommended.

If that's the header you're referring to then I am certain it can not serve as a direct replacement for User-Agent since it's an opt-in header, which means that the user will get a downgraded experience on the first request.

Genuine question (always trying to find new use cases): what information do you use from the model? And of that information, what cannot be gather from other, direct sources?

We use ua-parser to determine device type and do our best guess to serve an appropriate html for the device. That usually means that we match our media-queries to device types and go on from there. Right now we support 3 types of devices: mobile, tablet and desktop. We completely understand that this is a huge simplification of the actual experience that users expect and I hope that eventually Client Hints would help with that.

I would much rather prefer having sec-ch-ua-viewport-width to be sent on each request with no negotiation reqired (even if that means sending approximate width), than having a device hint, since as you well pointed we probably shouldn't gather any valuable information from that.

[abeyad]

Could I ask you to point to the specific page where I can verify that? Because my current Chrome installation doesn't send it by default and from what the MDN says it is actually no longer recommended.

The MDN page is referring to Viewport-Width, which is deprecated in favor of Sec-CH-Viewport-Width (there's also a Sec-CH-Viewport-Height). If you include Sec-CH-Viewport-Width in your Accept-CH header, then on the next request to the same origin, Chrome will include the Sec-CH-Viewport-Width header.

https://wicg.github.io/responsive-image-client-hints/#sec-ch-viewport-width contains more details about viewport width.

[CyberAP]

If you include Sec-CH-Viewport-Width in your Accept-CH header, then on the next request to the same origin, Chrome will include the Sec-CH-Viewport-Width header.

That is the problem here. Negotiable headers are not a direct substitue for User-Agent. Because User-Agent is sent on the very first request and those Client Hints are not, which will lead to a jump in the interface on the first visit.

[abeyad]

That is the problem here. Negotiable headers are not a direct substitue for User-Agent. Because User-Agent is sent on the very first request and those Client Hints are not, which will lead to a jump in the interface on the first visit.

For that, you can use Critical-CH to also get the dimensions on the first request, though it does add some to the latency since it requires resending the initial request with the requested client hints. If your site uses TLS, an ACCEPT_CH frame can be added to the handshake protocol (to avoid the extra latency Critical-CH introduces), though that would require your TLS implementation to support it: https://chromestatus.com/feature/5555544540577792.

[CyberAP]

That actually should solve the problem, thank you! 👌