W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > February 2011

Minutes, 16 February 2011 WebFonts WG telcon

From: Chris Lilley <chris@w3.org>
Date: Wed, 16 Feb 2011 23:05:29 +0100
Message-ID: <3810247013.20110216230529@w3.org>
To: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
Hello,

 Minutes in html at
http://www.w3.org/2011/02/16-webfonts-minutes.html

and below as text for trackbot

                 WebFonts Working Group Teleconference

16 Feb 2011

   See also: [2]IRC log

      [2] http://www.w3.org/2011/02/16-webfonts-irc

Attendees

   Present
          Erik, Joanthan, Christopher, Vlad, JDaggett, Behdad, Chris,
          John, Maciej, Sergey, Tal, sylvaing, Tab

   Regrets
   Chair
          Vlad

   Scribe
          ChrisL

Contents

     * [3]Topics
         1. [4]Introductions
         2. [5]SOR and CORS and From-Origin
     * [6]Summary of Action Items
     _________________________________________________________

   <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
   [7]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
   [8]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].

Summary of Action Items

   [NEW] ACTION: jdaggett to contact Hakon regarding FO spec [recorded
   in [9]http://www.w3.org/2011/02/16-webfonts-minutes.html#action01]
   [NEW] ACTION: Maciej to ask apple about proposed FO solution
   [recorded in
   [10]http://www.w3.org/2011/02/16-webfonts-minutes.html#action02]

   [End of minutes]

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 16 February 2011 22:12:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 February 2011 22:12:11 GMT