4 ms·

Updated, thanks for pointing that out. "The publisher of a web font can enable cross-origin use in all browsers by sending CORS headers." I agree they can, bu

Updated, thanks for pointing that out. "The publisher of a web font can enable cross-origin use in all browsers by sending CORS headers." I agree they can, but why do we need to add "Access-Control-Allow-Origin" header? What is the security risk? I am not being facetious, I really want to know.

mbrubeck 13y ago
So, you fixed the bug number, but what about my other points? Why single out Firefox when IE9+ has the same behavior and that behavior is required by the spec? Why don't you (or your CDN) use CORS? Why do you say this is "breaking the web" when thousands of sites are using cross-domain web fonts just fine in Firefox and IE (for example, any site that uses Google Web Fonts)? Edit: I see you added more to your comment now. There are a few reasons to require CORS for cross-domain font loads. One is so that you can use fonts that have single-site licenses in a way that satisfies the licensor, by not allowing other sites to use the font too without your authorization. Another is to prevent unintended data leaks where a malicious site can deduce things about a user based on whether that user can load a font from a different site, or based on the contents of that font. This isn't about a known attack, but a class of attack that we know from experience is likely to crop up in the future for any type of cross-origin resource load that we allow.
- jdorfman 13y ago
  "Why single out Firefox when IE9+ has the same behavior and that behavior is required by the spec?" I don't expect Microsoft to listen to their customers/users. I used to think Mozilla did but apparently not.
  - mbrubeck 13y ago
    Hey, I'm part of Mozilla and I spent a significant part of my day researching this spec, and asking questions and listening to try and find out why your use case wasn't being met. Usually we prefer well-reasoned bug reports or emails as apposed to "Fucking fix it" on the HN front page, but we'll take feedback where we find it. :) Also note that if you can't convince Microsoft to change this as well, then it doesn't matter too much what Mozilla does (at least for sites that need to support IE).
  - jdorfman 13y ago
    @mbrubeck I know you are part of Mozilla and I respect the work that you and Mozilla have done for the FOSS community, I just think Mozilla is off on this one issue. "Usually we prefer well-reasoned bug reports or emails as apposed to "Fucking fix it" on the HN front page, but we'll take feedback where we find it. :)" You know just as much as I know that email is dead ;)
  - mbrubeck 13y ago
    Your first comment on your own petition was "Because every other browser supports cross-domain fonts except you" which is false. It looks like you filed this based on the blog post you linked to, which is three years out of date. (For example, it said S3 does not support CORS, which is no longer true.)
- jdorfman 13y ago
  "One is so that you can use fonts that have single-site licenses in a way that satisfies the licensor, by not allowing other sites to use the font too without your authorization." Good point but I believe that the only way to combat that particular edge-case is to use something like the valid_referers directive: https://gist.github.com/jdorfman/6737413 https://gist.github.com/jdorfman/6737413 "This isn't about a known attack, but a class of attack that we know from experience is likely to crop up in the future for any type of cross-origin resource load that we allow." You bring up another good point, but I am not talking about every cross-origin resource here, I am talking about Content-Type: font/ttf, application/x-woff, application/vnd.ms-fontobject & image/svg+xml.
  - mbrubeck 13y ago
    Note: We can't actually restrict cross-origin requests based on Content-Type, since we don't know the Content-Type until we get a response. But, that quibble aside, I agree that allowing cross-origin requests just for @font-face does not open up any obvious holes. (If it did, Chrome and Safari users would be under attack already.) However, it is the sort of thing that creative hackers are good at combining with other capabilities or exploits in order to get at data or code they shouldn't. The trend in web API design is to keep things same-origin by default, and give control to authors over whether they want to give other origins access to their data, because this keeps things secure by default and limits the number of tools that those creative hackers have at their disposal. Not everyone at Mozilla agrees that this is the right solution. Anne van Kesteren (formerly of Opera, now a Mozilla employee), for example, favors adding a "From-Origin" request header that would remove the need for servers to add Access-Control-* headers in many cases (though it would not provide the same security properties by default): http://annevankesteren.nl/2011/02/from-origin http://annevankesteren.nl/2011/02/from-origin http://www.w3.org/TR/2011/WD-from-origin-20110721/ http://www.w3.org/TR/2011/WD-from-origin-20110721/ Meanwhile, some Google employees have been major proponents of making things same-origin by default; read the Tab Atkin post linked above for example. This isn't really about sides; it's about constantly trying to find better ways to improve the web without compromising security. I won't claim the current solution is perfect; it's a starting point, that's all.

mbrubeck 13y ago

So, you fixed the bug number, but what about my other points? Why single out Firefox when IE9+ has the same behavior and that behavior is required by the spec? Why don't you (or your CDN) use CORS? Why do you say this is "breaking the web" when thousands of sites are using cross-domain web fonts just fine in Firefox and IE (for example, any site that uses Google Web Fonts)? Edit: I see you added more to your comment now. There are a few reasons to require CORS for cross-domain font loads. One is so that you can use fonts that have single-site licenses in a way that satisfies the licensor, by not allowing other sites to use the font too without your authorization. Another is to prevent unintended data leaks where a malicious site can deduce things about a user based on whether that user can load a font from a different site, or based on the contents of that font. This isn't about a known attack, but a class of attack that we know from experience is likely to crop up in the future for any type of cross-origin resource load that we allow.

jdorfman 13y ago
"Why single out Firefox when IE9+ has the same behavior and that behavior is required by the spec?" I don't expect Microsoft to listen to their customers/users. I used to think Mozilla did but apparently not.
- mbrubeck 13y ago
  Hey, I'm part of Mozilla and I spent a significant part of my day researching this spec, and asking questions and listening to try and find out why your use case wasn't being met. Usually we prefer well-reasoned bug reports or emails as apposed to "Fucking fix it" on the HN front page, but we'll take feedback where we find it. :) Also note that if you can't convince Microsoft to change this as well, then it doesn't matter too much what Mozilla does (at least for sites that need to support IE).
- jdorfman 13y ago
  @mbrubeck I know you are part of Mozilla and I respect the work that you and Mozilla have done for the FOSS community, I just think Mozilla is off on this one issue. "Usually we prefer well-reasoned bug reports or emails as apposed to "Fucking fix it" on the HN front page, but we'll take feedback where we find it. :)" You know just as much as I know that email is dead ;)
- mbrubeck 13y ago
  Your first comment on your own petition was "Because every other browser supports cross-domain fonts except you" which is false. It looks like you filed this based on the blog post you linked to, which is three years out of date. (For example, it said S3 does not support CORS, which is no longer true.)
jdorfman 13y ago
"One is so that you can use fonts that have single-site licenses in a way that satisfies the licensor, by not allowing other sites to use the font too without your authorization." Good point but I believe that the only way to combat that particular edge-case is to use something like the valid_referers directive: https://gist.github.com/jdorfman/6737413 https://gist.github.com/jdorfman/6737413 "This isn't about a known attack, but a class of attack that we know from experience is likely to crop up in the future for any type of cross-origin resource load that we allow." You bring up another good point, but I am not talking about every cross-origin resource here, I am talking about Content-Type: font/ttf, application/x-woff, application/vnd.ms-fontobject & image/svg+xml.
- mbrubeck 13y ago
  Note: We can't actually restrict cross-origin requests based on Content-Type, since we don't know the Content-Type until we get a response. But, that quibble aside, I agree that allowing cross-origin requests just for @font-face does not open up any obvious holes. (If it did, Chrome and Safari users would be under attack already.) However, it is the sort of thing that creative hackers are good at combining with other capabilities or exploits in order to get at data or code they shouldn't. The trend in web API design is to keep things same-origin by default, and give control to authors over whether they want to give other origins access to their data, because this keeps things secure by default and limits the number of tools that those creative hackers have at their disposal. Not everyone at Mozilla agrees that this is the right solution. Anne van Kesteren (formerly of Opera, now a Mozilla employee), for example, favors adding a "From-Origin" request header that would remove the need for servers to add Access-Control-* headers in many cases (though it would not provide the same security properties by default): http://annevankesteren.nl/2011/02/from-origin http://annevankesteren.nl/2011/02/from-origin http://www.w3.org/TR/2011/WD-from-origin-20110721/ http://www.w3.org/TR/2011/WD-from-origin-20110721/ Meanwhile, some Google employees have been major proponents of making things same-origin by default; read the Tab Atkin post linked above for example. This isn't really about sides; it's about constantly trying to find better ways to improve the web without compromising security. I won't claim the current solution is perfect; it's a starting point, that's all.