WebFonts Working Group Teleconference -- 16 Feb 2011

<trackbot> Date: 16 February 2011

<jfkthame> mjs: did you get the dialing info you needed?

<mjs> yes

<behdad> good afternoon. /me is on the call, mostly to listen.

<scribe> ScribeNick: ChrisL

Introductions

Vlad: New member from Apple, Maciej

mjs: Work on WebKit team at apple

SOR and CORS and From-Origin

Vlad: Not a last call response, but important so this call is dedicated to that
... charter was approved with mention of SOR
... could be done in WOFF spec or elsewhere but it needs to be adressed somewhere

<TabAtkins> Argh, sorry for being late, guys. Had this on my calendar, but then got distracted.

Vlad: please introduce your email, Maciej

mjs: wrong to attach embedding restrictiosn to a format rather than a mechanism
... so should be in CSS3 Fonts not on WOFF

sylvaing: IE9 and FF do it that way today

mjs: so it should be in CSS3 Fonts
... Second one is more complex. Linking, embedding and reading
... linking like a element in HTML. No restrictions at all. Totally separate contexts
... important webarch property
... embedding uses a resource as part of a rendering, so like html img
... cross site embedding allowed traditionally
... iframe, script, stylesheet links all work that way
... has been criticised but is a done deal now
... reading is making available the ful text or binary data to programs. Cant let sites read each others data
... protocols restrict cross site reading
... XHR uses CORS to open this as needed
... to make consistent, needs to embed same as other resources
... hotlinking is not an issue specific to fonts

Vlad: to clarify, in the font world linking and embedding have quite different meanings
... embedding means physical incluson in the same resource
... licenses differentiate between embedding and linking in that sense

mjs: agree there is a terminology collision
... thanks for clarifying

Vlad: originally wa said SOR by default for fonts (WOFF in particular) for any resource linked by @font-face. Preferred way due to current licenses that explicitly allow font linking, but its not the only reason
... font vendors happy that this minimal level of protection exists. Not looking for cast iron guarantees

mjs: SOR is not a defence against malwhere. Malware is typically hosted all on pne place, or adds headers to allow widespread linking

sergeym: there was a perception that it helped with malware but now I agree with mjs

Vlad: jdaggett spoke on this

jdaggett: higher security concern than imabes but not that different

sylvaing: like chrome cleaning of fonts for example due to security issues

Vlad: ok so we can disregard security isues with SOR

<behdad> good point re security not being relevant to SOR discussion. was going to point that out on the mailing list.

john: SORis a benefot to commercial font vendors, want them used for the site they were licensed to
... published has invested money in the webfont license, value is relative to the percieved rarity of their use, for brand identity etc. so unlicensed resuse dilutes the value

mjs: agree there can be lots of reasons t prevent hotlinking of fonts
... easier than referrer header checking

John: preferential for the default behaviour that the content creator has to use as little as possible. reasonable steps to restrict hotlinking
... agree bar is somewhat low, but not zero

ChrisL: aggregated content sites and ISP hosting often disallows server config

sylvaing: that was my experience even between departments in corporations

mjs: sceptical that this is a common case
... downloading and rehosting is much more likely for piracy than hotlinking

sylvaing: goal is not to guard against piracy
... its not drm or encryption. that is not a goal

mjs: preventing only hotlinking is not a strong defence

sylvaing: its purely pragmatic. options should not be only free fonts or locked down font hosting
... font hosting with other content should be allowed
... simple solution that gives the value they like and that font vendors really like, is a benefit. its not a high protection at all
... benefits to users and font vendors is very high

jdaggett: not sure why hotlinking on everything is a great default
... its not consistent

mjs: don't weant fonts to be different from other resources

sylvaing: popular ones like video often sniffed for referer header, precisely because cross domain embedding is in practice restricted
... that people do this is relevant

mjs: advicate a way to block hotlinking for any resource

sylvaing: yes but the default for fonts should be different .

John: what counts as 'everything else'. images are content, fonts are tiny programs for typesetting

mjs: images, html in iframe, script from script element, stylesheets wit link or @import, pdf with build in viewing
... and XHR follows this three-way classification

sylvaing: if we make fonts inconsistent, you say its too costly. Who bears the cost

mjs: user confusion and security analysis

John: what is reading, here?

mjs; programatic access to the actual bytes

jdaggett: current rules already confusing
... distinction between read and embed is not common in peoples minds

mjs: but it is used in the platform

sylvaing: conent providers are always doing this for some images and for video etc
... license requires it for fonts but not for other content
... much more likely for fonts than for anything else

mjs: images are low grade amateur content and freely distributable

Vlad: fonts are tools, not content as such. they are tools to make content
... licensing high quality fonts at low cost ..... recent consensus was to make the default what is most neded, will let web typography flourish
... dont want to sacrifice that for an illusory consistency
... until recently web typography did not happen. dont want to stop it now

sylvaing: suppose CSS3 fonts stated an assumed default for from-origin?

mjs: sounds ok but only heard the proposal today

Vlad: (scribe recap) if default was from-origin: same was the default for fonts, seems to be better recieved

mjs: yes its better. not my preferred solution but better than what we have now

Vlad: so tab said he would implement this in Webkit. if we agree to this, would apple disable this ?

mjs: tab is getting ahead of himself

TabAtkins: its easy to do and have it on the table
... not asserting what Safari would do

sylvaing: is this what Chromium will do?

TabAtkins: expect it to go into Chrome

sylvaing: CSS3 fonts is edited by jdaggett - what is your opinion?

jdaggett: fine to go along with the consensus
... fro-origin is a good thing
... not convinced in hot-linkable by default being good.
... makes spec coordination a bit more tricky

John: so most people seem to think From-Origin is better?

jdaggett: SOR by defsault is better, but having from-Origin is a good thing. here is some crossover. and some benefits outside fonts

John: so a value of same is presumed for fonts

mjs: embedding rules in a central place is not controvertial
... using From-Origin is preferred to CORS
... first two are ok, third one not clear which is the assumed font default

jdaggett: agree with that assesment

Vlad: so we have a majority that SOR or From-Origin same default, is the prevalent opinion

cslye: we just want fonts to be restriced by default, as a mechanism we dont care what that is just the result as a foundry

Vlad: So FO is a bette rproposal overall

jdaggett: main point of controversy at the default

sylvaing: that is the issue yes

John: philosophical differnece between font creators and browser makers. New types can have different defaults. Consistency with something that was not a goodidea is not a benefit

Vlad: agree with what John said.
... consistency with wrong choices is a silly position

John: is there a higher authority to discuss the best default for new content types/
... fonts are unique

mjs: no venue could decide that with authority. in theory the tag can do that but they dont have expertise or recognition to make this stick or the authority
... unlikely to have new majort content types
... this could belong in WebApps but some charter issues

John: is Hakon on the call

(no)

John: would have liked his opinion on this

Vlad: so we seem to agree that FO is a better mechansm
... and that it belongs in @fontface for all font formats not just WOFF

sylvaing: FF and IE do this except not with that header
... and ther eis no FO spec today
... dependency is an issue

Vlad: from a pragmatic POV this is already the FF and IE behaviour and the success we have seen so far in the last year is remarkable so i dont want to make a decision that would reverse this progress. what e have today works well

John: woff is largely embraced, as a package,and SOR is part of that. Wary of doing anything to undermine that support

sylvaing: agree, but we still have that difference

Vlad: hard to change for existing formats but we can d the right thing for new content

John: lets have action items to move forward
... we need a draft spec for FO
... and who maintains it
... FO should apply to any resource referenced by @font-face, need sto be discussed by CSS WG

Vlad: FO applies to any type of resource

Vl: so this should go in CSS3 Fonts

sylvaing: mjs please float that to Webit

mjs: sure

adjourned

jdaggett: Will contact Hakon regarding FO

trackbot, status

<scribe> ACTION: jdaggett to contact Hakon regarding FO spec [recorded in http://www.w3.org/2011/02/16-webfonts-minutes.html#action01]

<trackbot> Created ACTION-75 - Contact Hakon regarding FO spec [on John Daggett - due 2011-02-23].

<scribe> ACTION: Maciej to ask apple about proposed FO solution [recorded in http://www.w3.org/2011/02/16-webfonts-minutes.html#action02]

<trackbot> Created ACTION-76 - Ask apple about proposed FO solution [on Maciej Stachowiak - due 2011-02-23].

- DRAFT -

WebFonts Working Group Teleconference

16 Feb 2011

Attendees

Contents

Introductions

SOR and CORS and From-Origin

Summary of Action Items

Scribe.perl diagnostic output