[whatwg] New work on fonts at W3C

[Mikko Rantalainen]

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-0002.pgp>