Re: [whatwg] Adding a property to navigator for getting device model
Original Message: On 24 Sep 2014 20:40, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them? Why don't we provide a better structure and not just a random string. For example: deviceID, browserID, renderingEngineVersion ... Not sure what else would be useful to group actions that the developer needs to take. Haven't looked in detail. On top of that, firmware version would be helpful, since most HWA/WebGL bugs are caused by driver bugs that directly relate to the firmware version. Sangwhan
Re: [whatwg] Adding a property to navigator for getting device model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Oops, misunderstanding all around, sorry about that... Maybe I can try and explain. Here's how I would define the various UA-sniffing techniques : 1 - Client-side : - Parse : 'read' and interpret 'known' elements in appName, appVersion etc and return results. Returns only information contained in user-agent string. - Query : APIs and DOM 2 - Server-side - Parse : same as above, but no API or DOM directly at hand - Map : 'known' elements [model id] in the user-agent string allow it to be mapped to a 'record' in a device database which returns properties of the identified device. 'Real' device. Returns information not contained in user-agent string. - Probe : inject script that does the client side queries and returns the results. DeviceMap parses and maps. - From a strict interpretation [by no means shared by all] it follows that a desktop in the DeviceMap context is not a device. These 'devices' have become generic, defined by their software rather than by their hardware specs, so OS, 'browser', rending engine (if any !) and their versions, contained in the user-agent string, are sufficient to parse on either side. Here the client appears to have the clear advantage. Most devices have a tendency to become 'desktops' in that sense and mapping or looking up the Model Id in some database at some point no longer adds anything relevant. However, this assumes all requests come from 'desktops' in the above sense. That may be true in many cases most of the time today, but unless you do either traffic analyses on that level or server-side detection, you will never know. And without wanting to get overly dramatic : we do not want to create a new Best viewed with 'desktop' ;-) I think that's where server-side detection has the clear overall advantage. It makes no such assumptions and being the 1st the 'see' the user-agent string and it can 'equip' the client with the right tools [JS, CSS] for the job, relying on DOM, APIs etc, as well as handle requests from devices in the strict sense. Given that the cost server-side is negligible -- currently DeviceMap's just shy of 100 *micro*-second per user-agent string, with a microscopic code base and zero dependencies -- and given the added benefits such as security -- I would go so far as to say : consider default-denial for the weird stuff -- at some level, server-side is a must. I guess that's why we UA-sniffers tend to over-react when there's talk of the 'our' precious user-agent string.[Sorry !] It's not only because sigh, we're so misunderstood [there, there] but because of the far reaching consequences even minor changes can have [like IE dropping it's signature MSIE] on some systems. I hope that clears up a few things. In the current context, in an ideal world, maybe some way can be found to make the old X-Wap-Profile idea workable. [http://www.ducis.net/Miri/UAProfile] Either the device loading it's own 'UAProfile' [or variant thereof] and exposing it via an API -- but that's a bit 'rich' I suppose -- or just a property with a valid URI to a parse-able, standard, spec-sheet/string/object : JSON for the client and some 'cool' format for the server [Proto-buf ?]. Remove the RDF from UAProfile and you're halfway there, the technical part anyway. Surely that can be of some use to the Internet of Things we hear is around the corner. The Internet of Things, sounds like device to me... But I repeat, as long the user-agent string continues to contain the elements mentioned above, sane 'standards' are applied and there is no fiddling with it's truthiness, I currently see no need to add properties. Getting an UAProfile-protocol working would be stellar, something I'd gladly spend time on. Kind regards, esjr PS : please send me you ua-strings, long lists of ua-strings... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUL55xAAoJEOxywXcFLKYc2DkH/AjbSY1Ui/Bg9IvSforKGMnI gVA+ZhdXNKTnwGOelwrfl5HYlAjdXYXptTzb5oeTVLAxBphqcI2/tg1eTh3vIop4 9LWxat6nm906NKQTM9eKB66J0M6BkYtqMwArvyfmtOaUIXsiqE1n/UVuB3sOZI0r wyofzel7KnSZQib01hVsffYN5e+zsrGgo2MLMv6Dw1hFoj2lBIe1Cgce2khMqESb R5RakA7/jOxwF0ujI188Gyrh0OSwQ8pjwvlx9DHowZOaX93NqUNea4mVHZWYizGN /vKTcOI61PA0ZTXs25IaOkkjVQwrMF0FJqtW04BGsyE4/Uq0Q8jWI1cfyo9JjEQ= =36x0 -END PGP SIGNATURE-
Re: [whatwg] Adding a property to navigator for getting device model
On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. ses...@ducis.net wrote: If you are interested in the intricacies of UA-sniffing, client and server-side, the use-cases, the esoterica etc I'll gladly contribute what I can. I guess the question at hand is: What are the client-side situations when people need to do look up device capabilities using UA-sniffing and DeviceMap? I.e. when can't they use JS code and the APIs exposed through the DOM to detect what capabilities are available, and instead they have to look up these capabilities in DeviceMap? For server-side UA sniffing these situations are much more clear since the server has information to *much* less information. I.e. the server only has access to the headers that the browser sent. However JS code running in a browser has access to a much richer amount of information. So when does it need to use DeviceMap? / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 09:38, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. ses...@ducis.net wrote: If you are interested in the intricacies of UA-sniffing, client and server-side, the use-cases, the esoterica etc I'll gladly contribute what I can. I guess the question at hand is: What are the client-side situations when people need to do look up device capabilities using UA-sniffing and DeviceMap? I.e. when can't they use JS code and the APIs exposed through the DOM to detect what capabilities are available, and instead they have to look up these capabilities in DeviceMap? For server-side UA sniffing these situations are much more clear since the server has information to *much* less information. I.e. the server only has access to the headers that the browser sent. However JS code running in a browser has access to a much richer amount of information. So when does it need to use DeviceMap? / Jonas Hi, I fear you greatly oversimplify matters. For starters, 'responsive design' is not the only use case and secondly it is not the case that the server is at a disadvantage information wise, as a matter of fact, once a device is linked to a known UA-profile the opposite is very much the case. I must say I'm somewhat taken aback by this dismissive attitude. esjr -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJULpIAAAoJEOxywXcFLKYceS0IANCH35fbTl3s/VkwOsPVkMHN 4bYNBQymQEsO0mv81825cKRoClOcdkx/nZUbvTS0qd4C8OgNDUCN/D5Ryj8kvwMx OCjraKnwkbNobMvoxKjR+OiLi1SiipjP15jdnsi+q9NlgQ+vpjHxm+s8jWrUZ+Kj h75Pe3QzUKyLq716WJYLz06fvNhMeZ2+m0eDIGtS7+5KRvnfn+fd8m0lDmFNTNQU Zhb+indcptliEF3awxqsbmTQE1MftTb8Ol4mCmYOGCHcQASOrPkusThMqekwiOqK 4iWECIpHeLDhA4Q+wloYHrI0nABSQgKZYaUi2PGS1Mgy+mGRdT+VwiObwhnZF6Y= =k32y -END PGP SIGNATURE-
Re: [whatwg] Adding a property to navigator for getting device model
On Fri, Oct 3, 2014 at 5:09 AM, eberhard speer jr. ses...@ducis.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 09:38, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. ses...@ducis.net wrote: If you are interested in the intricacies of UA-sniffing, client and server-side, the use-cases, the esoterica etc I'll gladly contribute what I can. I guess the question at hand is: What are the client-side situations when people need to do look up device capabilities using UA-sniffing and DeviceMap? I.e. when can't they use JS code and the APIs exposed through the DOM to detect what capabilities are available, and instead they have to look up these capabilities in DeviceMap? For server-side UA sniffing these situations are much more clear since the server has information to *much* less information. I.e. the server only has access to the headers that the browser sent. However JS code running in a browser has access to a much richer amount of information. So when does it need to use DeviceMap? / Jonas Hi, I fear you greatly oversimplify matters. For starters, 'responsive design' is not the only use case and secondly it is not the case that the server is at a disadvantage information wise, as a matter of fact, once a device is linked to a known UA-profile the opposite is very much the case. I must say I'm somewhat taken aback by this dismissive attitude. I fear that you must have somehow misread my email above. I did intend to focus only on responsive design. In fact, I did not mention responsive design at all. I instead tried to ask broadly for use cases where people use DeviceMap since you graciously offered to help with providing them. It was also not my intent to be dismissive of anything. Neither people, use cases, software stacks, requirements or opinions. I'm not sure what it is that you feel that I was dismissive of but I apologize and can only assure you that that was not my intent at all. I did however want to specifically focus the discussion about client side practices and use cases. The reason for this is not that I feel like server side practices and use cases are not important, but rather that the topic of this thread is whether to add a clicent-side property specifically to make it easier for people that use things like DeviceMap on the client side. It still does seem to me that client side logic running in a browser has access to a richer set of information about that browser than server side logic which received a network request from that browser. Simply because the client side logic has access to the same information about the browser as the server side does. But in addition it can use JS and the DOM to check for existence or non-existence of hundreds of APIs, as well as use a handful of APIs that were specifically designed to expose information about the browser. However I could very well be wrong about that. But that is simply due to being uninformed and had no origin in malice or uncaringness at all. I could see for example that server side logic has much more efficient access to databases such as DeviceMap. I had thought that client side logic could access the same type of databases using network requests, but perhaps that is often not practical due to performance constraints. So I definitely imagine that I could be wrong about which environment effectively has access to better information. But I'd rather not guess at where I made an error in logic and would instead appreciate if you point out where I'm making the wrong assumptions. / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
On 3 Oct 2014 14:25, eberhard speer jr. ses...@ducis.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Maybe you missed my initial message : I am a contributor [IPMC] to the Apache DeviceMap Project. [http://incubator.apache.org/devicemap/] DeviceMap does expert UA-sniffing both client and server-side. Apache Cordova on the other hand is a mobile development framework which uses HTML5/CSS/Javascript and via plug-ins allows access to device features not or not consistently accessible [yet] via HTML5. The whole is packaged in a wrapper targeting a specific platform [iOS, Android,...]. So, no 'UA-sniffing' going on there to format content, but HTML5/CSS and javascript running inside a container which via the abstraction of a WebView and plug-ins allows access to things like accelerometer, camera, address-book etc. If you are interested in the intricacies of UA-sniffing, client and server-side, the use-cases, the esoterica etc I'll gladly contribute what I can. Please explain more. We're keen to learn about your experience. Silvia.
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
On Fri, 3 Oct 2014, at 04:39, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? I would love to know actually. Silvia, do you have any insights? -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
On 3 Oct 2014 04:45, Mounir Lamouri mou...@lamouri.fr wrote: On Fri, 3 Oct 2014, at 04:39, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? I would love to know actually. Silvia, do you have any insights? I've not used it - maybe others have some insights. Best Regards, Silvia.
Re: [whatwg] Adding a property to navigator for getting device model
On Fri, 3 Oct 2014, at 05:50, Silvia Pfeiffer wrote: I've not used it - maybe others have some insights. Sorry about that. I misread your previous messages and presumed that you were related to the Cordova project. -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Maybe you missed my initial message : I am a contributor [IPMC] to the Apache DeviceMap Project. [http://incubator.apache.org/devicemap/] DeviceMap does expert UA-sniffing both client and server-side. Apache Cordova on the other hand is a mobile development framework which uses HTML5/CSS/Javascript and via plug-ins allows access to device features not or not consistently accessible [yet] via HTML5. The whole is packaged in a wrapper targeting a specific platform [iOS, Android,...]. So, no 'UA-sniffing' going on there to format content, but HTML5/CSS and javascript running inside a container which via the abstraction of a WebView and plug-ins allows access to things like accelerometer, camera, address-book etc. If you are interested in the intricacies of UA-sniffing, client and server-side, the use-cases, the esoterica etc I'll gladly contribute what I can. Regards, eberhard speer jr. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJULiUDAAoJEOxywXcFLKYc/BYH/RsrgBLLQHcgMfoEp2mU8bKW u5Hrgb1mEIXNp3GO41JW4dX7J9rxTBYlrwMOnznLq2GwM7awiWBVPYvL4cgokAvY xc3lesplBbNONCNq5xNPWHfDHTfxewjyOSPEnH9M/VyFEVsafxRKbMqUdlBLV44c Cmp27o8NDwKih/NQGYEzIfvCfv9l3jR95BpCpGQefq+NdVu4M+PHPnI04VMA3SYZ k2Yl/M0iBIzID3mhLUivTm2xO0OrP6ZqJBXXdpi1FrPzCk9e/I7ahtzJA8V1OwQM O0KsTwf3zlvLOr75SVhlCdOf4/tWs2/zbu7/KSjLSZZLfdsdNPeMnd6rcSo8j2o= =SMaM -END PGP SIGNATURE-
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, Oct 1, 2014 at 7:43 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. I was under the impression that we are mostly talking client-side so that JavaScript can adapt the choice of features to what is available in the browser. Server-side information is merely a side effect (which, of course, is exploited for marketing and other purposes, but not something we can really avoid). Silvia.
Re: [whatwg] Adding a property to navigator for getting device model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I understand the focus is on the client-side, understandably, but please note that on both client and server side UA sniffing is used for 'responsive' design. On the server side for example it can be used to route requests or format responses. So, the server side information is definitely not a side-effect exploited [?] for marketing and other purposes. What someone uses the results of their traffic analyses for is separate from the fact that traffic analyses is a vital tool. I disagree with the notion that UA sniffing is some 'exploit' that is not something we can really avoid. It seems to me RFC 2616 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43] is pretty clear on that. So, I repeat : I would agree there is no immediate need for new or extra structures; the vendors just applying the existing 'standards' and not abusing the UA-string for 'marketing' purposes, would go a long way. esjr On Wed, Oct 1, 2014 at 7:43 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. I was under the impression that we are mostly talking client-side so that JavaScript can adapt the choice of features to what is available in the browser. Server-side information is merely a side effect (which, of course, is exploited for marketing and other purposes, but not something we can really avoid). Silvia. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUK9bmAAoJEOxywXcFLKYcEjUH/iQCxSvyMO3FOopkSauGb0yN wCgckWer46xMsUgXFMbcaokq0JB8sN3J8pdzyb3bh1o2bVhFAXkNltdkooKHQ3/2 Y/lKJk80urkpUyO7JJHZ9ji5/Hwa3D5eKaJsejDqvbUrOmwoY7JwE41qRYuTIDQZ 0MU23tbPZ//lK1pOHGX+dgk9HoqE4pxggufdVJ/TWpKSdZUDVvG8WetfYXKoYU1f FVmbIPzJP0LuWN404gQV21Rh4un3faKFKIVUmKWoXTe+mJusOpFwS2ur76um8pAV 0LXQ5VrAeCjbhbbSDgX8j7pNRd629WgksL9IxlYntCotQmSOiozgo/RPvAp1qYo= =1hom -END PGP SIGNATURE-
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
Am I right that a lot of the mentioned problems stem from old Android devices with browsers that have been shoddily hacked and broken by the manufacturers (presumably in the name of making improvements)? For example I remember specific versions of some Samsung Android device browsers would freeze during touches, ruining canvas games. I suppose the intent is to detect this OS version and affected devices and display a warning perhaps (there weren't any workarounds to that as far as I know). At least with Android both the web view and OS browser is moving to Chrome, and manufacturers don't hack it to pieces any more. I'm not aware of any other platforms where you get model-specific hacks/modifications/bugs, so maybe this problem is going away by itself? I would suggest breaking out every token of the UA string to its own navigator property, but that's already failed - for example every browser already reports navigator.appName as Netscape, presumably for long-standing backwards compatibility. The UA string, while getting ridiculously ugly these days, can be extended backwards-compatibility, which I guess is a feature. Ashley On 24 September 2014 11:34, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: On Wed, Sep 24, 2014 at 10:38 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Jonas Sicking jo...@sicking.cc writes: In some cases websites uses the UA strings for bad reasons (this is how we've always done it), in other cases because it's literally the best way for them to create a good user experience for their users. I have seen lots of the former and only some of the latter (software downloads for a specific OS / hardware come to mind). Please list examples of “good user experience” for which hardware is needed. O, I could write a book about this, but let's scratch the surface: * Disable animations for specific devices where they're janky / crash / don't work, as in the view doesn't even end up in the correct end state of the animation. * Force a reflow on devices where the UA fails to repaint when the transform matrix is updated. Forcing reflow on all devices would be a massive performance degradation on all devices, whereas not forcing reflow at all would lead to completely broken experience on a specific device. * Override feature detection, e.g. one older Galaxy Note device reported in the webview that transform/transition in document.createElement(div).style is true, but using the unprefixed property didn't work. Using both didn't work either because it selected the unprefixed setting which it didn't actually support. Android 2.3 and IE9 support simple CORS XHR but can't be feature-detected without making a request. * Apologize from users for whom the experience is irrevocably broken (Android 4.0.x), or recommend them to switch browsers (doesn't help if you're in a webview). * Apply z-index hacks that fix the layering on specific devices while breaking it on others. * Request user interaction for something that would on other UAs be OK to do without user interaction, e.g. creating an AudioContext (silently fails on iOS unless in response to a user interaction). * (Server-side) approximate screen size to deliver the correct critical rendering path. * (Server-side) approximate screen size to deliver an approximation of correct image sizes before for example a picture polyfill kicks in. * (Server-side) approximate screen size to deliver an approximation of a grid system as CSS that matching the layout before JS kicks in. * (Server-side) deliver only the needed polyfills. This is just stuff that I remember off the bat without looking at any specific codebase. I might add more later if necessary. […] I'm just suggesting that on platforms where various browsers are *already* exposing a device model through the UA string. That we expose the same information in a more easy-to-consume property in the DOM. My suggested name would be navigator.deviceModel Thoughts? This would lead to yet another entry point for device discrimination. Please do not make this easier. Yes, we can choose to not make developers lives easier, sit in an ivory tower looking at a perfect world where every browser behaves exactly according to standards with exact same performance characteristics and shame developers when they desperately try to drive people to use their native apps instead of their websites, or we could try to understand the reasons why developing good experiences for the web is such a pain that they'd rather push their users away from the product of their sweat and tears. You could argue that the developers shouldn't have to do this - that it's on the browser/device manufacturers - and you'd be right. However that's not much consolation to the developers when 20% of their user base is on a device that will never get updates and has a mostly broken experience. Or when a major
Re: [whatwg] Adding a property to navigator for getting device model
Ashley Gullen ash...@scirra.com writes: Am I right that a lot of the mentioned problems stem from old Android devices with browsers that have been shoddily hacked and broken by the manufacturers (presumably in the name of making improvements)? Key words “old devices” and “shoddily hacked”. The first lets me think that new features could never solve old problems – after all, if the UAs would be updated, one could just fix the bugs that existed. The second lets me think that no one – including site authors – would implement device detection and appropriate discrimination correctly. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
Jonas Sicking jo...@sicking.cc writes: In some cases websites uses the UA strings for bad reasons (this is how we've always done it), in other cases because it's literally the best way for them to create a good user experience for their users. I have seen lots of the former and only some of the latter (software downloads for a specific OS / hardware come to mind). Please list examples of “good user experience” for which hardware is needed. […] I'm just suggesting that on platforms where various browsers are *already* exposing a device model through the UA string. That we expose the same information in a more easy-to-consume property in the DOM. My suggested name would be navigator.deviceModel Thoughts? This would lead to yet another entry point for device discrimination. Please do not make this easier. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, Sep 24, 2014 at 10:38 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Jonas Sicking jo...@sicking.cc writes: In some cases websites uses the UA strings for bad reasons (this is how we've always done it), in other cases because it's literally the best way for them to create a good user experience for their users. I have seen lots of the former and only some of the latter (software downloads for a specific OS / hardware come to mind). Please list examples of “good user experience” for which hardware is needed. O, I could write a book about this, but let's scratch the surface: * Disable animations for specific devices where they're janky / crash / don't work, as in the view doesn't even end up in the correct end state of the animation. * Force a reflow on devices where the UA fails to repaint when the transform matrix is updated. Forcing reflow on all devices would be a massive performance degradation on all devices, whereas not forcing reflow at all would lead to completely broken experience on a specific device. * Override feature detection, e.g. one older Galaxy Note device reported in the webview that transform/transition in document.createElement(div).style is true, but using the unprefixed property didn't work. Using both didn't work either because it selected the unprefixed setting which it didn't actually support. Android 2.3 and IE9 support simple CORS XHR but can't be feature-detected without making a request. * Apologize from users for whom the experience is irrevocably broken (Android 4.0.x), or recommend them to switch browsers (doesn't help if you're in a webview). * Apply z-index hacks that fix the layering on specific devices while breaking it on others. * Request user interaction for something that would on other UAs be OK to do without user interaction, e.g. creating an AudioContext (silently fails on iOS unless in response to a user interaction). * (Server-side) approximate screen size to deliver the correct critical rendering path. * (Server-side) approximate screen size to deliver an approximation of correct image sizes before for example a picture polyfill kicks in. * (Server-side) approximate screen size to deliver an approximation of a grid system as CSS that matching the layout before JS kicks in. * (Server-side) deliver only the needed polyfills. This is just stuff that I remember off the bat without looking at any specific codebase. I might add more later if necessary. […] I'm just suggesting that on platforms where various browsers are *already* exposing a device model through the UA string. That we expose the same information in a more easy-to-consume property in the DOM. My suggested name would be navigator.deviceModel Thoughts? This would lead to yet another entry point for device discrimination. Please do not make this easier. Yes, we can choose to not make developers lives easier, sit in an ivory tower looking at a perfect world where every browser behaves exactly according to standards with exact same performance characteristics and shame developers when they desperately try to drive people to use their native apps instead of their websites, or we could try to understand the reasons why developing good experiences for the web is such a pain that they'd rather push their users away from the product of their sweat and tears. You could argue that the developers shouldn't have to do this - that it's on the browser/device manufacturers - and you'd be right. However that's not much consolation to the developers when 20% of their user base is on a device that will never get updates and has a mostly broken experience. Or when a major manufacturer releases the hottest new device ever and then the web app developers' brand is taking damage because of partnerships with that manufacturer, while having a completely broken experience on their flagship product. We can tell them the future will be better with ever-green browsers, but that doesn't mean that we shouldn't provide the developers with the best tools possible to deal with the situation when it goes sour. Of course this leads to also bad things when the next breakthrough in devices using the web is made and suddenly everyone is targeting designs to a specific device again (because it's the only one with certain characteristics), but one way or another they'll manage to do it anyway, whether we make it hard or not. However, the harder we make things, the harder it becomes to change the workarounds for these things to be more generic and thus we'll just slow down progress. - Jussi -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them?
Re: [whatwg] Adding a property to navigator for getting device model
On 24 Sep 2014 20:40, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them? Why don't we provide a better structure and not just a random string. For example: deviceID, browserID, renderingEngineVersion ... Not sure what else would be useful to group actions that the developer needs to take. Haven't looked in detail. Silvia.
Re: [whatwg] Adding a property to navigator for getting device model
Silvia Pfeiffer silviapfeiff...@gmail.com writes: On 24 Sep 2014 20:40, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them? Why don't we provide a better structure and not just a random string. For example: deviceID, browserID, renderingEngineVersion ... Not sure what else would be useful to group actions that the developer needs to take. Haven't looked in detail. This can and will lead to undue discrimination. Not using any of IE, Firefox, Safari or Chrome can already be enough to not be locked out of a site that would work if only a check for a UA string was not there. What developers actually do want to know is if some devices have some capabilities. That something feature detection provides. The UA version or hardware almost always constitutes a hidden query for something else. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Adding a property to navigator for getting device model
On Sep 24, 2014 3:40 AM, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them? If we do, is that any worse than having the string in one place? If we are stuck with having this information exposed to the web (which currently is looking more likely than not), then I'd rather that authors had an easy time doing so. / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
On Sep 24, 2014 3:51 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On 24 Sep 2014 20:40, James Graham ja...@hoppipolla.co.uk wrote: On 24/09/14 02:54, Jonas Sicking wrote: In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. It's not entirely clear this won't just leave us with the device string in two places, and unable to remove either of them. Do we have any evidence that the sites using UA detection will all change their code in relatively short order, or become unimportant enough that we are able to break them? Why don't we provide a better structure and not just a random string. For example: deviceID, browserID, renderingEngineVersion ... Not sure what else would be useful to group actions that the developer needs to take. Haven't looked in detail. I'm supportive of exposing any information that we are already exposing through the UA string. But most of it already is. Through various other properties on the navigator object. / Jonas
[whatwg] Adding a property to navigator for getting device model
Hi All, Right now all mobile browsers expose the mobile device model through the UA string. There are lots of us, me included, that wish that we could stop doing this. The problems are at least: * Exposes more finger printing bits. (I'm aware that people feel differently about how big of a problem this is). * Lots of websites key various things off of UA string, even when they don't care about device models. These will not recognize the UA if it's even slightly off from what they know which can cause them to fall back to a generic HTML4 (or even WAP) version of the website. * Parsing just the device model identifier from the UA string is error prone. * Encourages websites to do feature detection through UA detection, rather than through, well, feature detection. In some cases websites uses the UA strings for bad reasons (this is how we've always done it), in other cases because it's literally the best way for them to create a good user experience for their users. I've tried for a while to try to figure out features that we can add to the web platform to try to slowly move away the industry from this practice. But it's a very slow process. And actually getting websites to stop using the UA string in this manner is going to be even slower as it's very entrenched in the mobile industry. In the meantime, I'd like to add a property to window.navigator to enable websites to get the same information from there as is already available in the UA string. That would at least help with the parsing problem. And if means that we could more quickly move the device model out of the UA string, then it also helps with the UA-string keying thing. Obviously I'm not suggesting that UAs be required to set this property. At least Mozilla would not set this property in distributions where we are not currently sending a device model in the UA string. I'm just suggesting that on platforms where various browsers are *already* exposing a device model through the UA string. That we expose the same information in a more easy-to-consume property in the DOM. My suggested name would be navigator.deviceModel Thoughts? / Jonas
