[pdonis]

> Zooming basically changes the dimensions of the viewport as JS/CSS see it.

I don't care what the website's JS/CSS says. At the end of the day the browser has a rendered canvas; I just want to zoom the canvas (and clip it at the window dimensions, providing scrollbars if necessary, if zooming makes it larger than the window dimensions). The browser shouldn't have to re-run anything to do that; zooming and clipping a canvas are graphics operations that have existed in computers for as long as there have been computers with graphics at all.

[olliej]

When people increase their font size/zoom they generally don't want that - what you're describing is the default zoom on phones, etc which is different from increasing the page text size, and you'll note is typically about increasing undersized ui components rather than simply reading text.

When people are in a browser and expanding the content they want the content reflowed - having to scroll to read the width of a line is super obnoxious, and makes reading text much harder. This is made even more frustrating when you recall that a lot of time the reason for zooming is to make things easier to read.

There are very few times where the correct response to "increase the zoom" is simply an affine transform of the rendered content, from both a usability standpoint or from user intent.

[pdonis]

> When people are in a browser and expanding the content they want the content reflowed

Even if this is the case, I don't see why the browser has to re-run anything from the website or tell the website anything. It can just do the reflow operation locally. Yes, the central data structure then is the DOM rather than a rendered canvas, but the DOM is still held locally.

[hombre_fatal]

You can always zoom the website using built-in OS zooming.

However, browser zooming incurs layout logic. It's no different that resizing the browser viewport. Code is run on the site (whether CSS or JS) to determine how the site should render at that size.

CSS/JS is run even when loading the site in the first place. There is nothing special about zooming, so it's like asking why layout code has to be run when you visit a site.

Well, you can turn off JS and CSS styling, but that's too hamfisted for most people.

Here's how a site can load different stylesheets depending on viewport width:

    <link rel="stylesheet" media="screen and (min-width: 601px)" href="desktop.css" />
    <link rel="stylesheet" media="screen and (max-width: 600px)" href="mobile.css" />

It's unclear to me what you think should happen on first website load vs. zooming.

[slobotron]

And JS can detect that and send it back to the server.

[olliej]

I’m not sure what you’re suggesting. Reflow and relayout is entirely local just as it is if you resize your window.

What are you concerned is happening?

[pdonis]

> Reflow and relayout is entirely local just as it is if you resize your window.

Then why does the zoom level reset itself to 100% every time I reload the page if I set privacy.resistFingerprinting = true?

> What are you concerned is happening?

I'm concerned that setting privacy.resistFingerprinting = true breaks a feature (that my browser remembers the zoom level for a given site so I don't have to reset it every time I reload that site) that should, as you say, be "entirely local".

[olliej]

Ah ok, I see what's happening.

The issue is not related to page loads, and layout behaviour is not impacting or causing differing load behavior.

First we need to consider what the goal of fingerprinting a browser is, and subsequently how that is done. The goal is not just "track a user", it is "track a user without using any explicit storage", so no cookies, client storage, etc. So instead all that a fingerprinting service can do is read implicit data from the browser, and using a collection of that data construct a unique ID. Most data that you read will be the same across large numbers of browsers: user agents, installed fonts, etc so what you do is build up a signature from those properties that vary from the mean. If you query enough different properties that hope is that you can accumulate enough variation to create a unique (-enough?) identifier that persists for that user.

Which gets us to your feature. The enormous majority of users have default zoom. So if your browser presents a different zoom level that provides a large amount of information to uniquely fingerprint you.

Hence `privacy.resistFingerprinting = true` disables non-default zoom on load, because it's directly finger-printable.

Does that make it more clear what's going on?

[pdonis]

> Does that make it more clear what's going on?

No. I already understand why non-default zoom gives websites a way to fingerprint you, if your browser insists on telling the websites that you have a non-default zoom level.

What I don't understand, and what nobody in this discussion has been able to explain, is why a browser with privacy.resistFingerprinting = true can't just lie to the website about what the zoom level is. You have said that zoom should be a local operation; that means the browser shouldn't have to tell the website anything about the actual zoom level if the user doesn't want it to. It should just load the page, telling the website whatever default things it tells the website when privacy.resistFingerprinting = true, including, presumably, a default zoom level, and then do the local zoom operation afterwards.