Closed Bug 850769 Opened 7 years ago Closed 6 years ago

User Agent override including information regarding vendor/model about the device

Categories

(Firefox OS Graveyard :: Gaia, defect)

x86_64
Windows 7
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED WONTFIX
blocking-b2g -

People

(Reporter: dpalomino, Unassigned)

References

Details

Hi, 

This has been previously discussed by mail (thanks to Jonas and Lawerence for all the info provided). 

General UA is: 
Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

However for some specific (and problematic) sites, a UA override is planned (for those sites not compliant with generic UA), to avoid a bad user experience. 

For many carrier's content's portal (and even some services), the UA should be provided containing information regarding vendor and model device. It is intended to provide a list of domains where this override should be performed. 

Not making this exception would mean many carrier services stop working. 

Exact vendor/model string should be provided for the vendor. 

Thanks!
David

PS: BTW, I didn't find Jonas' bugzilla alias, could you please cc him?
Nominating it as tef?, as this is critical for commercial launch.
blocking-b2g: --- → tef?
(In reply to David Palomino [:dpv] from comment #0)
> Not making this exception would mean many carrier services stop working. 

I would prefer to discuss the limitations with the carriers so that we can understand the problem from their perspective and work towards a time where these overrides can be removed. 

> Exact vendor/model string should be provided for the vendor. 

Who will provide this information?
(I'll let Daniel make the tef+/- call here)
Flags: needinfo?(dcoloma)
(In reply to Lawrence Mandel [:lmandel] from comment #2)
> > Exact vendor/model string should be provided for the vendor. 
> Who will provide this information?

we probably need a bug like this per OEM and then we can include the associated OEMs to reveal their model number. Or not sure if Daniel/David will consolidate it and provide a full list of devices that's needed on your services
Sounds good Joe. To repeat my earlier request, it would be great to understand from the OEM why each site requires the override and can't function with the default UA.
Woah, woah, woah. Screwing with a user agent and the overrides is not something to be taken lightly. I thought there was a conclusion in the discussion thread that talked about this with Jonas that decision was to *not* do this - people were generally against changing the user agent for vendor/model needs, as this can hurt the overall web.

Putting needinfo on our module owner, Gerv, for a judgment call here. But I'm really strongly against doing this.
Component: Gaia::Browser → Gaia
Flags: needinfo?(gerv)
(clearing tef? flag as we have not arrived at a consensus yet so this bug is not ready for tef? consideration, but comment 3 still holds for the next re-nom)
blocking-b2g: tef? → ---
(In reply to Michael Vines [:m1] [:evilmachines] from comment #7)
> (clearing tef? flag as we have not arrived at a consensus yet so this bug is
> not ready for tef? consideration, but comment 3 still holds for the next
> re-nom)

This decision really is up to the user agent module owner, not TEF. We do have module ownership at Mozilla for these type of decisions and I'd expect we would stick by them for good measure. Otherwise, I fully expect a situation where someone will try to land something, someone will move fast to back out the patch without notice, and loud arguments will start up. We literally had a situation like this happen recently and I'd rather not have a repeat of this problem.

Reference doc for module ownership on user agent decisions:

https://wiki.mozilla.org/Modules/All#Content_HTTP_Headers
What I had discussed with Beatriz previously was to add an exception for the Vivo websites that needed device information in order to function properly.

We have discussed at length and reached agreement not to do a general change of the UA string to include device information, but instead to only make exception for as short list as possible of Telefonica and Vivo websites that need it in order to function properly.

It should definitely be viewed as a temporary exception to customize the UA string though. So questions about what specifically is causing these websites to need a custom UA string definitely seems relevant. Otherwise we won't be able to get rid of these exceptions.

Also note that it's in the carrier services interest to stop using these exceptions since these exceptions will cause problems for them. For example libraries such as WURFL probably won't work for these websites since WURFL won't recognize the custom UA string. Likewise, documentation for Firefox OS will reflect the "normal" UA string, and not exceptions.

That said, I don't have any problems with adding UA customization for carrier websites that are broken. This seems no different from our normal policy of adding exceptions for high-profile websites and then work towards removing the exceptions over time. It's just that these websites are high-profile for different reasons than other exceptions we've added.
Jason - Like Jonas said, this request is for UA overrides for a specific set of sites. As I said in comment 2, I want to understand why these overrides are required. We want to remove each override as soon as is possible.

I'm going to clear the needinfo on Gerv as I don't think that we need input from the module owner for this type of override. I expect that Gerv (still cced) will comment if he has something to contribute to this conversation.
Flags: needinfo?(gerv)
Adding an override with this info is sort of the same thing as an override for other broken sites, but it's a bit different in two ways. The first, minor way is that it does increase the fingerprintability. (In other cases, we simply add "Android", or present to be a Galaxy S2!)

The second is more significant. The UA Override List Policy:
https://wiki.mozilla.org/Evangelism/UA_Override_List_Policy
says that there needs to be an evangelism bug opened for each site added to the list, and we should open a channel to work with the site to fix the problem.

However, the idea here seems to be that these partners say they need this information, and that once we provide it, their view is that the site is working "properly" and they have no need to change it further. _This_ is the big difference between these overrides and other ones. It's an override that's not added by _us_ to make a site work, it's an override that's requested by the _site_ to "make the site work".

We have to decide whether we think that providing such information to the user's carrier is a good thing for the phone's user and good for the health of the web. (Noting, of course, that it's possible that they will customize Firefox OS to add such an override themselves, unless we prevent them from doing so contractually.)

Gerv
(In reply to Gervase Markham [:gerv] from comment #11)
> Adding an override with this info is sort of the same thing as an override
> for other broken sites, but it's a bit different in two ways. The first,
> minor way is that it does increase the fingerprintability. (In other cases,
> we simply add "Android", or present to be a Galaxy S2!)

I actually don't think that this change increases fingerprintability. Instead of sending static string A to the site we will send static string B. The UA will not change based on the underlying hardware (we don't have that capability in the UA override list).

> The second is more significant. The UA Override List Policy:
> https://wiki.mozilla.org/Evangelism/UA_Override_List_Policy
> says that there needs to be an evangelism bug opened for each site added to
> the list, and we should open a channel to work with the site to fix the
> problem.

Both Jonas and I are committed to understanding the underlying site issues that require these overrides so that we can work to fix the issues and remove the overrides. (See comment 9 and comment 10.) I want to understand these issues up front (before the overrides are added to the list) so that we know what is needed to fix the site and confirm that there is a path to remove the overrides.  

> However, the idea here seems to be that these partners say they need this
> information, and that once we provide it, their view is that the site is
> working "properly" and they have no need to change it further. _This_ is the
> big difference between these overrides and other ones. It's an override
> that's not added by _us_ to make a site work, it's an override that's
> requested by the _site_ to "make the site work".

Both Jonas and I have been clear in our communications with these partners that the UA override list is a temporary list and that the goal is to only have sites on this list for a short time.
I should add that at this point, without understanding the site issues that supposedly require an override, I can't say that an override is appropriate. We have not yet discussed any site specifics.
> I actually don't think that this change increases fingerprintability.
> Instead of sending static string A to the site we will send static string B.
> The UA will not change based on the underlying hardware (we don't have that
> capability in the UA override list).

Well, we do a separate build of B2G for each platform, so in a sense we do - we just have to patch each build separately.

But if it's true that we don't have this capability using the UA override list, then how (technically) do we expect to provide the info the sites want?

> Both Jonas and I are committed to understanding the underlying site issues
> that require these overrides so that we can work to fix the issues and
> remove the overrides. (See comment 9 and comment 10.) I want to understand
> these issues up front (before the overrides are added to the list) so that
> we know what is needed to fix the site and confirm that there is a path to
> remove the overrides.  

That's encouraging :-) I've been CCed on email from Vivo which suggests that they want us to send model info in the UA in order that they _not_ have to change their site. 

> Both Jonas and I have been clear in our communications with these partners
> that the UA override list is a temporary list and that the goal is to only
> have sites on this list for a short time.

What leverage do we have once we make this change? Do we threaten to back it out unilaterally on a certain date?

Gerv
(In reply to Gervase Markham [:gerv] from comment #14)
> > I actually don't think that this change increases fingerprintability.
> > Instead of sending static string A to the site we will send static string B.
> > The UA will not change based on the underlying hardware (we don't have that
> > capability in the UA override list).
> 
> Well, we do a separate build of B2G for each platform, so in a sense we do -
> we just have to patch each build separately.

That's true and is an approach that our partners can choose to take on their own.

> But if it's true that we don't have this capability using the UA override
> list, then how (technically) do we expect to provide the info the sites want?

This is a good question and one for which I don't yet have an answer. I don't yet know why the site requires this information and why they can't update their site before the launch. Again, I definitely want to understand these requirements before agreeing to this change.
 
> > Both Jonas and I are committed to understanding the underlying site issues
> > that require these overrides so that we can work to fix the issues and
> > remove the overrides. (See comment 9 and comment 10.) I want to understand
> > these issues up front (before the overrides are added to the list) so that
> > we know what is needed to fix the site and confirm that there is a path to
> > remove the overrides.  
> 
> That's encouraging :-) I've been CCed on email from Vivo which suggests that
> they want us to send model info in the UA in order that they _not_ have to
> change their site. 

I've been cced on similar e-mails and have consistently responded per our discussion in this thread to each request.

> > Both Jonas and I have been clear in our communications with these partners
> > that the UA override list is a temporary list and that the goal is to only
> > have sites on this list for a short time.
> 
> What leverage do we have once we make this change? Do we threaten to back it
> out unilaterally on a certain date?

I think we have limited leverage. What we need is an agreement that the site needs to be fixed. If there is a legitimate reason that the override is required (some reason that it will take X months to fix the site) then we should proceed. If there is no promise that the site will be fixed, we should carefully consider the benefit of adding it to the override list.

At the risk of hijiacking this bug, we can also discuss when the UA override mechanism should be dropped altogether. This may be when the list gets to zero, in a specific version of B2G, or some other criteria.
First - let's not hijack the bug for the general UA override mechanism being dropped - I'd talk about that as a separate discussion in the mobile web compat meeting and potentially dev-b2g as well.

Second - In an effort to make understanding open questions, decisions, and notes about this issue easier to understand since there's a lot to this, I've created an etherpad for this here - https://etherpad.mozilla.org/vendor-model-ua-override-questions. I'd suggest we package the list of questions here, decisions, and other relevant notes so that we know what to discuss next when a followup partner discussion happens.
Hi, 

Sorry for the delay answering, I've been couple of days off. 

I think we cannot expect all those sites will be modified at such a short term (before launching), to be able to work properly with the generic UA. If we do not override the UA for those, the result will be sites not displaying properly in FFOS devices, and working fine with any device else. 

We are talking about just a few sites to apply the UA override. I think it'd be possible to follow this strategy: 
- At short term, apply UA override (including vendor/model info) for just those sites
- File evangelims bugs for each of the sites, and try to convince them that it's the best way to manage it in their own interest. 

Thoughts?

Thanks, 
David
Let's take this offline to an email thread. I've got some questions in response to that, but might be appropriate for a smaller audience.
tef? this should be under the radar so that partners can pickup the changes after the decision is made on which site to have UA override but it seems like this is going to happen
blocking-b2g: --- → tef?
(In reply to Joe Cheng [:jcheng] from comment #19)
> tef? this should be under the radar so that partners can pickup the changes
> after the decision is made on which site to have UA override but it seems
> like this is going to happen

FWIW, the email thread on this kinda stopped and never reached a conclusion. We still need to reach a decision here.

Marketplace technically did things differently to deal with carrier-specific requirements without using UA overrides, so I'm not sure this is necessarily the only approach available here.
tef- until that parallel e-mail thread reachs any conclusion.
blocking-b2g: tef? → -
Flags: needinfo?(dcoloma)
(In reply to Daniel Coloma:dcoloma from comment #21)
> tef- until that parallel e-mail thread reachs any conclusion.

To be more specific, in order to reach conclusion we need a list of the sites with the suggested UA override for each site as well as justification on why the site can't be fixed. (If these are 3rd party sites we'll need to start working with them to get their sites fixed.)
Hi, 

After talking to Telefonica Spain (and I presume the situation in other OBs would be quite the same), they state that having a list of the
sites with the suggested UA override for each site is not the best solution for them.

The main reason is that the number of sites (and their addresses) of this list is variable and may change from one day to another.
Moreover, most of these sites (such as Movistar homepage) has links to different contents from different providers hosted in non-Telefonica domains (meaning that Telefonica has no control on them since they are third parties'), and they also check the UA. 
Even more, Telefonica is uncapable of providing the whole list of current sites that would need to be included in our list.

It is true that the way these sites are developped might not be the best one, according to the Web principles but, being realistic, neither we, nor Telefonica are going to be capable of obtaining the current list of sites and persuading  all of them, in a short term, to addapt their websites (evangelization is, unfortunately, a long term matter)

Since many of these sites provide content that means revenue for the OBs, Telefonica needs to guarantee the proper access to them, so I strongly recommend that, at least for V1.1, the UA is modified to include vendor/model information

Thanks

PS: FYI, Telefonica Spain has already raised a bug about this in their internal tool, and they have set it as blocking
(In reply to Juan Perez-Bedmar [:jpbf] from comment #23)
> The main reason is that the number of sites (and their addresses) of this
> list is variable and may change from one day to another.

I would like to understand why the list of sites changes one day to the next. Are there transient sites that come and go with promotions or events? Are these sites built on the same framework so that fixing the framework will fix the sites?

> Moreover, most of these sites (such as Movistar homepage) has links to
> different contents from different providers hosted in non-Telefonica domains
> (meaning that Telefonica has no control on them since they are third
> parties'), and they also check the UA. 

AFAIK, the provider is not included in the UA for iPhone or Android devices. How do these sites determine the provider in order to provide provider specific content?

> Even more, Telefonica is uncapable of providing the whole list of current
> sites that would need to be included in our list.

Can we start with a short list of sites so that we have some concrete data with which to work?
 
> It is true that the way these sites are developped might not be the best
> one, according to the Web principles but, being realistic, neither we, nor
> Telefonica are going to be capable of obtaining the current list of sites
> and persuading  all of them, in a short term, to addapt their websites
> (evangelization is, unfortunately, a long term matter)

I agree that fixing sites is a long term problem. The approach that we've taken thus far is to try and fix the top key sites before the v1 launch. To be clear, we are not going to be able to get 100% of the content working for v1 (it may not ever all work).

In addition, UA detection is only one of the potential site problems. We also typically see problems due to WebKit DOM and JS prefixed property usage. We need to test each site before adding an UA override in order to ensure that adding the override actually fixes the site.

> Since many of these sites provide content that means revenue for the OBs,
> Telefonica needs to guarantee the proper access to them, so I strongly
> recommend that, at least for V1.1, the UA is modified to include
> vendor/model information

We have been pretty clear that we will not add the vendor/model information to the default UA. We will add this information on a site-by-site basis. Given that the OBs (?) receive revenue from these sites, I would expect that they can produce a list of revenue producing sites. Can we get the list of revenue producing sites?

I will also add that changing the UA at this point will likely cause regressions in key sites such as Facebook, Twitter, Google, etc. We have actively worked with all of these sites to ensure that they recognize the Firefox OS UA.

> PS: FYI, Telefonica Spain has already raised a bug about this in their
> internal tool, and they have set it as blocking

Good. What we need now is to explore the options to resolve this blocking issue.
Hi Lawrence, 

I agree with Juan's comments. Let me answer also inline. 

Thanks!
David



(In reply to Lawrence Mandel [:lmandel] from comment #24)
> (In reply to Juan Perez-Bedmar [:jpbf] from comment #23)
> > The main reason is that the number of sites (and their addresses) of this
> > list is variable and may change from one day to another.
> 
> I would like to understand why the list of sites changes one day to the
> next. Are there transient sites that come and go with promotions or events?
> Are these sites built on the same framework so that fixing the framework
> will fix the sites?
> 

This is changed very frequently because there a lot of contents providers that are fw'ed from emocion site. This sites check UA string (vendor/model), to check if the device/model really supports the content is going to be served. This list of providers change very frequently, so in practice is not possible to maintain this one site by one. 

Sites are very different, as they come from different content providers. They are not based in any "common platform", so it's not easy to solve this. 

> > Moreover, most of these sites (such as Movistar homepage) has links to
> > different contents from different providers hosted in non-Telefonica domains
> > (meaning that Telefonica has no control on them since they are third
> > parties'), and they also check the UA. 
> 
> AFAIK, the provider is not included in the UA for iPhone or Android devices.
> How do these sites determine the provider in order to provide provider
> specific content?

UAs from Android-based devices are modified by each vendor to include vendor/model information. 

For iPhone, the UA says that's an iPhone (so no matter which iPhone is, all of them are identical in terms of form factor, content formats support, etc): 
"... iPhone OS 5_1_1 like Mac OS X"

> 
> > Even more, Telefonica is uncapable of providing the whole list of current
> > sites that would need to be included in our list.
> 
> Can we start with a short list of sites so that we have some concrete data
> with which to work?

As explained before, I think it is not enough to include just a reduced white list, but allowing to the vendors to personalize UA, which is exactly what is done for Android (Juan, maybe you can confirm this point)

For instance, for Spain: emocion.movistar.es 

>  
> > It is true that the way these sites are developped might not be the best
> > one, according to the Web principles but, being realistic, neither we, nor
> > Telefonica are going to be capable of obtaining the current list of sites
> > and persuading  all of them, in a short term, to addapt their websites
> > (evangelization is, unfortunately, a long term matter)
> 
> I agree that fixing sites is a long term problem. The approach that we've
> taken thus far is to try and fix the top key sites before the v1 launch. To
> be clear, we are not going to be able to get 100% of the content working for
> v1 (it may not ever all work).
> 
> In addition, UA detection is only one of the potential site problems. We
> also typically see problems due to WebKit DOM and JS prefixed property
> usage. We need to test each site before adding an UA override in order to
> ensure that adding the override actually fixes the site.

I think this is not possible, as it's going to be very difficult to have a "static" whitelist for UA override. 

> 
> > Since many of these sites provide content that means revenue for the OBs,
> > Telefonica needs to guarantee the proper access to them, so I strongly
> > recommend that, at least for V1.1, the UA is modified to include
> > vendor/model information
> 
> We have been pretty clear that we will not add the vendor/model information
> to the default UA. We will add this information on a site-by-site basis.
> Given that the OBs (?) receive revenue from these sites, I would expect that
> they can produce a list of revenue producing sites. Can we get the list of
> revenue producing sites?
> 
> I will also add that changing the UA at this point will likely cause
> regressions in key sites such as Facebook, Twitter, Google, etc. We have
> actively worked with all of these sites to ensure that they recognize the
> Firefox OS UA.
> 

What type of regressions can we expect here, when adding UA override?

> > PS: FYI, Telefonica Spain has already raised a bug about this in their
> > internal tool, and they have set it as blocking
> 
> Good. What we need now is to explore the options to resolve this blocking
> issue.
As a random thought for a different idea to meet the needs of what I'm hearing from both sides?

Could we use something else other than the user agent to allow carrier sites to get what they need? Something else on the navigator object we could modify or provide? Expose a getCarrier like webapi?

Jonas - Do you have any ideas on what we could do here other than UA modifications or UA overrides?
Flags: needinfo?(jonas)
(In reply to David Palomino [:dpv] from comment #25)
> This is changed very frequently because there a lot of contents providers
> that are fw'ed from emocion site. This sites check UA string (vendor/model),
> to check if the device/model really supports the content is going to be
> served. This list of providers change very frequently, so in practice is not
> possible to maintain this one site by one. 

I may have misunderstood but it reads to me like emocion is a single site that performs the UA detection and forwards on as appropriate. If this is the case, this is a single point to fix. Is this correct?

> UAs from Android-based devices are modified by each vendor to include
> vendor/model information. 

Yes. There are UA detection frameworks such as WURFL, Categorizr, and 51Degrees, whom I've worked with personally to detect Firefox OS and list its capabilities. What capability differences between devices do you expect that require calling out the vendor/model in the UA?

Furthermore, unless I'm missing something, we're talking about adding a new vendor/model combination to the UA. i.e. This vendor/model combination will not be detected by these sites using their existing detection logic. The sites will need to modify their detection logic to recognize Firefox OS. If this is the case, why not simply have them modify their UA detection logic to recognize the existing Firefox OS UA?
 
> For iPhone, the UA says that's an iPhone (so no matter which iPhone is, all
> of them are identical in terms of form factor, content formats support,
> etc): 
> "... iPhone OS 5_1_1 like Mac OS X"

This statement is not correct. The iPhone 5 has a larger screen than previous models. http://www.apple.com/iphone/compare-iphones/

However, for content format support, your statement applies equally to Firefox OS at this point in the OS life cycle.
 
> > Can we start with a short list of sites so that we have some concrete data
> > with which to work?
> 
> As explained before, I think it is not enough to include just a reduced
> white list, but allowing to the vendors to personalize UA, which is exactly
> what is done for Android (Juan, maybe you can confirm this point)
> 
> For instance, for Spain: emocion.movistar.es 

I was unclear in my request. Can you provide a short list of sites so that we can have a few concrete examples to frame our discussion?

> > In addition, UA detection is only one of the potential site problems. We
> > also typically see problems due to WebKit DOM and JS prefixed property
> > usage. We need to test each site before adding an UA override in order to
> > ensure that adding the override actually fixes the site.
> 
> I think this is not possible, as it's going to be very difficult to have a
> "static" whitelist for UA override. 

What I'm getting at here is that even if we modify the UA to include vendor/model information, there is no guarantee that any specific site will be functional.

> > Given that the OBs (?) receive revenue from these sites, I would expect that
> > they can produce a list of revenue producing sites. Can we get the list of
> > revenue producing sites?

I'll renew this question. If there are sites that are producing revenue, presumably the list of these sites is documented somewhere. Can we get access to this list so that we can QA this short list of sites? Even if the list changes over time at least a snapshot can serve as a good starting point.

> What type of regressions can we expect here, when adding UA override?

The problem that I was calling out is general regressions due to changing the default UA. I would expect that some percentage of sites that serve mobile content to Firefox OS today will regress and serve desktop content after this change. This will create more work for the Mozilla mobile Web compatibility team and adds risk to the existing content for the v1 release.
The time for making blanket changes to the Firefox OS UA is, as Lawrence points out, well past. Each change to this string brings its own compatibility issues, and many sites will have (at our request) adapted to make sure the current string provides the Firefox OS browser with the correct content. 

There are several reasons that vendor/model information were not included in the string; it was not an oversight. Doing so works against Mozilla's goals for the web in a number of ways, and stores up trouble for us and for later versions of Firefox OS or later device models in the future. Those who want to argue for it might want to familiarise themselves with the arguments in that debate; but, as noted above, it's now too late for a change anyway.

We do have the ability to send a different UA to sites on a per-site basis. However, this is not a magic bullet for "making sites work", and even if you do find a UA which does work, you can be storing up compatibility problems for yourself in the future. Also, we currently only have the ability to send a static UA; if we wanted to extend this mechanism so that some part of the replacement UA could be vendor/model specific, code would need to be written.

Anyway, as Lawrence points out, if we were to change Firefox OS in this way, then all these sites would need to update to recognize the vendor/model combination we add. Given that, why can they not update to recognize the current string (or, better, to detect capabilities directly)?

jsmith: the answer to your question is that they should use existing JS APIs to detect the values they care about (e.g. screen size), rather than detecting a model number and using it to guess at the screen size. Detecting it directly will work on every device. An extra level of indirection is just a source of bugs and problems.

Gerv
(In reply to Gervase Markham [:gerv] from comment #28)
> Also, we currently only have the ability to send
> a static UA; if we wanted to extend this mechanism so that some part of the
> replacement UA could be vendor/model specific, code would need to be written.

UserAgentOverrides.addComplexOverride is there to support this, so code would only need to be written on the b2g side to make use of that.
Adding dependency for certification meta bug, as it was reported in Spain.
Blocks: 855322
David - This bug still lacks basic requirements that will allow us to close it. Can you help with my request in comment 24 and comment 27 for a short list of sites that require the vendor/model in order to function? This list only needs to be a few sites so that we can investigate and understand more about why the vendor/model is required in the UA and start to work on a solution. Thanks!
Flags: needinfo?(dpv)
Hi Lawrence, 

We're asking and collecting info about this sites from the carriers. Not yet ready, sorry about that.
Flags: needinfo?(dpv)
Flags: needinfo?(jonas)
Adding latam dep.
Blocks: 855378
Duplicate of this bug: 863283
The V1.1 UAS is decide to below one in Bug 878961
Mozilla/5.0 (Mobile; rv:18.1) Gecko/18.1 Firefox/18.1

The operator requst to insert the model name in UAS
How about below one?
Mozilla/5.0 (Mobile;rv:18.1;Device name) Gecko/18.1 Firefix/18.1
(In reply to leo.bugzilla.gecko from comment #35)
> The V1.1 UAS is decide to below one in Bug 878961
> Mozilla/5.0 (Mobile; rv:18.1) Gecko/18.1 Firefox/18.1
> 
> The operator requst to insert the model name in UAS
> How about below one?
> Mozilla/5.0 (Mobile;rv:18.1;Device name) Gecko/18.1 Firefix/18.1

As has already been stated multiple times in the comments in the bug, we will not modify the default UA on the device. We will consider adding an UA override for a broken site. However, as I also requested multiple times above, in order to consider an UA override we need:
1. A specific domain that should be overridden (ex. mozilla.org)
2. Justification for the override. Why is this site important and why can't the fix be applied to the site.

For your reference again, here is our policy on partner changes
https://wiki.mozilla.org/B2G/User_Agent/Partner_Changes_Policy

And here is the justification/background for the Firefox OS UA
https://wiki.mozilla.org/B2G/User_Agent
Given that we agreed to allow vendors to optionally include a device/model id in the default UA on a device, I'm resolving this as won't fix.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.