Hilfe durchsuchen

Vorsicht vor Support-Betrug: Wir fordern Sie niemals auf, eine Telefonnummer anzurufen, eine SMS an eine Telefonnummer zu senden oder persönliche Daten preiszugeben. Bitte melden Sie verdächtige Aktivitäten über die Funktion „Missbrauch melden“.

Weitere Informationen

Bank Bill Pay not working after v131.0.3 install

  • 2 Antworten
  • 0 haben dieses Problem
  • Letzte Antwort von NoahSUMO

more options

I was very excited to see in the 131.0.3 release notes that it fixed a problem with bill pay. I've been unable to use bill pay at my small local bank since v131. My bank was unable to help me and I couldn't get bill pay to work with v131 even after opening everything up as much as I knew how (cookies, trackers, etc.).


Sadly, v 131.0.3 still has the same behavior of blocking bill pay with a very similar message to the BOA message posted earlier.

My local bank uses a site named: web13.secureinternetbanking.com and in the past, I also needed to exempt cookies from sites named: cwsb40.checkfreeweb.com and cw411.checkfreeweb.com. I've also added these sites to the exceptions list for enhanced tracking without effect.

I found a thread on Mozilla Connect from ipv6_fan that seemed to indicate a solution.

Based on that thread, I checked the following parameters:

The value of network.cookie.cookieBehavior.optInPartitioning is false.

The value of network.cookie.CHIPS.enabled is true.

When I set network.cookie.CHIPS.enabled to false, my billpay popped up as usual.

This seems to indicate (to a novice like me) that there are still issues in 131.0.3 with partitioned cookies.

To make this point, yesterday I spent probably an hour and a 1/2 trying to get to another bank account on Barclays working again because they just "upgraded their web experience". I think I was able to get all the new URLs identified for my exception list for cookies, but blocking cross tracking also creates havoc and I had to turn it off to get the bank site to work. I tried to add sites to the exception list for cross tracking, but firefox still showed it was blocking trackers even though I had added it to the exception list - so I gave up after all that time.

I appreciate the additional security being built into Firefox, but it seems to not play well with banks who seem to be on their own path for increasing security. These two paths don't seem to be converging.

I hope this doesn't sound ungrateful. Thanks for working on this.

I was very excited to see in the 131.0.3 release notes that it fixed a problem with bill pay. I've been unable to use bill pay at my small local bank since v131. My bank was unable to help me and I couldn't get bill pay to work with v131 even after opening everything up as much as I knew how (cookies, trackers, etc.). Sadly, v 131.0.3 still has the same behavior of blocking bill pay with a very similar message to the BOA message posted earlier. My local bank uses a site named: web13.secureinternetbanking.com and in the past, I also needed to exempt cookies from sites named: cwsb40.checkfreeweb.com and cw411.checkfreeweb.com. I've also added these sites to the exceptions list for enhanced tracking without effect. I found a thread on Mozilla Connect from ipv6_fan that seemed to indicate a solution. Based on that thread, I checked the following parameters: The value of network.cookie.cookieBehavior.optInPartitioning is false. The value of network.cookie.CHIPS.enabled is true. When I set network.cookie.CHIPS.enabled to false, my billpay popped up as usual. This seems to indicate (to a novice like me) that there are still issues in 131.0.3 with partitioned cookies. To make this point, yesterday I spent probably an hour and a 1/2 trying to get to another bank account on Barclays working again because they just "upgraded their web experience". I think I was able to get all the new URLs identified for my exception list for cookies, but blocking cross tracking also creates havoc and I had to turn it off to get the bank site to work. I tried to add sites to the exception list for cross tracking, but firefox still showed it was blocking trackers even though I had added it to the exception list - so I gave up after all that time. I appreciate the additional security being built into Firefox, but it seems to not play well with banks who seem to be on their own path for increasing security. These two paths don't seem to be converging. I hope this doesn't sound ungrateful. Thanks for working on this.

Geändert am von NoahSUMO

Alle Antworten (2)

more options

Hi MI ClassB, Thanks for posting a super detailed report. I wasn't expecting that!

I hope this doesn't sound ungrateful. Thanks for working on this.

No worries! This is the kind of information that needs to be said so developers can fully understand the bad experience ETP (Enhance Tracking Protection) & all its cookie blocking technologies including CHIPS brings.

In the past 5 years, I would see bank sites stop working randomly. Anything from "I can't login and get a blank page" to "I can't use the bank's Bill Pay option". Or maybe another page inside the bank account is not displaying properly.

I used to think these were incidents caused by the bank updating their site and doing something incorrectly. Now after seeing the explosive breakage in banks sites & Google logins caused by Firefox's CHIPS and ETP, I'm of the opinion that Disconnect (the company that creates the blocking lists for tracking scripts & tracking cookies) has been responsible for breaking these banks sites (and more sites) over the last few years. I think we've been using them for 5 years now.

Disconnect.me says they test each url extensively before adding it to their block list. I believe that is a lie. It's impossible to thoroughly test the thousands of urls they've added to their blocking lists to make sure they don't cause any site breakage. And they've been getting away with breaking sites in Firefox for years now. I'm very much going to suggest Firefox terminate their contract with Disconnect. As I believe Disconnect.me charges corporations for access to specially crafted tracking protection lists. For all the damage & unnecessary headaches they've caused Firefox users, they should be giving out refunds. Regular users don't have hours or days to figure out silent site failures when they have to conduct important bank business or pay bills that are due or risk late fees or service disconnections. Or even when needing to make payments for a purchase. Disconnect has caused errors & failures by blocking captcha urls which then cause the payment to fail to complete. This is unacceptable.

Some Firefox developers reading this is are going to find this as an aggressive stance. Don't get me wrong, I'm all about privacy, ad blocking and not being tracking but not to this extreme level and unpredictable level of breakage this causes. I am not that paranoid about my bank tracking me that I would rather have it fail to login or be blocked from using its Bill Pay.

I appreciate the additional security being built into Firefox, but it seems to not play well with banks who seem to be on their own path for increasing security. These two paths don't seem to be converging.

I often wonder about this but I don't think banks are making these changes for security reasons. I think sometimes they are just making changes that are convenient and easier for them to implement. Firefox is making it more difficult by blocking perceived tracking scripts and tracking cookies and even cross-site cookies. Banks use cross-site cookies alot. I don't think Firefox is going to make them stop doing that. The banking industry is very stubborn and uses ancient technology from decades ago to keep a lot of its internal core parts still moving. Even though they make billions & billions of dollars, switching to new software can interrupt their business and if the data/software migration goes wrong (and they ALWAYS do) they can have a lot of downtime with transactions not being processed leading to a ton of lost money.

Some of the articles on this subject are amazing, shocking and scary all at the same time:

"The disparity between the legacy systems used by traditional banks and the new systems used by challenger banks is stark. Many banking legacy systems have been running for more than 30 years with an estimated over £2 trillion passing through legacy banks every day. With so much money relying on these systems it is understandably risky and complex to change them. All changes run the risk of introducing defects and potential vulnerabilities, so many banks have taken a risk averse approach."

Your experience with Barclays & ETP is simply unacceptable:

To make this point, yesterday I spent probably an hour and a 1/2 trying to get to another bank account on Barclays working again because they just "upgraded their web experience". I think I was able to get all the new URLs identified for my exception list for cookies, but blocking cross tracking also creates havoc and I had to turn it off to get the bank site to work. I tried to add sites to the exception list for cross tracking, but Firefox still showed it was blocking trackers even though I had added it to the exception list - so I gave up after all that time.

So I'm going to file a bug to have ETP have a clear and working OFF button in about:preferences#privacy. And no, going into ETP's Custom option & unchecking all the boxes is not acceptable or user-friendly. There must be a clear OFF button. And it must actually work.

Quite a few people have reported that temporarily disabling ETP via the Shield icon in the url bar does not work & does not stop blocking the cookies or scripts. That shocked me. Turning something off must simply turn it off.

I don't think the developers realize this privacy by default approach is harmful to the key aspects of everyone's lives where essential websites don't care about our privacy. To say that we must persist in this damaging relationship is not fair or sensible. Users who don't care & don't want to deal with ETP's extremely disruptive behavior that it can & will cause thanks to Disconnect's aggressive & overreaching blocking lists should have the right to completely DISABLE the feature. And as a tester and troubleshooter myself, users like me need a clear and definite way of disabling ETP without going to about:config & flipping a bunch of prefs off.

Wrapping up my point: I'm going to file a few bugs aimed at ETP:

  • To get a clear Disable/Off option so that ETP never activates at all in the slightest bit.
  • To get us to separate from Disconnect.me & start building our own lists or find a new trustworthy partner in this space. There used to be a "Change Block list" option. (This one will probably be difficult but its not impossible for Mozilla to do it)
  • To review tracking scripts and tracking cookies more regularly and get them removed from the blocking lists completely & permanently whitelisted
  • To create a list tracking the most popular sites to fail with ETP enabled and permawhitelist them. (But that's probably going to include a TON of sites so the list is going to get long fast but it will be worth it in the end)

In this last point, the idea would be to whitelist entire domains & not allow ETP to take any kind of action on the site even if it has suspected trackers on it. This should include any site dealing with payment processing, banks, shopping sites, webmail sites and more. Honestly at this point I could make the case that ETP should be disabled by default since the list of websites that should be permawhitelisted will overwhelm this whitelist very easily. ETP would then become a opt-in feature.

2nd wrapup: Sorry for the long post btw. These are thoughts I've been trying to organize and get out for a few months. And hopefully they can generate some momentum to make big changes to ETP in way that Firefox users will notice. Namely, that visiting websites work very reliably and don't fail to load, show blank pages, throw an error, fail to login, fall into redirect loops and anything caused by blocking tracking scripts/cookies & cross-site cookies.

There was a single person who posted about this 4 years in 2020 and I did not find it until recently, I was very unhappy about that because the suffering has continued since then: How to disable Enhanced Tracking Protection on all sites and for every FF session. Choosing Custom, and deselecting all check boxes doesn't work https://support.mozilla.org/questions/1273784

Every point he makes is sensible. And users should not have to be "clicking this or clicking that" or just scrambling to change options all the time. Surfing the internet smoothly should just work out of the box.

Geändert am von NoahSUMO

Hilfreich?

more options

Mi ClassB, sorry again for the long post above. Just needed to get it out. :)

What I really wanted to ask you was for a exact list of all the Barclays new URLs you identified for your Cookies exception list. We could possibly add these to a whitelist. I admire the work you put in to collecting all those urls & just hate that it still didn't work after doing all that.

My local bank uses a site named: web13.secureinternetbanking.com and in the past, I also needed to exempt cookies from sites named: cwsb40.checkfreeweb.com and cw411.checkfreeweb.com. I've also added these sites to the exceptions list for enhanced tracking without effect.

All these bank urls I've seen before experience issues with broken logins and Bill Pay going back a few years. Especially *.checkfreeweb.com. I'd be curious to get your full list of Exceptions from both your Cookies & Enhanced Tracking protection areas and see if we can't get them all whitelisted.

Also, do you use Standard, Strict or Custom mode for ETP? I'm curious if even Standard mode causes these failures in the bank sites for you.

Small note from my investigations: It appears Bank of America and Barclays have the most issues with Firefox over the years. Especially BOA. Now that could be the fault of BOA's web dev team making changes or ETP or a mix of both. I think stock trading sites like Etrade also broke quite a bit too. There are way too many banking sites to track btw lol

Geändert am von NoahSUMO

Hilfreich?

Stellen Sie eine Frage

Sie müssen sich mit Ihrem Benutzerkonto anmelden, um auf Beiträge zu antworten. Bitte stellen Sie eine neue Frage, wenn Sie noch kein Benutzerkonto haben.