> 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.
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.
> 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".
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.
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.
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.