1856125 - Images are still lazy loaded when scripting is disabled via content security policy

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect)

Description

[aoia7rz7l]

Bug 1842984 removed the dom.image-lazy-loading.enabled pref. I can confidently say that:

1. This is BAD, and
2. clearly no one involved in making this decision has ever browsed with JS disabled by default.

As you can clearly see in the diff the old comment that was added back when lazy loading was implemented,

// If scripting is disabled don't do lazy load.
// https://whatpr.org/html/3752/images.html#updating-the-image-data

And I am even going to quote the spec

If scripting is disabled for img, return false.
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.

But the logic for checking "if scripting is disabled" has always been flawed, at least in Firefox. It simply checks the global javascript.enabled pref, and disables lazy loading when and only when its value is false. And as anyone who disable JS by default can tell you, no one does it this way ever since NoScript is a thing, because there is simply not enough granular control to it. AFAIK all "modern" content-blocking extensions (NoScript/uBO/uMatrix) block JS by injecting/modifying CSP headers, so the browser is never aware that scripting is effective disabled in these circumstances. By removing the dom.image-lazy-loading.enabled pref, this "anti-tracking measure" is no longer in place even though a user has clearly indicated the intent to disable scripting for a particular site.

Ideally, this bug is about Firefox properly detecting CSP headers and disabling lazy loading accordingly. Realistically, I am willing to live with dom.image-lazy-loading.enabled because:

1. it's simpler this way,
2. no added complexity of whether to lazy load third-party images when third-party scripts are disabled,
3. many sites still run their own lazy loading scripts and will still lazy load images when dom.image-lazy-loading.enabled is false (pre-118) anyway, and
4. user agents should at least respect users' choice to enable or disable image lazy loading,

If you still need some more convincing that this is an issue, there are two open tickets over at TBB's issue tracker discussing the potential fingerability of lazy loading. I am also not too sure why dom.image-lazy-loading.enabled can be considered a "rollout pref" when there are still outstanding issues like bug 1650677.

Comment 1

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

:ren, since you are the author of the regressor, bug 1842984, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Gregory Pappas [:gregp]]

FWIW, it should still be possible to effectively turn off lazy loading by setting dom.image-lazy-loading.root-margin.* to a big number.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This seems like a duplicate of https://github.com/whatwg/html/issues/9113. I'm not sure how easy to do that would be. But fixing that would fix this and the relevant scripting media feature, and similar things.