Closed Bug 1952759 Opened 1 year ago Closed 1 year ago

ETP preventing replies to articles on Yahoo

Categories

(Web Compatibility :: Privacy: Site Reports, defect, P2)

Product:
Web Compatibility
Component:
Privacy: Site Reports
Version:
Firefox 135
Type:
defect

Tracking

(Webcompat Priority:P2, Webcompat Score:6)

Status:
RESOLVED FIXED
Project Flags:
Webcompat Priority P2
Webcompat Score 6

People

(Reporter: cmwmlw, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: webcompat:needs-diagnosis, webcompat:site-report, webcompat:tracker-blocking)

User Story

platform:windows,mac,linux,android
impact:feature-broken
configuration:common
affects:all
branch:release
user-impact-score:300

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

I attempted to reply to an article on us.yahoo.com.

Actual results:

There is a button for View Comments at the bottom of most articles which not only shows what others have already posted, but provides an input field to add your own comments. When you click that button with ETP Strict enabled all you get is white space, no input field or previous comments are shown.

Expected results:

All previous comments should appear, there should also be an input field to add your own.

If you use ETP Custom and enable everything but trackers it works as expected. Based upon my research it seems to have something to do with blocking spot.im, but not being an expert in decoding things like that means I can't be 100% certain.

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Component: Privacy: Anti-Tracking → Privacy: Site Reports
Ever confirmed: true
Product: Core → Web Compatibility
Severity: -- → S2
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: --- → 6
Keywords: webcompat:needs-diagnosis, webcompat:site-report
Priority: -- → P2

Thank you for reporting this!

Any update on a resolution to this issue?

This bug has been fixed by a permanent intervention.

This is an automated assessment, if this bug still reproduces for you in the most recent Nightly version, please reopen.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

The link to bug 1962443 says the following...

We have added a global, permanent intervention in private browsing mode for *.spot.im

Does that mean the fix has not been applied to non-private windows?

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

(In reply to Jim from comment #5)

The link to bug 1962443 says the following...

We have added a global, permanent intervention in private browsing mode for *.spot.im

Does that mean the fix has not been applied to non-private windows?

This is correct. However, in non-private windows, this would only be an issue in ETP-Strict/Custom mode and these are currently considered WONTFIX as we cannot automatically apply exceptions if the user has requested strict tracker blocking.

We are working on a UI that would allow manually opting in to these exceptions but we don't have a release date yet. If you are using ETP-Strict then we recommend for now to use ETP-Standard + Private Browsing for the site in question.

Status: REOPENED → RESOLVED
Closed: 1 year ago → 1 year ago
Resolution: --- → FIXED

Unless I'm misunderstanding, that sounds backwards. Why would private windows allow exceptions when standard ones do not? If anything, it should be the exact opposite. If someone has enabled private windows the assumption is they want additional security and anonymity, not the other way around.

I don't know what the overall FireFox usage metrics reveal, but I suspect somewhere around 99% of the people are not in private windows 99% of the time. I also have to assume that just about everyone who uses ETP is running it in strict mode, unless they uncover bugs like this one there really should be no reason not to.

What it sounds like is the user would have to identify that blocking spot.im is the culprit, load a private window, change the ETP mode and then get back to what they were doing? The bug report saying "multiple sites becoming unusable" indicates a more universal solution is required as the impact has been encountered by seemingly many others. Private browsing and standard ETP might be a way to mask the issue, but it doesn't solve the problem. It's also an unnecessary inconvenience.

(In reply to Jim from comment #7)

Unless I'm misunderstanding, that sounds backwards. Why would private windows allow exceptions when standard ones do not? If anything, it should be the exact opposite. If someone has enabled private windows the assumption is they want additional security and anonymity, not the other way around.

So, there is two reasons for private browsing being mentioned specifically here:

  1. If you use ETP-Standard and switch to private browsing, the tracker blocking component of ETP behaves like strict - as in, more trackers are being blocked. Therefore, most of the breakage you see with ETP-Strict turned on also reproduces with ETP-Standard, but only in private browsing mode.

  2. Private browsing mode has ephemeral storage plus additional anti-fingerprinting features enabled, that mitigate the effect of loading certain trackers, which is why it is easier to make certain exceptions to make the site work.

I don't know what the overall FireFox usage metrics reveal, but I suspect somewhere around 99% of the people are not in private windows 99% of the time. I also have to assume that just about everyone who uses ETP is running it in strict mode, unless they uncover bugs like this one there really should be no reason not to.

That's actually not the case, private browsing mode is way more prevalent than ETP in strict mode. In fact, strict mode is a very rare configuration, less than 2% of all users use strict mode. And yes, breakage in strict mode is very prevalent, we had about 1000 bugs on file when this work started at the beginning of the year.

What it sounds like is the user would have to identify that blocking spot.im is the culprit, load a private window, change the ETP mode and then get back to what they were doing? The bug report saying "multiple sites becoming unusable" indicates a more universal solution is required as the impact has been encountered by seemingly many others. Private browsing and standard ETP might be a way to mask the issue, but it doesn't solve the problem. It's also an unnecessary inconvenience.

As mentioned before, we are working on improving the situation by adding additional UI/UX that gives you the option to opt-in to these exceptions either on a page-by-page basis or to all exceptions. But unlike for standard, we cannot do this for strict users without adding new UI. When you selected strict mode, you acknowledged that sites may break because of your choice and that you want full tracker blocking, so we cannot just overrule that setting and automatically apply anything.

Building the new feature for ETP strict mode is something we are actively working on next, but we had to prioritize private browsing mode first because there are a lot more users affected there that have never opted-in to site breakage at all.

If in the meantime, there was a pref that allowed you to simply opt into applying all available exceptions, would you use it?

Flags: needinfo?(cmwmlw)

Thank you for the detailed information, that helped clarify the situation better.

I must admit to being surprised to hear your private mode/ETP strict comments; I don't know many people using FF, but of those that I do they're the opposite of that demographic. Similar to me, they use non-private mode and strict ETP for everything (or very close to it). Other than now, I can't even recall the last time I ran into an issue using that configuration. Things almost universally just worked, blocking spot.im was the first time I encountered a problem that caused a mainstream website to not function correctly.

If in the meantime, there was a pref that allowed you to simply opt into applying all available exceptions, would you use it?

I'm not quite sure what the ask is here, can you expand upon that some?

Flags: needinfo?(cmwmlw)

(In reply to Jim from comment #9)

If in the meantime, there was a pref that allowed you to simply opt into applying all available exceptions, would you use it?

I'm not quite sure what the ask is here, can you expand upon that some?

Basically, if you had an option in the ETP settings under Strict that, lets say a checkbox, that would make websites like the one in this bug work automatically (i.e. in this case it would detect that you are on Yahoo and an exception for spot.im is available and would automatically apply it to make the website work properly), would you use that?

So I'm in a normal browsing window, ETP set to strict. FF checks the URL, see I have an exception for spot.im on that website and would only allow it there? If my understanding is correct, that seems like a reasonable approach. Is that the UI/UX change you mentioned prior?

You need to log in before you can comment on or make changes to this bug.