Open Bug 1630949 Opened 7 months ago Updated 5 months ago

UrlClassifierSkipListService started during startup for uninteresting http requests

Categories

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

defect

Tracking

()

Tracking Status
firefox77 --- affected

People

(Reporter: Gijs, Unassigned)

References

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

Details

(Whiteboard: [fxperf:p2])

+++ This bug was initially created as a clone of Bug #1630939 +++

Splitting this discussion out of bug 1626935.

It seems the skip list service gets created relatively early during startup (AFAICT through https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/netwerk/url-classifier/AsyncUrlChannelClassifier.cpp#792 as soon as the first http channel is AsyncOpen'd).

I'm seeing the url-classifier run and create features for requests from about:newtab (notably image requests from the snippets CDN), and I don't see any obvious reason we wouldn't run the same code for internal fetch() requests, like the ones we use for update checks, captive portal checks, etc. That seems like it shouldn't ever result in anything getting blocked...

It also seems like we should avoid running them for document requests with system principal triggering principal (ie when the user explicitly requests opening a page in the toplevel docshell).

It seems like we could scope down when we need this information and thereby delay when we initialize this code, and that'd potentially help startup performance in the common case (without regressing things when automatic sessionrestore is enabled and we load webpages as the first thing in the initial window).

What does this involve? The URL classifier uses databases of URLs in order to classify things, no? Are we doing reads on those databases at this time?

(In reply to :Gijs (he/him) from comment #0)

+++ This bug was initially created as a clone of Bug #1630939 +++

Splitting this discussion out of bug 1626935.

I'm seeing the url-classifier run and create features for requests from about:newtab (notably image requests from the snippets CDN), and I don't see any obvious reason we wouldn't run the same code for internal fetch() requests, like the ones we use for update checks, captive portal checks, etc. That seems like it shouldn't ever result in anything getting blocked...

We check if a request is triggered by system privileged code here :)

It also seems like we should avoid running them for document requests with system principal triggering principal (ie when the user explicitly requests opening a page in the toplevel docshell).

We classify top-level load with system principal because users may still manually input a phishing URL.

Are you seeing URL classifier classifies requests that triggered by the system now (other than top-level load)?

(In reply to Dimi Lee [:dimi][:dlee] from comment #2)

Are you seeing URL classifier classifies requests that triggered by the system now (other than top-level load)?

I think the about:newtab ones probably don't have system principal, but should still fail that check (ie shouldn't trip the URL classifier).

(In reply to Doug Thayer [:dthayer] from comment #1)

What does this involve? The URL classifier uses databases of URLs in order to classify things, no? Are we doing reads on those databases at this time?

Yes, https://searchfox.org/mozilla-central/source/netwerk/url-classifier/UrlClassifierSkipListService.jsm runs the remote settings constructor and tries to get the contents of the DB.

Blocks: 1627071
Whiteboard: [fxperf] → [fxperf:p2]
Priority: -- → P3
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.