Introducing Device-Stock-UA: a new request header and proposal

Readers' comments 27

Left under the original article, as archived.

• 

  Mağruf ÇolakoğluMonday, October 8, 2012 6:30:05 PM

  interesting but it will help to be consruct the one web.thanks.
  
• 

  dahulevogyreMonday, October 8, 2012 7:01:07 PM

  Sad.
  You're shouting yourself in the foot.
  
• 

  lucideerTuesday, October 9, 2012 12:03:47 AM

  
  
  

  Originally posted by webinista:

  But from a pragmatic point-of-view ... ...

  
  So-called "pragmatism" has brought us such wonders as document.all support, and CSS vendor-prefixes. This is such ridiculous false economy.
• 

  Tiffany BrownTuesday, October 9, 2012 9:52:08 PM

  Opera certainly supports and advocates a 'one web,' responsive approach. But we also have to contend with the reality of how developers build sites and, in turn, how that affects Opera users.
  
  As someone who preaches responsive development, it stings to admit that server-side user agent sniffing is the cowpath that we're paving here. When it comes to mobile-focused development, UA sniffing is a current practice and a widely-deployed practice, even if it isn't a best practice from our point of view.
• 

  PaulWednesday, October 10, 2012 4:30:51 PM

  How do I turn this off? This is more info than what I'm willing to part with.
• 

  Luca PassaniThursday, October 11, 2012 4:05:33 PM

  Hi Tiffany,
  
  Luca Passani of WURFL here.
  
  good practical post. My initial reaction was: wow, yet another header, but then again, this is better than no header at all and above all it is better than the dogmatic approach the firefox guys are taking.
  In total honesty, I don't like the negative tone against device detection in the post, but I acknowledge that this is in the tradition of Opera and what Opera has been preaching for some time. Question for you, isn't device detection just an extra tool in a developer's toolbox? and after all, doesn't it make sense that some companies want to control the user-experience on different devices to a level that is simply unobtainable with a responsive approach? so, why all this negativity against device detection?
  
  Please allow me to point to an article (disclosure: I'm one of the co-authors) that discusses this aspect in a bit more detail: http://mobile.smashingmagazine.com/2012/09/24/server-side-device-detection-history-benefits-how-to/
  
  Thank you and you have a great day
  
  Luca
• 

  Tiffany BrownThursday, October 11, 2012 9:45:41 PM

  Thanks for your comments, Luca.
  
  

  Originally posted by lucapassani:

  Question for you, isn't device detection just an extra tool in a developer's toolbox?

  
  
  Yes, it's a tool. Whether it's the best tool depends on your point of view. I think the cases of Opera Mobile and Mobile Firefox show the limits of relying on the user agent to infer the device. We'll once again agree to disagree on this point.
  
  That said we've proposed this header so that developers who use such APIs can optimize their sites for devices running Opera Mobile.
• 

  Tiffany BrownThursday, October 11, 2012 9:51:38 PM

  Originally posted by sabret00the:

  How do I turn this off? This is more info than what I'm willing to part with.

  
  
  I do not believe there is currently a way to disable this feature, Paul. But you're right. There should be. I will present this feedback to the mobile team. Thank you.
• 

  Patrick H. LaukeFriday, October 12, 2012 2:14:35 PM

  Originally posted by lucapassani:

  In total honesty, I don't like the negative tone against device detection in the post, but I acknowledge that this is in the tradition of Opera and what Opera has been preaching for some time.

  
  
  in total honesty, i didn't like the not-so-subtle "interestingly..." accusations of hypocrisy on the part of Opera in your Smashing article either, but there we go
  
  As ever, it's not any particular tool that is at fault, but how it's employed. And "One web" is not incompatible with device adaptation, as you seem to imply is Opera's stance.
  
• 

  Luca PassaniFriday, October 12, 2012 3:24:28 PM

  Originally posted by webinista:

  We'll once again agree to disagree on this point.

  
  
  we don't need to disagree. I think we are agreeing, right?
  
• 

  Luca PassaniFriday, October 12, 2012 3:40:02 PM

  Originally posted by karlcow:

  I think the "negativity" is more a question of the experience. Basically when working on the QA side of a client (bot, browsers, etc, any kind of user agents) company for a little while, you come to understand why device detection is a tool which is most of the time used to butcher user experience.

  
  
  I understand what you are coming from and it makes sense. Device-detection is a high-maintenance activity and, sometimes, companies do not realize that device-detection requires commitment and it comes with a cost. But the logic where the fact that someone uses device-detection poorly necessarily implies that device detection is bad is hardly acceptable. If I judged pizza by the US-style version I get served here, I would conclude that I don't like pizza, while I know perfectly that this is not the case
  
  Anyway, I think that it is totally legitimate (and even reasonable) that Opera recommends responsive approaches. What would not be reasonable is that Opera actively makes device detection harder (like Firefox is doing). That would be dumb and I am happy to see it is not happening. Let developers decide for themselves what the right tool for the job is.
  
  In short, I think I and Tiffany agree in general on the main point. I just happen to disagree on the tone with which device detection is presented. I find it sort of unfair, but then again, this is not a big deal at the end of the day.
  
  Thanks
  
  Luca
  
• 

  Luca PassaniFriday, October 12, 2012 3:41:35 PM

  Originally posted by patrickhlauke:

  in total honesty, i didn't like the not-so-subtle "interestingly..." accusations of hypocrisy on the part of Opera in your Smashing article either, but there we go

  
  
  Fair enough, but if you look at the writings of a guy called Bruce Lawson on Device Detection (or UA-sniffing, as he loves to call it), you will see that it's not exactly like we started it
  
  Luca
  
• 

  Bruce LawsonFriday, October 12, 2012 5:45:44 PM

  UA sniffing/ device detection - the term doesn't really matter.
  
  As Luca said, "I think that it is totally legitimate (and even reasonable) that Opera recommends responsive approaches. What would not be reasonable is that Opera actively makes device detection harder (like Firefox is doing). That would be dumb and I am happy to see it is not happening. Let developers decide for themselves what the right tool for the job is."
  
  I agree.
• 

  Patrick H. LaukeFriday, October 12, 2012 5:49:45 PM

  Originally posted by lucapassani:

  if you look at the writings of a guy called Bruce Lawson

  
  
  oh, are they available in a hardcover, leather-bound format?
  
  

  it's not exactly like we started it

  
  
  aw, bless. "but he started it, miss..."
  
• 

  Luca PassaniFriday, October 12, 2012 6:32:02 PM

  
  I am not following. Doesn't Bruce work for Opera?
• 

  Luca PassaniFriday, October 12, 2012 8:29:19 PM

  Originally posted by karlcow:

  I didn't want to reply about the pizza analogy. But it doesn't work.
  
  The issue is that users do not have choice.

  I guess this is where the fundamental difference is. at the cost of sounding brutal: who told you that users have the right to have a choice? my point is that content providers have a right to choose what users can access on a given device when it comes to the providers' content. And to be clear, content providers (i.e. copyright owners) can also freely decide that it is OK for their users to choose how to access their content, but then again, they may decide not to and retain that right to themselves. For example, my business model could be to sell video content. The fact that a browser hides the identity of the device would mean that my business model is impacted negatively (I no longer know that that "client" can access my content). If a company's business model is to control the user-experience, they have a right to do it. That right derives directly from the fact that they are the copyright owners and they are making an investment to present that content to web users, under the assumption that this will make their business sustainable. If users are given ways to work-around what the content owners has meant to present to them, the implication is that users are being made similar to hackers more than users. So, users have rights only as long as this does not override the rights of who provides the service/content with a significant investment.

  Originally posted by karlcow:

  Originally posted by lucapassani:

  Device-detection is a high-maintenance activity and, sometimes, companies do not realize that device-detection requires commitment and it comes with a cost.

  
  
  This unfortunately doesn't match the business reality of the Web. And if I follow you, you are advocating for a technology which makes sense for the 1%, not the 99%. Aka companies who will maintain their web sites for ever.

  Even assuming that your 1-99 split is right (I don't think it is, but for sake of discussion), your reasoning still does not hold water: yes, there is a minority of developers that will benefit from server-side detection. 99% won't, **BUT** using server side detection is **AN OPTION** and not an obligation. So, what sense does it make to make the life of developers who pick device detection harder by hiding a device make and model? the reason why I am advocating device detection is because I created WURFL 10 years ago and my company makes a living out of selling device detection (WURFL). Of course, I also think that device-detection makes sense in a lot of cases (the two aspects above are intimately mixed!). I guess that Opera is promoting responsive because it makes more sense in the moment the company provides a browser to desktop, tablets, smart-tvs and mobile devices of all kinds. I respect that. I would love to see that that respect is mutual. Thank you Luca
• 

  Patrick O'ReillyMonday, October 15, 2012 8:32:16 AM

  Originally posted by karlcow:

  The issue is that users do not have choice. You have the choice to go to a better pizza place to eat real italian pizza.

  
  Karl, with responsive design users don't get a choice, they must use the UI that fits their viewport. With device detection the user has the option of choosing a different experience by changing their user-agent string.
  However I do think you're missing the point of this new header, it is not to replace the current user-agent string, only to augment it with information outside the browsers control e.g does the device support the sms: URI or the smsto: URI, what is the device width and height (for times when the viewport size is deemed unreliable due to optional chrome elements). A user is still detected as using Opera on a mobile, therefore the user should get a mobile experience, now with the addition of information about the hardware and software of the users device.
• 

  Danny BaggsTuesday, October 16, 2012 8:36:35 AM

  I've scan-read the comments on this so apologies if my comment skips over something.
  
  Thumbs up on a pragmatic addition of the header.
  
  I would quite like to understand if we can get to the core challenge with this if we are talking about changing specs. We've seen the User-Agent header adapt itself over the years to accommodate OS and locale etc and perhaps this is another example of where we should influence things at this level.
  
  In my experience, the device detection solution has come about because the same information available through detection services is not available within the requests received by the server. Whether this is just pulling out the product and model or something more granular like device screen resolution or other attributes, there surely has to be a justification for trying to push this as additional meta data about the user agent within the core HTTP protocol.
  
  I know we want to be saving bytes etc but I'd rather have data I can use and strip out some of the legacy information that currently exists in User-Agent headers.
  
  Given this what may be a naive 'mile high' statement, what do people think about the plausibility of this?
• 

  lucideerSaturday, October 20, 2012 12:14:40 AM

  Originally posted by lucapassani:

  Question for you, isn't device detection just an extra tool in a developer's toolbox?

  
  It is exactly that, which is the crux of the problem. Giving developers "more tools" regardless of consideration for the repercussions of using (or more precisely misusing) those tools is not progress. Internet Explorer has, in the past, given front-end developers heaps and heaps of extra tools - ranging from "XML Islands" to CSS -ms-filter and many more. Yet it's a relatively well accepted at this stage that we might have been a little better off without these myriad extra "tools".
  The fact is, if there are best-practice and not-such-best-practice ways of implementing any given project, providing even more "not-such-best-practice" tools for developers to play with is rarely likely to improve the average quality of web projects out there, nor their long-term compatibility with browsers and devices (in particular minority browser/devices).
  
  

  Originally posted by brucelawson:

  "Let developers decide for themselves what the right tool for the job is."
  
  I agree.

  
  Given your previously stated views on CSS vendor-prefixes, as an example, I'm not surprised you agree with this, though I don't really understand either stance. Developers have - in practice - generally chosen the "wrong" tool for the job in the past. And Opera in particular has tended to bear the brunt of the fallout from those decisions, both in the cases of "made-for-IE" UA sniffing and the more recent "made-for-WebKit" prefixes.
  
  @webinista I must say the openness of your feedback on this is encouraging.
• 

  Luca PassaniSaturday, October 20, 2012 1:16:13 AM

  Originally posted by lucideer:

  Giving developers "more tools" regardless of consideration for the repercussions of using (or more precisely misusing) those tools is not progress.

  
  
  Wow, what a phenomenon we have here. You know better than everyone else, don't you?
  
  you are smart and you know how to do things right, right? Other developers are stupid and foolishly fall for tools that are not the right ones. They just don't get it.
  
  
  
  If this is where you come from, I am not even sure it is worth discussing with you, because you are obviously the bearer of a higher truth.
  
  
  
  If it made sense to discuss with you, I would explain how Opera is approaching all major content providers around the planet and a large chunk of those is telling them to make devices recognizable or they won't be able to optimize the user experience. But wait, no, UA-sniffing is wrong, no matter what. Mankind must resist the temptation of UA-sniffing, or web heaven will forever be lost. May TBL have mercy on our souls....
  
  
  
  Luca
  
• 

  lucideerMonday, October 22, 2012 9:18:44 PM

  Originally posted by lucapassani:

  You know better than everyone else, don't you?

  
  I do apologise if I'm coming across in any way pretentious or arrogant, I don't intend to.
  
  However my views on this issue aren't just some arbitrary dogma or individualistic idealism. The problems I've mentioned are extremely well documented - they have been described in great detail by many people who are far smarter and more knowledgeable than I am.
  
  Most importantly, Opera has probably been the most adversely affected of all browsers by these decisions in the past.
• 

  Luca PassaniMonday, October 22, 2012 10:48:49 PM

  Originally posted by lucideer:

  I do apologise if I'm coming across in any way pretentious or arrogant, I don't intend to.
  
  However my views on this issue aren't just some arbitrary dogma or individualistic idealism.

  OK. That's better. Looking at the link you reported, I can see where you are coming from: the big desktop web. My background happens to be somewhat different from it. I was doing mobile development in 1999, when the mark-up for mobile was WML and the first two WAP devices on the market had incompatible WML support (incompatible from the view point of mobile usability, that is).
  Yes, if we were in a world of desktop browsers alone, "UA sniffing" would obviously be an anti-pattern. On the other hand, if you start accounting for mobile devices, PDAs and tablets, one-size-fits-all, responsive HTML only works at the cost of cutting quite a few corners. This may be OK for some, but it is obviously NOT OK for others. In some cases, server-side detection is a great option for many, and it would be nice if that approach was respected (along with the professional who elect to adopt it).
  The fact that RWD only cuts it to a point will become obvious to everyone the day Smart TVs need to be accounted for (D-PAD navigation, different colors, larger fonts, less content to be displayed on the screen, etc.).
  Finally, a bit of empirical data: Facebook, Google and Yahoo go for server-side device detection when it comes to mobile. This must necessarily mean that server-side detection is not that bad after all, right? Luca
• 

  lucideerTuesday, October 23, 2012 11:04:05 PM

  Originally posted by lucapassani:

  In some cases, server-side detection is a great option for many

  
  I'm not against server-side detection insofar as the common denominator between the proposal in this blog post and examples of other poorly-thought-out proposals is not server-side nor client-side.
  
  UA sniffing in Javascript has probably been far more prevalent an issue than server-side UA-sniffing ever was, and CSS vendor-prefixes are an entirely client-side technology.
  
  The aspect of this I'm against is not server-side detection, it's device and browser detection. A vendor-oriented approach to web-development is the reason monopolies are made and minorities excluded.
  
  Projects like WURFL are highly impressive in their scope, but if we're at the standardisation stage (Device-Stock-UA being a proposed standard), why not propose server-side feature-detection instead - mobile/device-relevant versions of Accept-* headers - and actually make it easy for developers to do things the "right" way, instead of providing "extra tools" that involve potentially checking against 250+ Android device UAs, before you even get on to other OSes.
  
  For now, in the absence of any such standard, things like "Adaptive Images" and other RESS-based approaches seem like the best we can do. I acknowledge there are many issues with these, but I don't think this will solve them.
• 

  Luca PassaniWednesday, October 24, 2012 2:05:15 AM

  Originally posted by lucideer:

  I'm not against server-side detection insofar as the common denominator between the proposal in this blog post and examples of other poorly-thought-out proposals is not server-side nor client-side.

  Thank you for the clarification. Appreciated. I respectfully observe that this post is about Opera Mobi, Opera Mini and a mechanism that Opera is introducing to make server-side detection easier for developers that really want to adopt it. It is not about the desktop web. I agree that Javascript-based UA sniffing is a very slippery slope.

  Originally posted by lucideer:

  
  Projects like WURFL are highly impressive in their scope, but if we're at the standardisation stage (Device-Stock-UA being a proposed standard), why not propose server-side feature-detection instead - mobile/device-relevant versions of Accept-* headers - and actually make it easy for developers to do things the "right" way,

  If the issue was agreeing on standards, the problem would have been solved a long time ago. The real problem is that different stakeholders in the mobile ecosystem do not agree on who is allowed to do what. Users may have an idea of what they want (or not). content providers have their own ideas. Device manufacturers will sometimes listen to users and others just blindly install a browser that takes some decisions. We even saw network operators try to hijack the user-experience trying to get a share of the mobile content pie (vodafone-novarra are the keywords there). This is the reason why agreement has never been found. At one point, even Opera had opted to go for the desktop CSS while running on a mobile device (thus disrespecting developers). At the same time, Opera-Mini did send some of the device feature in one of the headers, but that info was not very reliable.
  The reality is that the discussion about who has the right to do what on the web has never been resolved. On the desktop this question was essentially immaterial. In mobile, all the ambiguity has exploded in the developers' face.
  What WURFL does is just to provide a simple API on top of something that would look very ugly and complex if watched closely.

  Originally posted by lucideer:

  instead of providing "extra tools" that involve potentially checking against 250+ Android device UAs, before you even get on to other OSes.

  Seriously. WURFL has existed for over 10 years. You are not assuming that each and every request is matched against 8000 UAs each time, right? Under the hood, WURFL is a lot smarter than that Luca
• 

  lucideerMonday, October 29, 2012 4:28:09 PM

  Originally posted by lucapassani:

  You are not assuming that each and every request is matched against 8000 UAs each time, right?
  Under the hood, WURFL is a lot smarter than that

  
  Not assuming that at all. My comment above on checking against 250+ devices related to the overhead of maintaining WURFL in the first place, not using it in production.
  
  The issue with WURFL is not perf. overhead, but rather that it acts as a middleman for what I believe devices and user-agents should have standardised and be providing directly. What WURFL provides is "doing it right" in a lot of ways imo, but it's filling a hole left by UAs that instead seem more focused on providing developers with vendor-specific, rather than feature-specific metadata.
  
  Not everyone uses WURFL, and if you're being exclusively provided with vendor-specific data upon which you base your server-side logic, your development is inevitably going to be vendor-specific and you end up having sites designed only for WebKit/iPhone/Samsung/[insert whatever popular product] instead of having websites designed with specific screen-sizes, DPIs, event-support, etc. in mind.
• 

  Luca PassaniMonday, October 29, 2012 10:13:50 PM

  Originally posted by lucideer:

  What WURFL provides is "doing it right" in a lot of ways imo, but it's filling a hole left by UAs that instead seem more focused on providing developers with vendor-specific, rather than feature-specific metadata.

  I suspect that now that you have clarified your position, we agree more than anything else.
  I would agree that WURFL is a very specialized tool, probably expensive (if compared to the traditional cost of web development) and that its value is directly proportional to the shortcomings of current UAs and the information (or lack thereof) they provide about the features of the client, a gap that could be filled by better (or better applied) standards in the future.
  
  So, I think we can happily close this discussion by agreeing that server-side detection is a tool, that most web developers are probably better served by a responsive approach, but a different approach is also legitimate and deserves respect. Do we agree?
• 

  ChirpieWednesday, November 14, 2012 8:03:37 AM

  Originally posted by lucapassani:

  you are smart and you know how to do things right, right? Other developers are stupid and foolishly fall for tools that are not the right ones. They just don't get it.

  Yes, that is exactly the case.
  
  The web proves that web developers are generally incompetent, stupid, clueless, and lazy.