4 ms·

> comparing the resulting size of the element to a baseline This is the real hole, imo. 99% of web pages should not need that kind of information. I’m close to

> comparing the resulting size of the element to a baseline This is the real hole, imo. 99% of web pages should not need that kind of information. I’m close to thinking 100% shouldn’t, although I understand its need in particularly advanced applications. Maybe there should be a sandbox specifically for these very advanced JavaScript apps - nothing else should be allowed to get font metrics.

vekker 7y ago
Is it? It seems to me getting the size of an element is a pretty basic operation that a lot of scripts use.
- oneeyedpigeon 7y ago
  Maybe scripts for advanced apps, but most apps and all content shouldn’t have the slightest interest in positioning elements down to the pixel.
  - vekker 7y ago
    35% of all websites run Wordpress. A lot of those sites run pre-made templates which often heavily use jQuery scripts to show pop-ups, sliders, tooltips, what have you... Accessing the width/height of an element is pretty standard in those scripts. That's not at all limited only to advanced apps. I'm just saying that simply blocking or limiting that part of the DOM API is probably not a practical solution.
jefftk 7y ago
This is equivalent to saying that nothing dynamic can depend on the position or size of elements. Which means you can't use <picture> or srcset to load different images in different cases, because that can be exploited to leak what size other elements are. You can't use media queries to affect anything that can send requests. There can't be any way to lazy-load images that are way down the page. From an anti-fingerprinting perspective you do much better to restrict what system fonts are available than to remove all of these valuable and common reactive features.
- oneeyedpigeon 7y ago
  > This is equivalent to saying that nothing dynamic can depend on the position or size of elements. Unless that dependency is specified in a style sheet language, yes. I think that’s exactly how it should be: the web of 'apps' is fine to break this if it wants, the web of 'content' shouldn’t be concerned with extremely detailed matters of presentation. > From an anti-fingerprinting perspective you do much better to restrict what system fonts are available Agreed; I’m not saying there isn’t lower hanging fruit, I’m just commenting on the one that interested me.
  - jefftk 7y ago
    The problem is, even if you restrict this to being specified in CSS it can still be used for fingerprinting

vekker 7y ago

Is it? It seems to me getting the size of an element is a pretty basic operation that a lot of scripts use.

oneeyedpigeon 7y ago
Maybe scripts for advanced apps, but most apps and all content shouldn’t have the slightest interest in positioning elements down to the pixel.
- vekker 7y ago
  35% of all websites run Wordpress. A lot of those sites run pre-made templates which often heavily use jQuery scripts to show pop-ups, sliders, tooltips, what have you... Accessing the width/height of an element is pretty standard in those scripts. That's not at all limited only to advanced apps. I'm just saying that simply blocking or limiting that part of the DOM API is probably not a practical solution.

jefftk 7y ago

This is equivalent to saying that nothing dynamic can depend on the position or size of elements. Which means you can't use <picture> or srcset to load different images in different cases, because that can be exploited to leak what size other elements are. You can't use media queries to affect anything that can send requests. There can't be any way to lazy-load images that are way down the page. From an anti-fingerprinting perspective you do much better to restrict what system fonts are available than to remove all of these valuable and common reactive features.

oneeyedpigeon 7y ago
> This is equivalent to saying that nothing dynamic can depend on the position or size of elements. Unless that dependency is specified in a style sheet language, yes. I think that’s exactly how it should be: the web of 'apps' is fine to break this if it wants, the web of 'content' shouldn’t be concerned with extremely detailed matters of presentation. > From an anti-fingerprinting perspective you do much better to restrict what system fonts are available Agreed; I’m not saying there isn’t lower hanging fruit, I’m just commenting on the one that interested me.
- jefftk 7y ago
  The problem is, even if you restrict this to being specified in CSS it can still be used for fingerprinting