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

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
<https://github.com/slightlyoff/ServiceWorker/issues/719#issuecomment-121017590>
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?

Thoughts?

~TJ

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