Provide input method UA CH (Was: We can do better than "mobileness" as a boolean) #43
Comments
|
Sec-CH-Experience: "Mobile", "Desktop", "Watch", "Television", "Headset" |
I would posit that most UA sniffing in that regard either searches for "Mobile" or uses the device/viewport width, and a minority look at these things. I also don't know of a well lit path for enums that doesn't lead to a very similar problem we have with minority browser vendors now. A device will come up with a new class "foo", websites will only have a version for "desktop" and "mobile", and fail on cases it's not aware of. New devices either risk not being developed for or they pick an already existing option that's well know and fit well enough. I see one of two options: We let browsers set whatever they want, which will lead to a lot of browser-specific behaviours and edge cases very quickly, or we codify it in a standard, in which case the list is always behind the times and either browsers stay behind the ties with it or we are back to the first problem. Basically, I forsee the list either ballooning or ossifying. All of those options might be too many to fit into too few buckets. Is there any benefit to putting it all into one hint instead of looking at other hints like |
|
@amtunlimited I agree with your analysis on that list becoming ossified, unless we explicitly GREASE it (which will come with an adaptation cost). At the same time, I was talking to @bslassey yesterday, and it seems like there's room for more form factors than just "mobile". One example that came up was a feature phone. |
+1 to this. Speaking from long hands-on experience in that field, device classifications, like form factors, feature-phoneness, and even mobileness, is a moving target. Further, the classifications have different meanings depending on geography, audience and application.
+1 to this too. |
When it comes to naming, perhaps being explicit about that delineation would be helpful (e.g. |
|
I think having these concrete hints is better in general. The composability might need to be examined entropy-wise, but it'll allow for getting what you actually need instead of having to blow your privacy budget on something with an insane amount of entropy like |
|
Copying from the closed issue: the primary goal of detecting ‘mobileness’ for developers is answering two questions: whether they can use hover-based techniques (i.e. user uses mouse or pen) and whether they can use multitouch-based techniques. All other stuff is highly irrelevant. Screen size says nothing in current state of affairs — right now my phone screen has more pixels (both logical and physical) than my laptop one. It would be more or less useful to understand physical characteristics of the screen (DPI) than ’mobileness’. Detecting mobile user-agents mostly serve the purpose to guess resolution and scaling, since you may simply hardcode them for popular devices, such as iPhone. And providing just 'mobile' flag doesn't help to remove this hardcode. |
yoavweiss
changed the title
yoavweiss
added
enhancement
|
One justification for keeping mobileness as a boolean is compatibility with the "mobile" token currently used in user agent strings (see #120). But user agent strings in the wild already use other tokens to indicate device type e.g. "VR" for virtual reality headsets. Here's a UA string from an Oculus Quest 2:
Many televisions use a "TV" token:
So a simple mobileness boolean is incomplete if the goal is backwards compatibility, meaning a reduction of functionality. |
|
Going to add to this issue, as I wanted to open an issue and did a quick search, which lead me to this open issue. I agree with #94 I was thinking Apple iPhone X has one screen. and Samsung Galaxy Fold has more than one screen.
This lead me to think why this repo doesn't create a new header, something like: Then the above example could have the following results: Apple iPhone X has one screen. Samsung Galaxy Fold has more than one screen. I would then suggest a whole range of values (which we currently use for our user agent parser in the repo: https://github.com/Summer-CMS-Modules/sc-parser-module) FingerprintingI know this repo talks a lot about fingerprinting but I feel this extra information is not going to cause any major issues with regards to that. |
|
I mean you'd be going from 1 bit of information to 5 bits of information, with most of the values other than "Desktop", "Tablet" and the mobile values will be highly uncommon and so will be highly valuable as fingerprinting values. Besides, why does the server need to know what kind of device you have? If you need to serve less content to devices with less bandwidth then use the Downlink and Save-Data client hints. (Which has the advantage of discriminating between high-end devices on high-end plans and low-end devices on low-end plans, and other such combinations.) If you need to approximate how much content to serve above the fold, use the Viewport-Width client hint. If you want to serve smaller images to smaller screens, use the If you need to know if the device has a mouse. supports hover and so on, there are Media Queries for those. (any-hover, any-pointer). You can use them to conditionally load CSS files if you want to squeeze every last drop of performance out. General responsive design should remove 99% of all uses cases that would "require" you to know what kind of device the user is using. |
|
I think you missed my point, it's not just about I repeat and expand the example I said in the previous comment. Apple iPhone XApple iPhone X has one screen. Below is a developer design example:
Samsung Galaxy FoldSamsung Galaxy Fold has more than one screen. Below is a developer design example:
As you can see it's more than responsive screen size or serving less data etc. It's a completely different user experience and code design based on the device type. This can be repeated for other device types as well. For example, I wouldn't code the same website for a smart phone and an Oculus Rift headset and just use a responsive design to allow both devices to work. The code would be changed a lot more to fully take advantage of the different device types and offer different functionality between them! Another example (GoogleBot using Chrome 100 vs a human being using Chrome 100 on a desktop computer): vs A common developer design is serving a GDPR cookie banner only to the human user and not to GoogleBot. Why not use feature detecting instead?There are lots of devices out there that you can't reply on using feature detection and need to use a client hints user agent instead (as a last resort). There are many IoT devices that create this issue! Scope to add even more device typesWhen a completely new device type is created in the future manufacturers can add a new value to the Hope my example makes a bit more sense, what I'm suggesting. |
|
I feel strongly like the ability to detect how many screens the page is rendered on should be a CSS Media query, if anything... I also feel like the rapid development of new devices will far outpace the specification's ability to enumerate them all, let alone all developers create a unique experience for each one. |
|
Turns out that there's a JavaScript API specifically for organizing windows across multiple screens: https://web.dev/multi-screen-window-placement/ |
|
I wanted to add a php Laravel code example for my previous comment. if (Request::header("Sec-CH-UA-Device-Type") !== "Bot" ) {
// Run the cookie banner code (bypass for bots)
}This header allows coding languages like php to do things, that Javascript can do (using feature detection apis). |
Love the idea of a "mobile" vs "desktop" user experience differentiator, but I worry that using
Sec-CH-UA-Mobile: 1is shortsighted.We all know that the type (and amount) of content served from one single website address needs to vary greatly depending on how the user will be able to consume it, and that the resulting experience is affected by many concerns such as bandwidth, touch screens, hands-free, and so on. Whatever the future holds (smartwatches, augmented reality, billboards with holographic sharks, etc) this spec needs to be flexible enough to handle it, else we can fully expect vendors to abuse the system to find workarounds.
We don't want Client Hints to become the new navigator.userAgent where we still see libraries trying to parse a combination of Brand, Platform, and Model to try to figure out which UX category this particular device/browser falls into. How do we avoid that?
This new spec needs to provide a direct and dependable answer to the question of which type of experience will best serve this client -- and, this field needs to accommodate future formats.
The text was updated successfully, but these errors were encountered: