6 ms·

> browsers could standardize a list of system fonts available on each platform. It would probably make sense to completely disable support for local fonts unle

> browsers could standardize a list of system fonts available on each platform. It would probably make sense to completely disable support for local fonts unless permitted by the user (for legacy websites that depend on it). All modern browsers support @font-face, and without @font-face you can always depend on the special keywords serif, sans-serif, and monospace; these will load the system's default font for that category.

Klathmon 10y ago
I hope there is another way to solve it, as I have installed web-fonts to my PC to improve page loading speed for some common fonts I keep seeing (the most recent being the Roboto font stack from google). It would be a shame to have to keep re-downloading that every time.
- Freak_NL 10y ago
  You don't have to. Fonts should be (and usually are) offered to the web browser with the instruction to cache them indefinitely. You will only have to re-download them when your cache is cleaned up (due to its size, private browsing, or manually cleaning it). Upcoming technology WOFF2 helps further compress them by a significant margin as well (I've seen up to 50% improvement in size over plain WOFF). The problem is that the behaviour you are describing is also one of the ways a fingerprinter gets its data on your fonts; by specifying an @font-face declaration that first tries for a local font, and only loads a remote font if that is not found. Do this for a short-list of popular but distinct fonts (such as Roboto), and you have a nice amount of bits of identifying data to add to the stack. Also, tricks like these exist (using rendering metrics to detect fonts): http://www.lalit.org/lab/javascript-css-font-detect/ http://www.lalit.org/lab/javascript-css-font-detect/
  - Klathmon 10y ago
    Browser caches are extremely unreliable and pretty small in the grand scheme of things. On some mobile platforms the browser cache can be replaced entirely by some heavy pages! Plus, even if we assumed "cached forever" actually worked for a significant amount of time, it still doesn't solve the problem that I am hoping to solve. I know many websites use the Roboto font. By installing it I no longer need to ever download that font again. It doesn't matter if it's the first time i'm seeing the site, if they use a CDN, if they link to the bold/light/regular version or their own packed font, etc... I understand that it's a privacy issue, but I'm hoping there is a way to solve that privacy issue without removing that feature.
cm3 10y ago
I would go further and disable remote fonts as well since it's not crucial like images and is an attack vector that should have been avoided. The better solution would have been a shared set of web fonts distributed with browsers, just like certificates.
- WalterSear 10y ago
  I don't see why fonts are any different from images.
  - cm3 10y ago
    Fonts are different in that they're not as crucial to the content as images. You cannot replace an image with an alternative text form while retaining the content, but you can display the content completely with WOFF missing.
    - kbenson 10y ago
      I think the logical conclusion of that argument is to also disable all CSS. Fonts are styling for text, CSS is styling for markup. I think most the arguments against disabling CSS can be used against disabling fonts (barring that people do crazy shit with CSS most often now, so it complicates the issue). Really, in the end, all input accepted from the remote side (including text/html) needs to be vetted and processed by security conscious routines. I don't personally have a reason to assume a font library is more likely to be exploitable than an HTML+CSS parser and layout engine. Based on complexity, I would actually assume the opposite, which is probably right, except we've already found and fixed a lot of the exploits for the HTML parser and layout engine.
      - cm3 10y ago
        Of course you're right, and I didn't mention CSS but thought of it as another utilitarian piece. I agree that the most complex parts are HTML+CSS+JS+DOM+GFX, but some parts cannot be reasonably disabled without breaking it completely.
      - 10y ago

Klathmon 10y ago

I hope there is another way to solve it, as I have installed web-fonts to my PC to improve page loading speed for some common fonts I keep seeing (the most recent being the Roboto font stack from google). It would be a shame to have to keep re-downloading that every time.

Freak_NL 10y ago
You don't have to. Fonts should be (and usually are) offered to the web browser with the instruction to cache them indefinitely. You will only have to re-download them when your cache is cleaned up (due to its size, private browsing, or manually cleaning it). Upcoming technology WOFF2 helps further compress them by a significant margin as well (I've seen up to 50% improvement in size over plain WOFF). The problem is that the behaviour you are describing is also one of the ways a fingerprinter gets its data on your fonts; by specifying an @font-face declaration that first tries for a local font, and only loads a remote font if that is not found. Do this for a short-list of popular but distinct fonts (such as Roboto), and you have a nice amount of bits of identifying data to add to the stack. Also, tricks like these exist (using rendering metrics to detect fonts): http://www.lalit.org/lab/javascript-css-font-detect/ http://www.lalit.org/lab/javascript-css-font-detect/
- Klathmon 10y ago
  Browser caches are extremely unreliable and pretty small in the grand scheme of things. On some mobile platforms the browser cache can be replaced entirely by some heavy pages! Plus, even if we assumed "cached forever" actually worked for a significant amount of time, it still doesn't solve the problem that I am hoping to solve. I know many websites use the Roboto font. By installing it I no longer need to ever download that font again. It doesn't matter if it's the first time i'm seeing the site, if they use a CDN, if they link to the bold/light/regular version or their own packed font, etc... I understand that it's a privacy issue, but I'm hoping there is a way to solve that privacy issue without removing that feature.

cm3 10y ago

I would go further and disable remote fonts as well since it's not crucial like images and is an attack vector that should have been avoided. The better solution would have been a shared set of web fonts distributed with browsers, just like certificates.

WalterSear 10y ago
I don't see why fonts are any different from images.
- cm3 10y ago
  Fonts are different in that they're not as crucial to the content as images. You cannot replace an image with an alternative text form while retaining the content, but you can display the content completely with WOFF missing.
  - kbenson 10y ago
    I think the logical conclusion of that argument is to also disable all CSS. Fonts are styling for text, CSS is styling for markup. I think most the arguments against disabling CSS can be used against disabling fonts (barring that people do crazy shit with CSS most often now, so it complicates the issue). Really, in the end, all input accepted from the remote side (including text/html) needs to be vetted and processed by security conscious routines. I don't personally have a reason to assume a font library is more likely to be exploitable than an HTML+CSS parser and layout engine. Based on complexity, I would actually assume the opposite, which is probably right, except we've already found and fixed a lot of the exploits for the HTML parser and layout engine.
    - cm3 10y ago
      Of course you're right, and I didn't mention CSS but thought of it as another utilitarian piece. I agree that the most complex parts are HTML+CSS+JS+DOM+GFX, but some parts cannot be reasonably disabled without breaking it completely.
    - 10y ago