The default bug view has changed. See this FAQ.

Use the legacy User Agent string (containing Gecko/20100101) for some possibly-broken online banking sites

RESOLVED FIXED in Firefox 17

Status

()

Firefox
General
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: dao, Assigned: dao)

Tracking

Trunk
Firefox 19
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox16 unaffected, firefox17+ fixed, firefox18+ fixed)

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Assignee)

Description

5 years ago
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.
(Assignee)

Comment 1

5 years ago
Created attachment 662168 [details] [diff] [review]
patch
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #662168 - Flags: review?(gerv)
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
(Assignee)

Comment 3

5 years ago
(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.

Comment 4

5 years ago
(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

Comment 7

5 years ago
(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.
(Assignee)

Comment 8

5 years ago
(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.

Comment 9

5 years ago
(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
(Assignee)

Comment 11

5 years ago
(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

Comment 13

5 years ago
(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.
(Assignee)

Comment 14

5 years ago
(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
(Assignee)

Comment 17

5 years ago
> - 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.
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
(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
(Assignee)

Comment 19

5 years ago
(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.
tracking-firefox17: ? → +
tracking-firefox18: ? → +
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?
Keywords: qawanted
(Assignee)

Comment 21

5 years ago
(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.
Depends on: 795348
(Assignee)

Updated

5 years ago
Depends on: 795350
(Assignee)

Comment 22

5 years ago
Created attachment 666934 [details] [diff] [review]
patch v2

added raiffeisen.hu
Attachment #662168 - Attachment is obsolete: true
Attachment #662168 - Flags: review?(gerv)
Attachment #666934 - Flags: review?(gerv)
(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.
Keywords: qawanted
(Assignee)

Comment 24

5 years ago
(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
(Assignee)

Updated

5 years ago
Summary: Override the User Agent string for some possibly-broken online banking sites → Use the legacy User Agent string (containing Gecko/20100101) for some possibly-broken online banking sites
(Assignee)

Comment 25

5 years ago
Created attachment 673705 [details] [diff] [review]
patch v3

updated as per comment 24
Attachment #666934 - Attachment is obsolete: true
Attachment #666934 - Flags: review?(gerv)
Attachment #673705 - Flags: review?(gerv)
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"
(Assignee)

Comment 27

5 years ago
(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
Depends on: 804103
(In reply to Dão Gottwald [:dao] from comment #27)
> Could you please file a separate Tech Evangelism bug? Thanks.

Done. Bug #804103
(Assignee)

Updated

5 years ago
(Assignee)

Comment 30

5 years ago
Created attachment 673888 [details] [diff] [review]
patch v4

bug numbers added
Attachment #673705 - Attachment is obsolete: true
Attachment #673705 - Flags: review?(gerv)
Attachment #673888 - Flags: review?(gerv)
(Assignee)

Comment 31

5 years ago
Created attachment 676554 [details] [diff] [review]
patch v5

removed nab.com.au (bug 804178) and pnc.com (bug 804181), added bankmillennium.pl (bug 804103)
Attachment #673888 - Attachment is obsolete: true
Attachment #673888 - Flags: review?(gerv)
Attachment #676554 - Flags: review?(gerv)
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
(Assignee)

Comment 33

5 years ago
(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
(Assignee)

Comment 35

5 years ago
(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.
(Assignee)

Comment 37

4 years ago
Created attachment 677474 [details] [diff] [review]
patch v6

removed deutsche-bank.de (bug 804176)
Attachment #676554 - Attachment is obsolete: true
Attachment #676554 - Flags: review?(gerv)
Attachment #677474 - Flags: review?(gerv)
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
Attachment #677474 - Flags: review?(gerv) → review+
(Assignee)

Comment 39

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/fe3ddc3ce8e6
https://hg.mozilla.org/mozilla-central/rev/fe3ddc3ce8e6
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
(Assignee)

Comment 41

4 years ago
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
Attachment #677474 - Flags: approval-mozilla-beta?
Attachment #677474 - Flags: approval-mozilla-aurora?
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.
Attachment #677474 - Flags: approval-mozilla-beta?
Attachment #677474 - Flags: approval-mozilla-beta+
Attachment #677474 - Flags: approval-mozilla-aurora?
Attachment #677474 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 43

4 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/cc85077c423b
https://hg.mozilla.org/releases/mozilla-aurora/rev/33c470ea043e
status-firefox17: affected → fixed
status-firefox18: affected → fixed
Blocks: 809517
You need to log in before you can comment on or make changes to this bug.