- From: Chris Lilley <chris@w3.org>
- Date: Wed, 16 Feb 2011 23:05:29 +0100
- 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 UTC