2 ms·

font enumeration is done by basically trying to use a certain font and then measuring the div it's writing to. Also can be done a bit fancier drawing to a canva

by mpeg 9y ago

font enumeration is done by basically trying to use a certain font and then measuring the div it's writing to. Also can be done a bit fancier drawing to a canvas element and then taking a fingerprint of it (but presumably slower?). It can be spoofed from a browser extension by messing with the results from the measurement or hooking into core APIs. Plus you need a font list to begin with, you can't just look at the fonts the system has installed just from javascript.

gsnedders 9y ago
Yes, indeed. But you know what fonts each OS ships out of the box, so all you need is the set that's the union of those and then you have your fingerprinting. (Canvas will probably be slower, but I expect not by as much as you might suspect.) I don't see how you can mess with the results of measuring successfully, though, at least not without breaking things. You'd have to make CSSOM lie all over the place to avoid it.
- derefr 9y ago
  The simple thing would be for the browser to taint Javascript values derived (at whatever remove) from the CSSOM, and then block all network APIs from accepting such values.
  - pcwalton 9y ago
    I can think of fun ways around that. For example, using setTimeout() and then Date.now deltas to communicate numeric values. Or communicating data via UI events (you have to be able to send network requests in response to UI events, for obvious reasons). It wouldn't be possible to do that anyway without breaking important things like infinite scroll. Infinite scroll fundamentally requires network requests to be issued when an element is scrolled into view, but whether an element is in view depends on the results of layout, which depends on the user's installed fonts…
    - derefr 9y ago
      > but whether an element is in view depends on the results of layout, which depends on the user's installed fonts… It'd be kind of interesting if you could only ask about the CSSOM in terms of what the page would look like if rendered with a known set of {fonts, visited links, whatever else is a security leak} rather than asking what it does actually look like—with the browser keeping two render-trees in memory for metrics (the real one, and your hypothetical one) but only actually rendering the real one. Then, you could synchronize page-manipulation events between the two render-trees, by trying to re-synthesize things like viewport/scroll-offsets and mouse positions, such that everything "will have been" in the right position in one model to end up clicking on whatever element ended up being clicked on in the other model. Very inefficient, but kind of interesting.
      - gsnedders 9y ago
        If you have multiple columns of text, which column are you matching the scroll position up to? I'm pretty sure even something that inefficient isn't going to work. :)
    - dTal 9y ago
      >important things like infinite scroll No.

by mpeg 9y ago

gsnedders 9y ago

Yes, indeed. But you know what fonts each OS ships out of the box, so all you need is the set that's the union of those and then you have your fingerprinting. (Canvas will probably be slower, but I expect not by as much as you might suspect.) I don't see how you can mess with the results of measuring successfully, though, at least not without breaking things. You'd have to make CSSOM lie all over the place to avoid it.

derefr 9y ago
The simple thing would be for the browser to taint Javascript values derived (at whatever remove) from the CSSOM, and then block all network APIs from accepting such values.
- pcwalton 9y ago
  I can think of fun ways around that. For example, using setTimeout() and then Date.now deltas to communicate numeric values. Or communicating data via UI events (you have to be able to send network requests in response to UI events, for obvious reasons). It wouldn't be possible to do that anyway without breaking important things like infinite scroll. Infinite scroll fundamentally requires network requests to be issued when an element is scrolled into view, but whether an element is in view depends on the results of layout, which depends on the user's installed fonts…
  - derefr 9y ago
    > but whether an element is in view depends on the results of layout, which depends on the user's installed fonts… It'd be kind of interesting if you could only ask about the CSSOM in terms of what the page would look like if rendered with a known set of {fonts, visited links, whatever else is a security leak} rather than asking what it does actually look like—with the browser keeping two render-trees in memory for metrics (the real one, and your hypothetical one) but only actually rendering the real one. Then, you could synchronize page-manipulation events between the two render-trees, by trying to re-synthesize things like viewport/scroll-offsets and mouse positions, such that everything "will have been" in the right position in one model to end up clicking on whatever element ended up being clicked on in the other model. Very inefficient, but kind of interesting.
    - gsnedders 9y ago
      If you have multiple columns of text, which column are you matching the scroll position up to? I'm pretty sure even something that inefficient isn't going to work. :)
  - dTal 9y ago
    >important things like infinite scroll No.