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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 13 Jul 2015 12:32:26 -0700
Message-ID: <CAAWBYDBrjjmucbTan3P_qu1qcpmasYYYq0snZL9EqDUpgoCMAw@mail.gmail.com>
To: www-style list <www-style@w3.org>
On Mon, Jul 13, 2015 at 12:06 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

#2 still exposes slightly more information than stylesheets did before
- it gives you the number of font faces declared by a tainted sheet,
and lets you observe their loading status.  (Previously, you could
only observe the loading status of fonts you knew the name of, via
layout/timing channels.)  Here's an option that's only slightly more
complicated, and eliminates the further information leak:

3. For each tainted sheet, expose a single OpaqueFontFaceList in the
document's FontFaceSet (with a private slot holding a list of the real
FontFace objects).  The query methods on FontFaceSet, when they would
return one or more faces from tainted sheets, instead return
OpaqueFontFaceLists as well, containing references only to the
appropriate FontFaces that would normally be returned (if the sheet
weren't tainted).  OpaqueFontFaceList only publicly exposes .load()
(which is distributed to all of the contained faces when called),
.loaded (promises resolves only when they all load), and .status
(refers to the aggregate status in some reasonable defined way).

Depending on how I define this, it *might* expose the presence/absence
of @font-face rules in a stylesheet, but (a) that's such a small leak
I'm sure it's okay, and (b) I might be able to define it in such a way
that it's not observable anyway.

I'm undecided as to whether #3 is worth the effort over #2, but I
provide it as a viable option if implementors want it.

Received on Monday, 13 July 2015 19:33:13 UTC

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