Re: [whatwg] New work on fonts at W3C
If browsers all send the referrer HTTP header, Webmaster might always put a filter on incoming requests, But it won't prevent other webmaster to get these resources tunneling it from their own server sending a fake referrer header If you want to strictly restrict cross-domain resources, the only way would be the use of certificates, which would at least tell the visitor that some resources is going to see comes from another domain, and at most could be forbidden by the browser (Sorry, it requires SSL for now) Restricting access to resources from cross domain access also level up then the question of access it from out of any website With URL sent by mail, twitter, or anything else... -Message d'origine- De : whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] De la part de Aryeh Gregor Envoyé : lundi 22 juin 2009 22:50 À : Brad Kemper Cc : wha...@whatwg.org; Mikko Rantalainen; www-st...@w3.org Objet : Re: [whatwg] New work on fonts at W3C On Mon, Jun 22, 2009 at 4:23 PM, Brad Kemper wrote: > So your argument, in effect, is that site owners should not be allowed to > restrict their content, because it might actually work? Or because older > browsers and browsers that have yet to implement the standard could be used > for the same sort of IP pirating as today? No, I'm saying that browser vendors will refuse to implement it because it will break existing sites en masse and thereby anger their users. Ideally I think it should have been possible to restrict cross-domain image loads from the start, but I don't see any way to do that *now* without breaking too many existing sites for browsers to be willing to go along with it.
Re: [whatwg] New work on fonts at W3C
A server serving documents containing references to content from other sites, embedded or not, does not distribute that content. It would only redistribute in case of hot piping. Some sites have a policy disallowing publishing backdoor hyperlinks; the legal implications of such a policy are questionable (it is a collision with the free speech principle), but it can be applied if considered valid and enforceable. Limiting browser access to cross-site resources does not prevent copyright violation, at least not for images, because the publisher can use a (possibly illegal) mirror; a Flash applet can figure out it is being served from somewhere else and refuse to run but static content will display all right. The right answer to this problem, if it is really a problem, is to embed licensing information into the resources themselves, as in EOT fonts. IMHO, Chris
Re: [whatwg] New work on fonts at W3C
Aryeh Gregor wrote: > On Mon, Jun 22, 2009 at 10:43 AM, Brad Kemper wrote: >> This makes sense to me. I was surprised and found it counter-intuitive to >> learn that CORS could be used to list the servers that are allowed access, >> but could not and would not restrict access to servers not on that list. Why >> not? If the header was added to an image file, it would seem to be a clear >> indication of what servers were allowed access or not. > > Consider the following scenario: > > 1) Site A hotlinks images from site B > > 2) Firefox 3.5 implements CORS in a way that allows sites to deny > cross-origin requests of images > > 3) Site B's webmaster hears about this and says "Great, I can stop > hotlinking!" and uses it > > 4) User of site A upgrades to Firefox 3.5, images suddenly break. > User gets annoyed and concludes Firefox 3.5 is broken, and switches > back to Firefox 3.0 or to a competing browser. > > I believe that's the major rationale for not permitting cross-origin > restrictions on existing media types. The only way this could work is > if *all* browsers agreed to implement it all at once, and it would > still seriously annoy a lot of users/cause them to delay > upgrading/etc., which none of the browser vendors want to do. I understand this argument. I'll rephrase the issue: If a new version of user agent would honor the licensing of content (and refuse to embed some content), a site which is distributing content without a proper license would look broken to a casual user. I'd consider this an improvement. If I'm not totally incorrect, this is what font foundries are asking for - a piece of content (font) used without a proper license should not work (easily). If you believe that this cannot be ever implemented because of poor user experience, then this whole discussion seems pointless. However, I think that this is only a user interface issue. For example, Firefox already blocks pop up windows and is "broken" in a sense that it doesn't display the content that the author is trying to display (ads). In such case, Firefox will display a yellow bar on the top of the page telling the user what has happened and allows the user to override the action (display the pop up). How about an implementation where a new version of user agent (say, Firefox 3.5) would honor the CORS header but allow the user to override the protection? (Possibly because the cause for the problem is incorrect server configuration instead of copyright infringement. The user agent cannot know.) Consider the following scenario (pretty similar to above): 1) Site A hotlinks to fonts from site B 2) Firefox implements CORS in a way that allows sites to deny cross-origin request of fonts 3) Site B's webmaster hears about this and says "Great, I can stop hotlinking to my fonts!" and uses it 4) User of site A upgrades to Firefox 3.5, fonts suddenly do not show. However, while entering the site A, Firefox 3.5 displays a yellow bar at the top of the page with a message "This site is trying to use restricted content from external sources without a proper permission" with a button "Show all content". In addition, there could be a link or button with label "Show details" which could open a dialog with a message "This site is trying to use resource http://siteB.tld/font.ttf which is allowed only by siteB.tld and siteC.tld." (repeated for all the content blocked by CORS). Would that be an acceptable UI? Obviously, the actual labels could be improved. This way font vendors or anybody else would not get any silly ideas that the use of the fonts could be prevented altogether. Just that there can be some hints to user agents about what should be allowed and what should not. But those are only hints. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] New work on fonts at W3C
On Tue, Jun 23, 2009 at 8:15 AM, Aryeh Gregor > wrote: > I believe that's the major rationale for not permitting cross-origin > restrictions on existing media types. The only way this could work is > if *all* browsers agreed to implement it all at once, and it would > still seriously annoy a lot of users/cause them to delay > upgrading/etc., which none of the browser vendors want to do. > It's very simple. Billions of Web pages depend on cross-site loads of images, scripts and stylesheets. Many of those Web pages aren't even maintained anymore. No browser that broke all those pages would be viable. Even if the Illuminati made every future browser version impose cross-site restrictions on those resources, users would probably just stop upgrading. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] New work on fonts at W3C
On Mon, Jun 22, 2009 at 4:23 PM, Brad Kemper wrote: > So your argument, in effect, is that site owners should not be allowed to > restrict their content, because it might actually work? Or because older > browsers and browsers that have yet to implement the standard could be used > for the same sort of IP pirating as today? No, I'm saying that browser vendors will refuse to implement it because it will break existing sites en masse and thereby anger their users. Ideally I think it should have been possible to restrict cross-domain image loads from the start, but I don't see any way to do that *now* without breaking too many existing sites for browsers to be willing to go along with it.
Re: [whatwg] New work on fonts at W3C
If browsers start refusing cross-domain image requests, some servers will work around this problem using hot piping. I am not sure this would be good-but I cannot say it would be bad either. IMHO, Chris
Re: [whatwg] New work on fonts at W3C
On Mon, Jun 22, 2009 at 10:43 AM, Brad Kemper wrote: > This makes sense to me. I was surprised and found it counter-intuitive to > learn that CORS could be used to list the servers that are allowed access, > but could not and would not restrict access to servers not on that list. Why > not? If the header was added to an image file, it would seem to be a clear > indication of what servers were allowed access or not. Consider the following scenario: 1) Site A hotlinks images from site B 2) Firefox 3.5 implements CORS in a way that allows sites to deny cross-origin requests of images 3) Site B's webmaster hears about this and says "Great, I can stop hotlinking!" and uses it 4) User of site A upgrades to Firefox 3.5, images suddenly break. User gets annoyed and concludes Firefox 3.5 is broken, and switches back to Firefox 3.0 or to a competing browser. I believe that's the major rationale for not permitting cross-origin restrictions on existing media types. The only way this could work is if *all* browsers agreed to implement it all at once, and it would still seriously annoy a lot of users/cause them to delay upgrading/etc., which none of the browser vendors want to do.
Re: [whatwg] New work on fonts at W3C
Anne van Kesteren wrote: > On Sat, 20 Jun 2009 17:07:06 +0200, Brad Kemper > wrote: >> I didn't mean it should be restricted by default. Just that CORS could >> restrict it like anything else if you told it to. And that the font >> could instruct the CORS mechanism. > > That's not how CORS works. CORS is not about restricting at all. It is > about lifting cross-origin restrictions if any are present. If there are > no restrictions to start with (which I think makes sense for consistency > as I pointed out though it seems not everyone agrees) CORS cannot impose > any. Perhaps CORS could further defined to use following rules: 1) without CORS same-origin restrictions may or may not apply depending on the resource type or user agent (with XHR it does apply, with IMG SRC attribute it does not apply) 2) with CORS, the same-origin restrictions always apply and in addition to same-origin, any entity listed in CORS may use the resource This way CORS could be expanded to apply to XML, CSS, images, videos and font files. This would change to status of CORS somewhat - it would still only allow lifting cross-origin restrictions but a mere presence of it would suggest to user agent that same-origin checks should be done. If enough user agents started following the hints given with CORS it could be used as a pseudo-restriction (I would consider this a label and fence as used in this font discussion.) -- Mikko signature.asc Description: OpenPGP digital signature
