Prevent CSS-based scriptless interaction tracking

assigned to @ma1

added Doing label

Interestingly (ugh!) this doesn't affect Firefox + NoScript, at least for 3rd party resources, because of the forced CSS prefetching protection against PP0.

Unfortunately, though,

if (!(ns.policy.isTorBrowser || ns.allows("unchecked_css"))) {
    // protection against CSS PP0, not needed on the Tor Browser because of its
    // noisy DNS resolution: https://orenlab.sise.bgu.ac.il/p/PP0

So my proposal to fix this would be enabling this protection on Tor Browser too, including same host requests.

We should probably upstream this concern to mozilla, and ask for a test to cover this. Similarly regarding https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42828, and they should be able to confirm what is happening at the low level. In principle, any of these delayed loads can be used in a similar way, and we'll probably get more in the future as well. So it would be nice if they had a low-level solution for us and some test coverage so this doesn't get regressed as they add more optimizations.

Security and networking is not really my area though, so I'm not sure I'm the best person to follow this through. @ma1 could you do it? That way you would by default be able to see the confidential bugzilla discussion.

@ma1 could you do it? That way you would by default be able to see the confidential bugzilla discussion.

On it.

Place the element with content: url() in <details>. Only loads when the <summary> is clicked.

And with ESR 128, also with <button popovertarget="i"> and <img id="i" popover="" />.

changed the description

Before we go down these routes (prefetching all the CSS images and asking for upstream help), one philosophical question: is the "Safest" security level actually supposed to block this kind of behavior under our threat model / specification?

Once you start clicking stuff (i.e. <summary>, <button>), you kinda expect to send signals to the other side of the web.
Triggering a request on :hover and :focus* is a bit more unexpected and therefore concerning?
My understanding is that disabling scripts in "Safest" is meant more as a last-line defense against 0 day browser exploits and maybe to mitigate sophisticate, fine-grained, invasive user interaction tracking / fingerprinting (e.g. measuring typing or mouse movements patterns). This technique seems too much fuzzy and coarse-grained to actually matter (even though I can imagine ways to overcome the "fires once" limitation, for instance)

WDYT?

/cc @morgan, @pierov, @thorin

is the "Safest" security level actually supposed to block this kind of behavior under our threat model / specification?

No, I don't think we're trying to do anything behavioral-related. Reducing the time accuracy somehow helps in this regards.

My understanding is that disabling scripts in "Safest" is meant more as a last-line defense against 0 day browser exploits

Yes, especially this.

maybe to mitigate sophisticate, fine-grained, invasive user interaction tracking / fingerprinting (e.g. measuring typing or mouse movements patterns)

Well, this is a side effect. Without JS fingerprint measurements are much more limited (even though I'd expect possible with similar strategies).

Yeah, I wasn't sure, but the HTML spec for the lazy loading of img and iframe specifically carved out the no-scripting exception for this reason. I guess it would be of interest to whoever implemented this if this can achieve a similar result.

So this is more of a privacy issue than a security issue, and so not applicable to just Safest.

I think an argument can be made that hovering a traditionally non-interactable element (eg a div, an img, etc versus a button) shouldn't have hidden side-effects.

If we do fix this (ie pre-fetch everything pre-fetch'abl) I think it should apply universally not just on Safest even though the same affect can be achieved by doing the request in JS on Standard.

What's the main source of concern here? Gaze/mouse tracking telemetry basically?

Also agree if we do fix this should happen as low as possible w/ upstream tests .

can someone explain why this is a concern - what does it add to linkability or fingerprinting?

can someone explain why this is a concern - what does it add to linkability or fingerprinting?

From the Henry's comment link:

This is an anti-tracking measure, because if a user agent supported lazy loading when scripting is disabled, it would still be possible for a site to track a user's approximate scroll position throughout a session, by strategically placing images in a page's markup such that a server can track how many images are requested and when.

In the past we had already decided not to do anything for lazy loading (#40056 (closed)).

sorry to beat this drum - but since when is scroll position (scroll speeds notwithstanding) an issue - it's a ~~per site~~ per-page, user-action

@thorin I think this is not really a fingerprinting issue. It is a different privacy concern. It is more the idea that a scriptless webpage should never be able to inform the website how the user is interacting with it. I.e. it should act more like a PDF document: initial download, then only further network activity when you follow a hyperlink.

E.g. if your web page contains a list of hyperlinks to third party domains, the host would be able to guess which third party link you clicked.

Obviously you could fill your website with internal hyperlinks and all sorts of tracking parameters to force the user to reveal their path and exactly what they are trying to do, but this would be fairly awkward and transparent to the user since they can read a hyperlink before clicking it.

thanks henry ... that's what I thought - it's not universal i.e all sites [1] - pretty much low target if any. I have deliberately ignored these sorts of things - e.g. observer

[1] now I say that but some things can be used for correlation - for example, you cannot hide you have a mouse once you start moving the pointer around (99% sure, I have a nasty PoC in the works - takes the order of all events), etc - so some user actions are worthy FP metrics, e.g. fullScreen API and so on - they have consequences that result in universal metrics.

If I've understood correctly, this feature effectively allows tracking of what the user reads/consumes when JavaScript is not enabled which is unexpected and a privacy concern unrelated to linkability.

@ma1 Is there enough info for you to go on?

It seems like the consensus seems to be no this isn't a Security Level consideration and we should always disable CSS pre-fetching always.

@morgan (sorry I accidentally edited your comment, rather than quoting/replying, it should be restored now):

If I've understood correctly, this feature effectively allows tracking of what the user reads/consumes when JavaScript is not enabled which is unexpected and a privacy concern unrelated to linkability.

Yes. In my understanding it actually belongs to a set of features which I'd call "user interaction dependent subresource loading", including the "lazy" loading attribute (#40056 (closed)), to be reconsidered in this light.

@ma1 Is there enough info for you to go on?

Yes, as you know I was already working at a stopgap countermeasure to be shipped during the weekend in NoScript 11.4.35 (see below).

It seems like the consensus seems to be no this isn't a Security Level consideration

Not a Security Level consideration per se, but related to Safest because users who explicitly disable JavaScript may not expect interaction within the page (like mouse hovering or scrolling, with no apparent navigation) to be traceable.

we should always disable CSS pre-fetching always.

You probably rather mean "force subresource preloading" (which is quite the opposite of disabling pre-fetching).

And rather than "always", given both the potential performance implications and the assumption that JavaScript provides hostile pages with many more effective means to reach the same tracking goal, we should preload when JavaScript is user-disabled (in our case, at the Safest security level).

Therefore, as discussed last week on IRC, I'm provisionally shipping a NoScript-based mitigation by extending the "unrestricted CSS" capability semantics to any "user interaction dependent subresource loading" we know of (or we may learn about in the future), forcing such subresources to be preloaded when the capability is disabled and relying on the fact that we already disable this capability at the Safest Level.

@tjr is this something that you believe could realistically be translated in a built-in Firefox feature at some point in the future?

Is this going to be a problem for mobile users?

Esp., can this become a sort of DoS attack? E.g., reference big assets that will never be actually used and consume your resources.

can this become a sort of DoS attack? E.g., reference big assets that will never be actually used and consume your resources.

Yes it could. As much as this I suppose, though?

<noscript>
<img src="verybigstuff.jpg">
</noscript>

thanks for the explanation @ma1!

My thoughts:

This isn't a Security Slider thing. The Security Slider is for Security, defense against 0-days. Not Privacy. You accidently get more privacy via the slider, because some features like JS are disabled, but once you add privacy-only behaviors to the slider you're starting down a slippery slope. Less so in the sense of "This will hurt our users" and more so in the sense of "This means we're making decisions that are kind of ancillary or inconsistent with our threat model of what we try to protect against and what we don't and it will result in more conversations (like this one) and more effort and brainpower being drawn from the things that are more directly in line with our threat model (and goals in usability.)"
What you're trying to do is treat a webpage as a static piece of content that once loaded, provides no feedback to the server about user behavior. If that is something you want to add to the threat model as an explicit goal, then so be it. It's going to require a concerted effort to identify the ways it can be broken (e.g. lazy image loading!). If you want to support such a feature, it might be easier to load the page, wait for the loading to be 'done' (don't ask me how you know that, but let's pretend you do), take a screenshot (I think that feature is still in the browser, right?), and then replace the page with the screenshot and discard the context.
I don't think this is a worthwhile goal to have. Under some use cases I suppose it might be nice, but has anyone in user studies ever said they wanted it? I doubt it's something they've ever considered. That said, if you asked someone "If a website added tracking information to a page to learn that a user was scrolling down it - not that you personally are doing it, but whoever the anonymous user is, they're scrolling down and reading more of the page - is that a concerning privacy leak to you?" - what would they say?
"is this something that you believe could realistically be translated in a built-in Firefox feature at some point in the future" - maybe I've biased myself by having the above opinions, but I think the relevant engineers would consider this an unnecessarily complex feature. That said, if you showed up with a patch and the patch wasn't that complicated - maybe they'd take it anyway.

I agree with Tom.

I don't think we can do much (and even for safest I don't think it's worth developing).

If a person is worried about this they should probably choose "work offline" once a page has been loaded.

All right.

We get both loading="lazy" neutering and CSS resources prefetching for free in NoScript 11.4.35, and it's now (since rc3) configurable via two distinct capabilities (lazy_load and unrestricted_css).

Both capabilities get automatically disabled on scriptless presets unless user explicitly change them, so the Tor Browser with NoScript 11.4.35 will get this configuration automatically on Safest (and individual script-disabled pages, if any) like all the other NoScript users unless we decide to explicitly handle those capabilities (e.g. re-enable them back, in order not to force any eager loadoing) in our SecurityLevel module.

If anybody wants to take it for a ride, RC4 is here, and I plan submit it as next stable to AMO in ~12 hours.

I agreed with tom before tom answered - #42829 (comment 3053273)

pretty much low target if any

be smart, be like thorin

Regardless of the conclusion in Tor Browser, we should still upstream this information to Mozilla since this is an easy work-around for a protection they explicitly added as part of the HTML specification.

Regardless of the conclusion in Tor Browser, we should still upstream this information to Mozilla since this is an easy work-around for a protection they explicitly added as part of the HTML specification.

IIUC you suggest to open a (confidential?) mozbug noting the contradiction between obeying the specification by disabling loading="lazy" on pages where "scripting is disabled" as "an anti-tracking measure", and neglecting to do the same for CSS features which are equivalent in their potential for abuse, and let Mozilla folks discuss. I'm fine with that.

On a side note, since the definition of "scripting is disabled" used in the spec and in the implementations does not include CSP-based script blocking like NoScript's, I'd still argue that users who aren't aware of this quite arcane difference may find the lazy loading behavior of pages script-blocked by NoScript < 11.4.35 quite confusing / unexpected.

ok, I opened bugzilla bug 1919496 to pass on the information upstream to let them know. I CCed ma1 and morgan.

added All Platforms label

added Bug label

The mitigation we discussed is included in the just released NoScript 11.4.35rc2. If no disaster is reported by beta testers, I'll submit 11.4.35 stable to AMO over the weekend or early next week, in time for inclusion in next Tor Browser releases.

Relevant commits: