In the mozillazine forums, I saw someone who customized his UA string in order to access his bank. I'm still waiting for a response as to which bank this affects. In the meantime, knowing that banks are notorious UA sniffers (they consider this a security measure), I searched for "bank" on input.mozilla.org: http://input.mozilla.org/?product=firefox&version=17.0&q=bank http://input.mozilla.org/?product=firefox&version=18.0&q=bank which lead me to this list: becuonlinebanking.org coastal24.com deutsche-bank.de mtb.com mandtbank.com nab.com.au pnc.com Not all of the reports necessarily have to do with UA sniffing. I was only able to verify the case for <https://onlinebanking.mandtbank.com/SignOn.aspx>. In general it's hard to do this without testing accounts. I think we should err on the side of overriding, which can always be undone later.

I'm afraid I don't agree that we should err on the side of overriding. I think we need to have a high bar for adding sites to the override list. (Has that patch even got checked in yet?) I propose that we have the following requirements: - Sites broken in B2G and/or Firefox for Android only (these are our products with low market share) - Site is significantly used in target market for product - Evangelism bug open on getting the site fixed - Outreach efforts to the site have not met with success for a period of time - Testing has demonstrated that a UA override leads to a significantly better-functioning site - Evangelism bug is referenced in a comment above the list entry Gerv

(In reply to Gervase Markham [:gerv] from comment #2) > - Sites broken in B2G and/or Firefox for Android only (these are our > products with low market share) Releasing a product with significant market share and wait for sites to roll out emergency fixes is one way to approach things, but I don't expect that Asa & Co. will agree with this.

(In reply to Gervase Markham [:gerv] from comment #2) > I'm afraid I don't agree that we should err on the side of overriding. I > think we need to have a high bar for adding sites to the override list. (Has > that patch even got checked in yet?) I propose that we have the following > requirements: > > - Sites broken in B2G and/or Firefox for Android only (these are our > products with low market > share) > - Site is significantly used in target market for product > - Evangelism bug open on getting the site fixed > - Outreach efforts to the site have not met with success for a period of time > - Testing has demonstrated that a UA override leads to a significantly > better-functioning site > - Evangelism bug is referenced in a comment above the list entry > > Gerv While I'm absolutely against this and feel that this is solely something for Evangelism, I'd like to state propose that given most banks are steering towards dedicated Android apps and also that B2Gs usage is as low as it is, can I recommend that we remove criteria one from the list?

(In reply to Dão Gottwald [:dao] from comment #3) > (In reply to Gervase Markham [:gerv] from comment #2) > > - Sites broken in B2G and/or Firefox for Android only (these are our > > products with low market share) > > Releasing a product with significant market share and wait for sites to roll > out emergency fixes is one way to approach things, but I don't expect that > Asa & Co. will agree with this. I'm not sure what you mean here. I am suggested we _do_ do fixes for our products with low market share, and that we don't do fixes for Firefox for Desktop because if a 20% market share isn't going to persuade them to fix their site, then what will? Gerv

(In reply to Paul [sabret00the] from comment #4) > While I'm absolutely against this and feel that this is solely something for > Evangelism, I'd like to state propose that given most banks are steering > towards dedicated Android apps and also that B2Gs usage is as low as it is, > can I recommend that we remove criteria one from the list? I don't understand your logic. Why does the fact that banks have dedicated apps, and B2G currently has no market share (because it's not released) mean that we should do UA spoofing in Firefox on desktop? Gerv

(In reply to Gervase Markham [:gerv] from comment #6) > (In reply to Paul [sabret00the] from comment #4) > > While I'm absolutely against this and feel that this is solely something for > > Evangelism, I'd like to state propose that given most banks are steering > > towards dedicated Android apps and also that B2Gs usage is as low as it is, > > can I recommend that we remove criteria one from the list? > > I don't understand your logic. Why does the fact that banks have dedicated > apps, and B2G currently has no market share (because it's not released) mean > that we should do UA spoofing in Firefox on desktop? > > Gerv I'm saying we _should__not_ spoof the strings and instead evangelise the banks to make the change. It's the same argument that's been had every time a UA bug/thread comes up. Decide on something and stick with it. If we make exceptions, then how long for? There's no plus side to making exceptions in the long term of Firefox.

(In reply to Gervase Markham [:gerv] from comment #5) > (In reply to Dão Gottwald [:dao] from comment #3) > > (In reply to Gervase Markham [:gerv] from comment #2) > > > - Sites broken in B2G and/or Firefox for Android only (these are our > > > products with low market share) > > > > Releasing a product with significant market share and wait for sites to roll > > out emergency fixes is one way to approach things, but I don't expect that > > Asa & Co. will agree with this. > > I'm not sure what you mean here. I am suggested we _do_ do fixes for our > products with low market share, and that we don't do fixes for Firefox for > Desktop because if a 20% market share isn't going to persuade them to fix > their site, then what will? It would persuade them but it also means that Firefox might be broken for a few days for some of our users. That's a problem.

(In reply to Dão Gottwald [:dao] from comment #8) > (In reply to Gervase Markham [:gerv] from comment #5) > > (In reply to Dão Gottwald [:dao] from comment #3) > > > (In reply to Gervase Markham [:gerv] from comment #2) > > > > - Sites broken in B2G and/or Firefox for Android only (these are our > > > > products with low market share) > > > > > > Releasing a product with significant market share and wait for sites to roll > > > out emergency fixes is one way to approach things, but I don't expect that > > > Asa & Co. will agree with this. > > > > I'm not sure what you mean here. I am suggested we _do_ do fixes for our > > products with low market share, and that we don't do fixes for Firefox for > > Desktop because if a 20% market share isn't going to persuade them to fix > > their site, then what will? > > It would persuade them but it also means that Firefox might be broken for a > few days for some of our users. That's a problem. If we receive significant feedback on the beta channel, then by all means let's reconsider this bug, but there's absolutely no rush at this point and we need to give banks, etc a chance to implement changes.

Paul: it's not clear at all what you are arguing for. I suggested a stringent set of criteria we should have to meet before deciding to add a site to the list. You suggested removing one of those criteria, making them less stringent, and opening up the possibility of using this mechanism for broken Firefox for Desktop sites. But then you said that you were _against_ spoofing. So what is your actual position? Dao: can I just check what this bug is asking for? You are asking for the UA override mechanism to be used on Firefox desktop for mantdbank.com? Based on a report from input.mozilla.com and some brief testing of your own? If so, what UA are you proposing? What evidence is there, if any, that this makes the whole site work well? It could be that Firefox is excluded because the site doesn't actually work with it - e.g. they use ActiveX. If so, bypassing the protection would be counter-productive. Gerv

(In reply to Gervase Markham [:gerv] from comment #10) > Dao: can I just check what this bug is asking for? You are asking for the UA > override mechanism to be used on Firefox desktop for mantdbank.com? Based on > a report from input.mozilla.com and some brief testing of your own? mandtbank.com is the only site where I could verify without an account that modifying the UA helps. I propose that we override the UA for all sites mentioned in comment 0 to be on the safe side. > If so, what UA are you proposing? The default UA with Gecko/20100101 instead of Gecko/<version>. > What evidence is there, if any, that this makes > the whole site work well? It could be that Firefox is excluded because the > site doesn't actually work with it - e.g. they use ActiveX. If so, bypassing > the protection would be counter-productive. The reports say things work in Firefox stable, so unless there's some other Gecko change breaking these sites or something weird is going on locally for these particular users, it's likely due to bug 588909.

OK, I really got the wrong end of the stick here. It wasn't at all clear from comment 0 that the problem being addressed was the Gecko/version vs. Gecko/date thing, and that the proposed alternative UA was our previous UA, not some other browser's UA or a totally new UA. I still think we should file evangelism bugs on, and reach out to, these sites. But I have much less of a problem of using this mechanism to ease our transition from one UA to another than I have with using it to get us into sites which explicitly block Firefox for their own reasons. Gerv

(In reply to Gervase Markham [:gerv] from comment #12) > I still think we should file evangelism bugs on, and reach out to, these > sites. We're in agreement. > But I have much less of a problem of using this mechanism to ease our > transition from one UA to another than I have with using it to get us into > sites which explicitly block Firefox for their own reasons. I believe that to be a slippery slope.

(In reply to Gervase Markham [:gerv] from comment #12) > OK, I really got the wrong end of the stick here. It wasn't at all clear > from comment 0 that the problem being addressed was the Gecko/version vs. > Gecko/date thing, and that the proposed alternative UA was our previous UA, > not some other browser's UA or a totally new UA. Sorry, I thought the attached patch and bug 588909 being in the dependency list made this clear.

(In reply to Paul [sabret00the] from comment #13) > > But I have much less of a problem of using this mechanism to ease our > > transition from one UA to another than I have with using it to get us into > > sites which explicitly block Firefox for their own reasons. > > I believe that to be a slippery slope. Why? The set of sites broken by UA changes we make is going to be a small, bounded and non-increasing set, otherwise we would be unlikely to make the change. Why is the slope so slippery? Where are you worried about ending up? Gerv

Anyway, back on topic. I agree that we don't need the full 6-point list from comment 2 for this case, but I don't want this system to be a dumping ground. I'd say we need a reduced 4-point list: - Testing has demonstrated that a UA override fixes the problem - Evangelism bug open on getting the site fixed - Outreach efforts to the site have not met with success for a period of time - Evangelism bug is referenced in a comment above the list entry I'm certainly not in favour of adding sites to the list where the problem hasn't even been confirmed. Gerv

> - Testing has demonstrated that a UA override fixes the problem I said why I can't deliver even on this first point: I don't have accounts for those banks. > I'm certainly not in favour of adding sites to the list where the problem hasn't even > been confirmed. Sure, I'm not "in favour" of this either. But I'm also certainly not in favour of shipping Firefox 17 as is and crossing our fingers when we have way to mitigate the risk for a list of sites where we can make educated guesses that they're broken, and why.

(In reply to Dão Gottwald [:dao] from comment #17) > > - Testing has demonstrated that a UA override fixes the problem > > I said why I can't deliver even on this first point: I don't have accounts > for those banks. Sure. And I'm saying we shouldn't override for a site until we've found someone who does and confirmed that this is the problem, and that changing the UA fixes it. > Sure, I'm not "in favour" of this either. But I'm also certainly not in > favour of shipping Firefox 17 as is and crossing our fingers when we have > way to mitigate the risk for a list of sites where we can make educated > guesses that they're broken, and why. What are our deadlines here? Is the override code in the same Firefox release as the first one to contain the UA change from Gecko/date to Gecko/version? Gerv

(In reply to Gervase Markham [:gerv] from comment #18) > (In reply to Dão Gottwald [:dao] from comment #17) > > > - Testing has demonstrated that a UA override fixes the problem > > > > I said why I can't deliver even on this first point: I don't have accounts > > for those banks. > > Sure. And I'm saying we shouldn't override for a site until we've found > someone who does and confirmed that this is the problem, and that changing > the UA fixes it. So how am I supposed to find those people? > > Sure, I'm not "in favour" of this either. But I'm also certainly not in > > favour of shipping Firefox 17 as is and crossing our fingers when we have > > way to mitigate the risk for a list of sites where we can make educated > > guesses that they're broken, and why. > > What are our deadlines here? Is the override code in the same Firefox > release as the first one to contain the UA change from Gecko/date to > Gecko/version? Yes.

Adding qawanted, do we have test accounts with various banking sites to start rounding up some examples of this and getting ourselves more information - alternately could this go into a testday for reconn?

(In reply to Dão Gottwald [:dao] from comment #0) > In the mozillazine forums, I saw someone who customized his UA string in > order to access his bank. I'm still waiting for a response as to which bank > this affects. Finally got a response. Filed bug 795348.

added raiffeisen.hu

(In reply to Lukas Blakk [:lsblakk] from comment #20) > Adding qawanted, do we have test accounts with various banking sites to > start rounding up some examples of this and getting ourselves more > information - alternately could this go into a testday for reconn? We don't have test accounts for banking websites as far as I know, nor would I expect any bank to give us a fake account (given financial security). Any testing we organize will be constrained to the limits of the test audience. I would not expect the testing to be very broad. You'd probably have better luck putting a call out to our mailing lists and other feedback channels to canvas for problem areas.

(In reply to Dão Gottwald [:dao] from comment #0) > http://input.mozilla.org/?product=firefox&version=17.0&q=bank > http://input.mozilla.org/?product=firefox&version=18.0&q=bank > > which lead me to this list: > > becuonlinebanking.org > coastal24.com > deutsche-bank.de > mtb.com > mandtbank.com > nab.com.au > pnc.com Additional input.mozilla.org reports since 17 moved to beta: bank.barclays.co.uk becu.org bfsfcu.org cenfedcu.org natweststockbrokers.co.uk / natweststockbrokers.com

updated as per comment 24

Bank Millennium ( https://www.bankmillennium.pl/ ) is also affected "This Browser is not supported. Unable to proceed with registration process..." I informed them and get this reply (translated from PL to ENG) "Dear Sir, Thank you for your message. We are pleased to announce that it has been communicated to the relevant units of the bank. Thank you very much for sharing your observation. Sincerely, Veronica Grzeszczyk Department of Electronic Banking Bank Millennium SA"

(In reply to Virtual_ManPL [:Virtual] from comment #26) > Bank Millennium ( https://www.bankmillennium.pl/ ) is also affected "This > Browser is not supported. Unable to proceed with registration process..." > > > I informed them and get this reply (translated from PL to ENG) Could you please file a separate Tech Evangelism bug? Thanks.

I'll r+ this patch as soon as Tech Evangelism bugs have been filed for each site (or perhaps each company; I notice NatWest on their twice), someone has contacted each site (:Virtual: is that something you could help with? Thanks for contacting Bank Millennium...) and the patch has been updated to include the bug numbers. https://wiki.mozilla.org/Evangelism/UA_Override_List_Policy Gerv

(In reply to Dão Gottwald [:dao] from comment #27) > Could you please file a separate Tech Evangelism bug? Thanks. Done. Bug #804103

bug numbers added

removed nab.com.au (bug 804178) and pnc.com (bug 804181), added bankmillennium.pl (bug 804103)

Given that we've done investigation of about 5 of these so far, and of those 2 have proved to be caused by other things, is it not reasonable to do a little more work before putting in possibly-unnecessary overrides which will muddy the waters? How long before we ship will a policy change patch such as this one still be acceptable? 1 week? Gerv

(In reply to Gervase Markham [:gerv] from comment #32) > How long before we ship will a policy change patch such as this one still be > acceptable? 1 week? * FF17 beta 5 will go to build on 11/6 (severe user facing issues or need-to-fix beta regression only at this time) * FF17 will code freeze on 11/9 * Final Beta Goto Build on 11/12 (restricted to critical patches only) 11/5 seems like a reasonable target.

OK. I need to go and have my kidney removed. I'm fine with a checkin on 5th November (remember, remember!) but I'd urge you and the evang. team to keep chasing up the banks in question. If there's actually some different problem, we need to find out what it is (we may have other bugs to fix). Gerv

(In reply to Gervase Markham [:gerv] from comment #34) > If there's actually some different > problem, we need to find out what it is (we may have other bugs to fix). Which would be easier if this didn't land at the last minute. Probably too late already by now. If this had landed weeks ago, we could have watched input.mozilla.org for ongoing complaints.

I have this in my burndown list for Beta 5 and will be pinging on Nov 5 to get it landed before we go to build.

removed deutsche-bank.de (bug 804176)

Comment on attachment 677474 [details] [diff] [review] patch v6 Given the hit rate we've seen here, I'm a bit suspicious of using individual reports from input.mozilla.com as input into this process. The diagnosis accuracy seems like 50% or worse. Still, we are where we are in the release cycle, so r=gerv. Gerv

Comment on attachment 677474 [details] [diff] [review] patch v6 [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 588909 User impact if declined: online banking may be broken on some banking sites until they fix their User Agent sniffing Testing completed (on m-c, etc.): landed on m-c Risk to taking this patch (and alternatives if risky): low risk String or UUID changes made by this patch: none

Comment on attachment 677474 [details] [diff] [review] patch v6 Please go ahead with uplift today so that this lands in time for tomorrow's beta build.

https://hg.mozilla.org/releases/mozilla-beta/rev/cc85077c423b https://hg.mozilla.org/releases/mozilla-aurora/rev/33c470ea043e