- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Tue, 23 Jun 2009 13:09:15 +0300
Aryeh Gregor wrote: > On Mon, Jun 22, 2009 at 10:43 AM, Brad Kemper<brad.kemper at gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090623/54e3f245/attachment.pgp>
Received on Tuesday, 23 June 2009 03:09:15 UTC