Make sure Tracking Protection covers about: pages

NEW
Unassigned

Status

()

Toolkit
Safe Browsing
P2
normal
10 months ago
a month ago

People

(Reporter: gcp, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox54 affected, firefox55 affected, firefox56 affected)

Details

(Whiteboard: tp-leak)

(Reporter)

Description

10 months ago
Tracking protection currently doesn't seem to apply to about:* pages. Given that some pages load external sites through iframes, this will allow some trackers to get through. This has given rise to some controversy about the "Get Add-ons" page.

We should also make sure this works correctly when having both private and non-private windows open.

Comment 1

10 months ago
same as bug 1380409?
Duplicate of this bug: 1380409
@tofumatt: Once we fix this oversight, the Shield icon will start to show up on about:addons for people with tracking protection enabled. You may want to avoid loading it for people with DNT enabled. TP will automatically send the DNT signal so that will solve this UX issue.

This hacks post is our recommended way of using Google Analytics: https://hacks.mozilla.org/2016/01/google-analytics-privacy-and-event-tracking/
This is a regression introduced by bug 1337043. We should back it out and come up with a better solution to address the performance problem.

It's now clear that we can't rely on about: pages to not load arbitrary web content, so I guess we'll have to instead whitelist the about: pages which are known to be local-only.

Christoph: do you know if there's a larger problem with our trusting too much the about: scheme in platform code or is it limited to the URL classifier?
Blocks: 1337043
status-firefox54: --- → unaffected
status-firefox55: --- → affected
status-firefox56: --- → affected
Flags: needinfo?(ckerschb)

Comment 5

10 months ago
> the Shield icon will start to show up on about:addons for people with tracking protection enabled. You may want to avoid loading it for people with DNT enabled. TP will automatically send the DNT signal so that will solve this UX issue.

Will this also stop showing the shield icon on other websites?
TBH showing the shield icon, while slightly irritating ("What? trackers blocked on about:addons??") is actually accurate, isn't it?
(In reply to Ralf Jung from comment #5)
> > the Shield icon will start to show up on about:addons for people with tracking protection enabled. You may want to avoid loading it for people with DNT enabled. TP will automatically send the DNT signal so that will solve this UX issue.
>
> Will this also stop showing the shield icon on other websites?

Only if those websites avoid loading GA when they are sent the DNT signal. What the Hacks proposes is that you check DNT because you load GA on your website.

If GA is not loaded (because the user has DNT enabled) then there is nothing to block so the TP shield doesn't appear. (The Shield is a sign that something was blocked by TP.)

Comment 7

10 months ago
Ah, got it -- "loading it" was referring to loading GA, not loading the icon. Thanks :)
Comment hidden (offtopic)
(Reporter)

Comment 9

10 months ago
Someone on reddit reported that the issue reproduces just as well in Firefox 54, and I can confirm this. GA is loaded when visiting about:addons, but not when visiting other web properties.
status-firefox54: unaffected → affected
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)
(In reply to François Marier [:francois] from comment #4)
> This is a regression introduced by bug 1337043. We should back it out and
> come up with a better solution to address the performance problem.
> 
> It's now clear that we can't rely on about: pages to not load arbitrary web
> content, so I guess we'll have to instead whitelist the about: pages which
> are known to be local-only.

Is bug 1337043 really at fault here? My understanding is that the about:addons page is the toplevel one, but the URL Classifier should still be classifying the iframe that is loaded inside it which has a regular URL. Or does the classifier only classify top-level documents?

If yes, I'm fine if we change bug 1337043 to only whitelist about:blank and about:home, as long as we check that it doesn't regress the win of not initializing NSS before first paint (see bug 1337043 comment 63). It's probably better to keep classifying about:newtab anyways.
(In reply to François Marier [:francois] from comment #4)
> Christoph: do you know if there's a larger problem with our trusting too
> much the about: scheme in platform code or is it limited to the URL
> classifier?

I think the scope is limited to tracking protection because if iframes load external content, then those go through the regular loading process, meaning that depending on their protocol applicable security checks are performed, nonetheless if toplevel is a local resource like about or not.
Flags: needinfo?(ckerschb)
(In reply to Gian-Carlo Pascutto [:gcp] from comment #9)
> Someone on reddit reported that the issue reproduces just as well in Firefox
> 54, and I can confirm this. GA is loaded when visiting about:addons, but not
> when visiting other web properties.

And it's no longer reproducible on AMO because AMO now honours DNT: https://github.com/mozilla/addons-frontend/issues/2785#issuecomment-315212909

We'll have to create a test about: page with GA on it to make sure the underlying Safe Browsing bug is fixed.
(In reply to :Felipe Gomes (needinfo me!) from comment #13)
> If yes, I'm fine if we change bug 1337043 to only whitelist about:blank and
> about:home, as long as we check that it doesn't regress the win of not
> initializing NSS before first paint (see bug 1337043 comment 63). It's
> probably better to keep classifying about:newtab anyways.

about:blank is clearly not a problem. about:home could in theory cause issues because it loads remote resources (e.g. the snipet), but is probably unlikely to grow a GA dependency anytime soon.
Priority: -- → P2
Blocks: 1410920
Depends on: 1408410
Duplicate of this bug: 1451307
Whiteboard: tp-leak
You need to log in before you can comment on or make changes to this bug.