W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] font security on measureText

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 7 Jun 2013 18:33:30 -0700
Message-ID: <CAGN7qDBJPBdjB0N3uG1rTtQKw2t019+7FTH7p1daFhtt_9j7nQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHATWG <whatwg@whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Fri, Jun 7, 2013 at 4:08 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 2 May 2013, Rik Cabanier wrote:
> >
> > The canvas 2d spec currently states that a font has to be local in order
> > for measureText to work: [1][2]
> >
> > If doing these measurements requires using a font that has an origin
> > that is not the same as that of the Document object that owns the canvas
> > element (even if "using a font" means just checking if that font has a
> > particular glyph in it before falling back to another font), then the
> > method must throw a SecurityError exception.
> >
> > Does anyone know what this is?
>
> If you import a font from another origin (without CORS), then this
> prevents you from reading its metrics.
>
>
> > It seems to us, that if the font is available to CSS (depending on if
> > the browser supports CORS for fonts), it should be fine to call
> > measureText.
>
> Only if CSS prevents cross-origin font loads.
>

Sure.
My point was, why is canvas defining it here?
It seems that it should rely on whatever CSS does. Defining it in Canvas
might make things go out of sync since someone will have to remember to
update both specs.



>
>
> On Thu, 2 May 2013, Rik Cabanier wrote:
> >
> > So, if my css specifies a font:
> >
> > @font-face {
> > font-family: "Bitstream Vera Serif Bold";
> > src: url("
> http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf");
> >
> > }
> >
> > it seems that the origin of the font is not the same as the document so
> > measureText won't work. (I'm not that familiar with the verbiage so I
> > might be mistaken)
>
> Right, that's the idea.
>
>
> On Fri, 3 May 2013, Boris Zbarsky wrote:
> >
> > The text at
> > http://dev.w3.org/csswg/css-fonts/#default-same-origin-restriction and
> > http://dev.w3.org/csswg/css-fonts/#allowing-cross-origin-font-loading
> > predates your introduction of the mode values, but clearly corresponds
> > to the "CORS" mode, no?
> >
> > And while browsers are not aligned yet, they did plan to align last I
> > heard, in that their representatives in the WG had agreed to the above
> > text.
> >
> > Of course it's possible some of the browsers involved are just planning
> > to ignore the spec altogether without bothering to argue to get it
> > changed to what they think is the right thing.
>
> If browsers align on the above text the HTML spec indeed would no longer
> need to worry about this, since there'd no longer be any cross-origin
> fonts. Has this occurred?
>
> (Personally I don't really see why we'd limit this to same-origin and
> CORS-cross-origin only. It makes loading fonts from other origins a pain.)
>
>
> On Mon, 6 May 2013, Rik Cabanier wrote:
> >
> > I logged https://www.w3.org/Bugs/Public/show_bug.cgi?id=21943
>
> In the future, please note that there's no need to file a bug for topics
> raised on the WHATWG list -- just one or the other is fine.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Saturday, 8 June 2013 01:33:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC