W3C home > Mailing lists > Public > www-style@w3.org > July 2015

[css-font-loading] Handling cross-origin CORS-tainted font faces

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 13 Jul 2015 12:06:38 -0700
Message-ID: <CAAWBYDBjdhJtmuXMr=YcEgmJzFSaLzfc-GVou0AZ-bzJxySYgw@mail.gmail.com>
To: www-style list <www-style@w3.org>
When a stylesheet is cross-origin and not CORS-blessed (via the
crossorigin attribute on the <link>, and appropriate CORS headers on
the response), we apply the sheet but don't offer any access to it.

However, it was pointed out in
that the Font Loading API *does* expose some aspects of the
stylesheet; specifically, the existence of @font-face rules and the
contents of their descriptors (other than 'src').

I need to address this, but I've got a few options for doing so, and
I'm not sure which is best:

1. Put a "CORS-tainted" flag on FontFaces, set appropriately, and
rewrite several of the search/iteration algorithms in the spec to skip
tainted FontFaces unless you're a blessed caller.

2. Add a "OpaqueFontFace" interface which lacks most of the
attributes, but has a private slot pointing to the real FontFace it
represents (as usual, private slots are only visible/accessible to the
implementation), and then just treat it as normal.

I think I prefer 2.  It's a smaller diff to the spec, for one, and
doesn't require me to have to remember to exclude anything when I add
new algorithms in the future.  It also seems like it plays better with
some of the algorithms: if I call .load() and it targets a font from a
cross-origin stylesheet, I can still get back a promise that'll
resolve to an OpaqueFontFace, rather than, I dunno, get back an empty
list?  Or a promise that resolves to undefined?


Received on Monday, 13 July 2015 19:07:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC