1644738 - Strict Enhanced Tracking Protection blocking content even when ETP is disabled for a site

Status: VERIFIED FIXED

(Core :: Privacy: Anti-Tracking, defect, P1)

Description

[joseluisbolos]

Attachment: Firefox-77-tracking.jpg

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36

Steps to reproduce:

1. Create a new, empty Firefox profile
2. Open Firefox
3. Enable Strict enhanced tracking protection
4. Browse https://www.nature.com/articles/nature15393 - Ads are missing (as expected).
5. Click on the shield to disable enhanced tracking protection for that site
6. Reload the page

Actual results:

Main content loads fine but some third parties (like the ads) fail to load.

Console displays:
The resource at “<URL>” was blocked because content blocking is enabled. (x6)

Expected results:

Page should have loaded fully and I would expect that no third parties are blocked, as enhanced tracking protection is disabled.

Comment 1

[joseluisbolos]

Attachment: about:support info

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Patrick]

Attachment: about:support

Can confirm this bug - was able to reproduce following the steps provided on: https://www.adelaidereview.com.au/issues/484/

```

Comment 4

[Patrick]

I'm also experiencing this bug on https://www.adelaidereview.com.au/issues/484/ & can repro following joseluisbolos' instructions. Thanks for the detailed report joseluisbolos!

Comment 5

[Steven Englehardt [:englehardt]]

Thanks for the reports! I can reproduce this on the latest Nightly as well. Looks like this has been broken since 76 release. I ran mozregression to narrow it down:

2020-06-29T13:41:23.727000: INFO : Narrowed integration regression window from [7e133379, 120c7c6a] (3 builds) to [9b889a0e, 120c7c6a] (2 builds) (~1 steps left)
2020-06-29T13:41:23.733000: DEBUG : Starting merge handling...
2020-06-29T13:41:23.733000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=120c7c6a1961c2caf92d3eb2859048f50c23fc54&full=1
2020-06-29T13:41:23.733000: DEBUG : redo: attempt 1/3
2020-06-29T13:41:23.733000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=120c7c6a1961c2caf92d3eb2859048f50c23fc54&full=1',), kwargs: {}, attempt #1
2020-06-29T13:41:23.736000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2020-06-29T13:41:24.158000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=120c7c6a1961c2caf92d3eb2859048f50c23fc54&full=1 HTTP/1.1" 200 None
2020-06-29T13:41:24.210000: DEBUG : Found commit message:
Bug 1612378 - Part 11: Change isOnContentBlockingAllowList in storageAccessAPIHelpers.js to use allowListed flag instead of permission. r=baku

Because we remove the content blocking allow list permission from the
permission preload list. The permission in the third party window might
not be available when we check it. So, we move to check the allowListed
flag which is passed by the test framework instead of check the
permission.

Depends on D66737

Differential Revision: https://phabricator.services.mozilla.com/D68189

Tim would you mind to look into this?

Comment 7

[Tom S. (please needinfo tschuster)]

Bug 1649371 was bisected to the exact change https://phabricator.services.mozilla.com/D68189

Comment 8

[Tim Huang[:timhuang]]

Sure, I will take a look.

Comment 9

[Tim Huang[:timhuang]]

Attachment: Bug 1644738 - Propagate the IsOnContentBlockingAllowList in CookieJarSettings to the script generated document. r?baku!

We also need to propagate the IsOnContentBlockingAllowList to the script
generated document. For this kind of document, it won't have the
CookieJarSettings at the first place. It will generate its
CookieJarSettings when someone requests it. And we need to propagate the
flag when generating the CookieJarSettings in this case. Or the script
generated document will have a wrong IsOnContentBlockingAllowList flag.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/82fef53594b0
Propagate the IsOnContentBlockingAllowList in CookieJarSettings to the script generated document. r=baku

Comment 11

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/82fef53594b0

Comment 12

[Tim Huang[:timhuang]]

I can confirm that this issue has been fixed in the latest Nightly.

Comment 13

[Tim Huang[:timhuang]]

Attachment: esr.patch

Comment 14

[Tim Huang[:timhuang]]

Comment on attachment 9160861 [details] [diff] [review]
esr.patch

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Disabling ETP for a site is broken.
• User impact if declined: The user cannot disable the ETP protection for a site.
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch is not risky since it is a small fix.
• String or UUID changes made by this patch: None

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Does this need a Beta approval request too?

Comment 16

[Tim Huang[:timhuang]]

Thanks Ryan,

Yes, I think this also needs a Beta approval, I will do it today.

Comment 17

[Tim Huang[:timhuang]]

Comment on attachment 9160435 [details]
Bug 1644738 - Propagate the IsOnContentBlockingAllowList in CookieJarSettings to the script generated document. r?baku!

Beta/Release Uplift Approval Request

• User impact if declined: The user cannot disable the ETP protection for a site.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Create a new, empty Firefox profile

2. Open Firefox
3. Enable Strict enhanced tracking protection
4. Browse https://www.nature.com/articles/nature15393 - Ads are missing (as expected).
5. Click on the shield to disable enhanced tracking protection for that site
6. Reload the page
7. Check the console, there should be no blocking message

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch is not risky since it is a small fix.
• String changes made/needed: None

Comment 18

[Julien Cristau [:jcristau]]

Comment on attachment 9160435 [details]
Bug 1644738 - Propagate the IsOnContentBlockingAllowList in CookieJarSettings to the script generated document. r?baku!

the lack of automated tests seems unfortunate..

approved for 79.0b4.

Comment 19

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b8048104e8e0

Comment 20

[Negritas Sergiu, Desktop QA]

Hello! I have managed to reproduce the issue following the STR provided in the description using Firefox Nightly 79.0a1 (2020-06-03).

I can confirm that the issue is fixed on firefox 79.0b4 and Nightly 80.0a1 (2020-07-07) on Windows 10, Ubuntu 18.04 LTS and MacOS 10.15.6

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9160861 [details] [diff] [review]
esr.patch

Approved for 78.1esr.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/d12deadbcf40

Comment 23

[Negritas Sergiu, Desktop QA]

Hello! I can confirm that the issue is fixed on Firefox 78.1.0esr on Windows 10, Ubuntu 18.04 LTS and MacOS 10.15.6 .

The build was donwloaded from https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr78&selectedTaskRun=bz0inGBPSV6jIsn0mV-HWw.0 with the date of 2020-07-14.