See also: IRC log
<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
Vlad: New member from Apple, Maciej
mjs: Work on WebKit team at apple
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].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wa/we/ Succeeded: s/XHR/XHR follows this three-way classification/ Succeeded: s/Jo;/John:/ Found ScribeNick: ChrisL Inferring Scribes: ChrisL Present: Erik Joanthan Christopher Vlad JDaggett Behdad Chris John Maciej Sergey Tal sylvaing Tab Found Date: 16 Feb 2011 Guessing minutes URL: http://www.w3.org/2011/02/16-webfonts-minutes.html People with action items: jdaggett maciej[End of scribe.perl diagnostic output]