Sylvain Galineau | 1 Jul 01:01 2011
Picon

RE: css3-fonts: should not dictate usage policy with respect to origin

“the scenario you offer only prevents access if *every* HTTP client, whether UA or not, respects SOR;”

 

Well, gee, doesn’t that sound like something worth standardizing on then ?

 

 

From: Glenn Adams [mailto:glenn <at> skynav.com]
Sent: Thursday, June 30, 2011 3:56 PM
To: John Daggett
Cc: John Hudson; liam <at> w3.org; StyleBeyondthePunchedCard; public-webfonts-wg <at> w3.org; www-font <at> w3.org; Martin J.; Sylvain Galineau; Vladimir Levantovsky
Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

 

if EvilCompany does not include an Origin header in its request, then BigCompany could not distinguish that request as coming from  a pre-HTML5 UA (i.e., current conditions), in which this case devolves to the current read scenario;

 

if BigCompany does not respond to fetches not containing an Origin, then again EvilCompany can guess an origin that permits access, resulting in a fetch;

 

EvilCompany does not need to use a UA, but can construct their own HTTP client to accomplish this;

 

the scenario you offer only prevents access if *every* HTTP client, whether UA or not, respects SOR;

 

On Thu, Jun 30, 2011 at 3:59 PM, John Daggett <jdaggett <at> mozilla.com> wrote:


Glenn Adams wrote:

> Regarding the last, please show me an attack based on font access that
> SOR prevents.

One possible attack scenario:

BigCompany decides to design a new logo.  They commission a font
containing a special glyph with that logo in it.  An access-restricted
site is created using that custom font.  EvilCompany, a competitor,
would like to know about that logo before it is released publicly.  They
insert script in web ads on popular sites that systematically attempt
to guess possible access-restricted URLs for the custom font.  An
employee of BigCompany hits one of the pages on an external site
containing one of EvilCompany's webads.

If no origin restriction exists, the web ad code can access the font as
long as they guess the right access-restricted URL and an
employee of BigCompany happens to have access.  The script inserted in a
webad by EvilCompany accesses the custom logo glyph and sends it back to
an EvilCompany-controlled site.

If font loads are restricted to same origin and the BigCompany hasn't
explicitly enabled cross-origin loading via CORS, the web ad code will
*never* be able to load the font even if their code guesses the right
access-restricted URL, since it's origin is different.

The scenario is the same one as in the WebGL example I noted earlier,
without same origin restrictions content can be accessed via means
that are not immediately obvious to the naive author.

Regards,

John Daggett

 

Cameron McCormack | 1 Jul 01:00 2011
Picon

Re: SVG Fonts inside of OpenType fonts? [Cross-post from www-font <at> w3.org]

Alex Danilo:
> > This is incorrect. If an implementation does SVG Full fonts, then the
> > content can contain <use> elements.

Levantovsky, Vladimir:
> I am not sure what you mean by content. Would plain sequence of
> Unicode codepoints be considered a content?

I think Alex means the content of the <glyph>, i.e. you can have

  <svg …>
    <defs>
      <path id="a" d="M …"/>
    </defs>
    <font>
      <glyph>
        <use xlink:href="#a"/>
        …
      </glyph>
    </font>
  </svg>

> > So, the glyph geometries themselves can just sit in a <defs> or
> > wherever, and you could even use their 'id' as your glyph index.
> > Then the <glyph> elements in the SVG font can reference an arbitrary
> > number of them. i.e. one-to-m, n-to-m and n-to- one mappings are all
> > possible with the SVG font spec. as is, no changes required.
> > 
> > It is a fact that an authoring tool is capable of outputting SVG
> > font outlines for glyphs etc. as a single self contained file with
> > no rendering ambiguity. Furthermore, language dependent rendering
> > can be achieved with <switch> if you wish.
> 
> I am sorry, I don't understand half of the above (I'm sure due to my
> limited knowledge of SVG Full fonts). Maybe a simple use case could
> help illustrate this workflow better:
>
> I have an SVG Full font and a string of Unicode characters that belong
> to a complex script where each character may be represented by one
> of many glyphs available in SVG font, and where a number of various
> character combinations may need to be replaced by a single glyph
> (ligature). I expect to get a readable text displayed as the result.
> What would have to happen for a text to be rendered correctly?

In cases where you have a complex script that isn’t supported directly
by SVG Font’s ligature and Arabic form features, then you can use
<altGlyph> to select an explicit glyph to use for a run of Unicode
characters.  For example:

  <font>
    <glyph id="complex">
      …
    </glyph>
  </font>
  <text>The <altGlyph xlink:href="#complex">xyzzy</altGlyph>
    glyph.</text>

--

-- 
Cameron McCormack ≝ http://mcc.id.au/

Glenn Adams | 1 Jul 01:01 2011

Re: css3-fonts: should not dictate usage policy with respect to origin

if this argument applies, then the same logic driving SOR on font fetches should be used on every type of fetch, including images; if the W3C came out and said "we are going to systematically transition our specs so that all fetches require SOR" as a preventative measure against possible attacks, then we probably wouldn't be having this conversation;


however, I have asked what is special about fonts that requires SOR that does not apply to text/plain, image/png, application/xml, etc., and I have not received an answer other than "we need a mechanism to enforce EULAs";

On Thu, Jun 30, 2011 at 4:38 PM, Tab Atkins <tabatkins <at> google.com> wrote:
On Thu, Jun 30, 2011 at 3:35 PM, Brad Kemper <brad.kemper <at> gmail.com> wrote:
> If there is a corporate font or specialized dingbat font that is only loaded
> and used when a person has signed into a secure site (for online banking,
> let's say), then an attacker whose site is open in another window or tab can
> find out about it using the method Tab described earlier. That is
> information leakage that would allow the attacker to know when to attack. He
> could, for instance, pop open a small window that says, "you are about to be
> automatically signed out. Click OK to stay signed in." And then the OK
> button would lead to a phishing site that looked just like the online
> banking site, and a lot of users wouldn't realize it. That is a security
> risk that has nothing to do with EULAs.

In other words, betting that a particular filetype will never be used
in malicious attacks is a good way to lose money.  ^_^

~TJ

Glenn Adams | 1 Jul 01:06 2011

Re: css3-fonts: should not dictate usage policy with respect to origin

sure, let's go ITU (or the U.N.) and get a universal mandate, then you may get what you want... in the mean time... business (access) as usual...


apparently we allow idealism to influence our thinking in different degrees; at 60+, i've moved on from the idealism of my 20s

On Thu, Jun 30, 2011 at 5:01 PM, Sylvain Galineau <sylvaing <at> microsoft.com> wrote:

“the scenario you offer only prevents access if *every* HTTP client, whether UA or not, respects SOR;”

 

Well, gee, doesn’t that sound like something worth standardizing on then ?

 

 

From: Glenn Adams [mailto:glenn <at> skynav.com]
Sent: Thursday, June 30, 2011 3:56 PM
To: John Daggett
Cc: John Hudson; liam <at> w3.org; StyleBeyondthePunchedCard; public-webfonts-wg <at> w3.org; www-font <at> w3.org; Martin J.; Sylvain Galineau; Vladimir Levantovsky


Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

 

if EvilCompany does not include an Origin header in its request, then BigCompany could not distinguish that request as coming from  a pre-HTML5 UA (i.e., current conditions), in which this case devolves to the current read scenario;

 

if BigCompany does not respond to fetches not containing an Origin, then again EvilCompany can guess an origin that permits access, resulting in a fetch;

 

EvilCompany does not need to use a UA, but can construct their own HTTP client to accomplish this;

 

the scenario you offer only prevents access if *every* HTTP client, whether UA or not, respects SOR;

 

On Thu, Jun 30, 2011 at 3:59 PM, John Daggett <jdaggett <at> mozilla.com> wrote:


Glenn Adams wrote:

> Regarding the last, please show me an attack based on font access that
> SOR prevents.

One possible attack scenario:

BigCompany decides to design a new logo.  They commission a font
containing a special glyph with that logo in it.  An access-restricted
site is created using that custom font.  EvilCompany, a competitor,
would like to know about that logo before it is released publicly.  They
insert script in web ads on popular sites that systematically attempt
to guess possible access-restricted URLs for the custom font.  An
employee of BigCompany hits one of the pages on an external site
containing one of EvilCompany's webads.

If no origin restriction exists, the web ad code can access the font as
long as they guess the right access-restricted URL and an
employee of BigCompany happens to have access.  The script inserted in a
webad by EvilCompany accesses the custom logo glyph and sends it back to
an EvilCompany-controlled site.

If font loads are restricted to same origin and the BigCompany hasn't
explicitly enabled cross-origin loading via CORS, the web ad code will
*never* be able to load the font even if their code guesses the right
access-restricted URL, since it's origin is different.

The scenario is the same one as in the WebGL example I noted earlier,
without same origin restrictions content can be accessed via means
that are not immediately obvious to the naive author.

Regards,

John Daggett

 


Brad Kemper | 1 Jul 01:06 2011
Picon

Re: [css3-speech] voice-family

On Jun 30, 2011, at 1:48 PM, Andrew Thompson <lordpixel <at> mac.com> wrote:

> Sorry but what's a generic voice family in this context? Do you mean something like 'robotic' as opposed to
c3p0 or Robbie?

Marvin, from Hitchhiker's Guide to the Galaxy.  

Sylvain Galineau | 1 Jul 01:07 2011
Picon

RE: css3-fonts: should not dictate usage policy with respect to origin

Unlike image resources which are everywhere and can’t really be moved to an SOR without breaking content all over, web font usage remain very new (as compared to the spec’s history) and we have the opportunity to get it ‘right’ before the mass of available content is too large.

 

As one major browser that is particularly popular with web authors has always applied SOR on font requests and another major browser supports the same behavior, we are able to address this issue without ‘breaking the web’ as it is colloquially known. We unfortunately don’t have the option of doing so with other resource types. That should not, however, be a reason to keep extending the overall attack surface. But it certainly seems the right policy for new features. (Again, yes, <at> font-face is not new but active *usage* is relatively new).

 

From: Glenn Adams [mailto:glenn <at> skynav.com]
Sent: Thursday, June 30, 2011 4:01 PM
To: Tab Atkins
Cc: Brad Kemper; John Daggett; John Hudson; Vladimir Levantovsky; liam <at> w3.org; StyleBeyondthePunchedCard; public-webfonts-wg <at> w3.org; www-font <at> w3.org; Martin J.; Sylvain Galineau
Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

 

if this argument applies, then the same logic driving SOR on font fetches should be used on every type of fetch, including images; if the W3C came out and said "we are going to systematically transition our specs so that all fetches require SOR" as a preventative measure against possible attacks, then we probably wouldn't be having this conversation;

 

however, I have asked what is special about fonts that requires SOR that does not apply to text/plain, image/png, application/xml, etc., and I have not received an answer other than "we need a mechanism to enforce EULAs";

On Thu, Jun 30, 2011 at 4:38 PM, Tab Atkins <tabatkins <at> google.com> wrote:

On Thu, Jun 30, 2011 at 3:35 PM, Brad Kemper <brad.kemper <at> gmail.com> wrote:
> If there is a corporate font or specialized dingbat font that is only loaded
> and used when a person has signed into a secure site (for online banking,
> let's say), then an attacker whose site is open in another window or tab can
> find out about it using the method Tab described earlier. That is
> information leakage that would allow the attacker to know when to attack. He
> could, for instance, pop open a small window that says, "you are about to be
> automatically signed out. Click OK to stay signed in." And then the OK
> button would lead to a phishing site that looked just like the online
> banking site, and a lot of users wouldn't realize it. That is a security
> risk that has nothing to do with EULAs.

In other words, betting that a particular filetype will never be used
in malicious attacks is a good way to lose money.  ^_^

~TJ

 

Sylvain Galineau | 1 Jul 01:14 2011
Picon

RE: css3-fonts: should not dictate usage policy with respect to origin

Not being a dumb idealist is exactly what this is about. We can’t go back and do this for image resources and other features as it would break too much existing content. But we can and should be smart with new features; it would be silly to keep expanding the menu of attack vectors because we can’t fix them all.  The perfect should not be the enemy of the good, learning from the past etc.

 

As <at> font-face use was very limited on the internet and intranet, we can in fact treat it as a new feature in practice. SOR was a breaking change for us in IE9 and the impact of the change has been extremely limited.

 

From: Glenn Adams [mailto:glenn <at> skynav.com]
Sent: Thursday, June 30, 2011 4:06 PM
To: Sylvain Galineau
Cc: John Daggett; John Hudson; liam <at> w3.org; StyleBeyondthePunchedCard; public-webfonts-wg <at> w3.org; www-font <at> w3.org; Martin J.; Vladimir Levantovsky
Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

 

sure, let's go ITU (or the U.N.) and get a universal mandate, then you may get what you want... in the mean time... business (access) as usual...

 

apparently we allow idealism to influence our thinking in different degrees; at 60+, i've moved on from the idealism of my 20s

On Thu, Jun 30, 2011 at 5:01 PM, Sylvain Galineau <sylvaing <at> microsoft.com> wrote:

“the scenario you offer only prevents access if *every* HTTP client, whether UA or not, respects SOR;”

 

Well, gee, doesn’t that sound like something worth standardizing on then ?

 

 

From: Glenn Adams [mailto:glenn <at> skynav.com]
Sent: Thursday, June 30, 2011 3:56 PM
To: John Daggett
Cc: John Hudson; liam <at> w3.org; StyleBeyondthePunchedCard; public-webfonts-wg <at> w3.org; www-font <at> w3.org; Martin J.; Sylvain Galineau; Vladimir Levantovsky


Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

 

if EvilCompany does not include an Origin header in its request, then BigCompany could not distinguish that request as coming from  a pre-HTML5 UA (i.e., current conditions), in which this case devolves to the current read scenario;

 

if BigCompany does not respond to fetches not containing an Origin, then again EvilCompany can guess an origin that permits access, resulting in a fetch;

 

EvilCompany does not need to use a UA, but can construct their own HTTP client to accomplish this;

 

the scenario you offer only prevents access if *every* HTTP client, whether UA or not, respects SOR;

 

On Thu, Jun 30, 2011 at 3:59 PM, John Daggett <jdaggett <at> mozilla.com> wrote:


Glenn Adams wrote:

> Regarding the last, please show me an attack based on font access that
> SOR prevents.

One possible attack scenario:

BigCompany decides to design a new logo.  They commission a font
containing a special glyph with that logo in it.  An access-restricted
site is created using that custom font.  EvilCompany, a competitor,
would like to know about that logo before it is released publicly.  They
insert script in web ads on popular sites that systematically attempt
to guess possible access-restricted URLs for the custom font.  An
employee of BigCompany hits one of the pages on an external site
containing one of EvilCompany's webads.

If no origin restriction exists, the web ad code can access the font as
long as they guess the right access-restricted URL and an
employee of BigCompany happens to have access.  The script inserted in a
webad by EvilCompany accesses the custom logo glyph and sends it back to
an EvilCompany-controlled site.

If font loads are restricted to same origin and the BigCompany hasn't
explicitly enabled cross-origin loading via CORS, the web ad code will
*never* be able to load the font even if their code guesses the right
access-restricted URL, since it's origin is different.

The scenario is the same one as in the WebGL example I noted earlier,
without same origin restrictions content can be accessed via means
that are not immediately obvious to the naive author.

Regards,

John Daggett

 

 

John Daggett | 1 Jul 01:15 2011

Re: css3-fonts: should not dictate usage policy with respect to origin


Glenn Adams wrote:

> if EvilCompany does not include an Origin header in its request, then
> BigCompany could not distinguish that request as coming from  a
> pre-HTML5 UA (i.e., current conditions), in which this case devolves
> to the current read scenario;
> 
> if BigCompany does not respond to fetches not containing an Origin,
> then again EvilCompany can guess an origin that permits access,
> resulting in a fetch;

There's no "origin header" here, the origin is the site where a given
piece of content originated.  In the example below, BigCompany content
originates from a BigCompany origin, EvilCompany from a popular site
origin (or some ad network origin).  The origin is the same in either an
older UA or a "HTML5 UA" (not sure how you're drawing this distinction).

> EvilCompany does not need to use a UA, but can construct their own
> HTTP client to accomplish this;

Sure, but getting an employee of BigCompany to use a UA constructed by
EvilCompany is an entirely different attack vector, one that would be a
*much* more difficult task compared to getting that employee to navigate
to a popular site.

> the scenario you offer only prevents access if *every* HTTP client,
> whether UA or not, respects SOR;

Sure, just as security updates can only fix problems for those users who
update, they can't magically make the problems just disappear.

Regards,

John

On Thu, Jun 30, 2011 at 3:59 PM, John Daggett <jdaggett <at> mozilla.com> wrote:

    Glenn Adams wrote:

    > Regarding the last, please show me an attack based on font access that
    > SOR prevents.

    One possible attack scenario:

    BigCompany decides to design a new logo.  They commission a font
    containing a special glyph with that logo in it.  An access-restricted
    site is created using that custom font.  EvilCompany, a competitor,
    would like to know about that logo before it is released publicly.  They
    insert script in web ads on popular sites that systematically attempt
    to guess possible access-restricted URLs for the custom font.  An
    employee of BigCompany hits one of the pages on an external site
    containing one of EvilCompany's webads.

    If no origin restriction exists, the web ad code can access the font as
    long as they guess the right access-restricted URL and an
    employee of BigCompany happens to have access.  The script inserted in a
    webad by EvilCompany accesses the custom logo glyph and sends it back to
    an EvilCompany-controlled site.

    If font loads are restricted to same origin and the BigCompany hasn't
    explicitly enabled cross-origin loading via CORS, the web ad code will
    *never* be able to load the font even if their code guesses the right
    access-restricted URL, since it's origin is different.

    The scenario is the same one as in the WebGL example I noted earlier,
    without same origin restrictions content can be accessed via means
    that are not immediately obvious to the naive author.

    Regards,

    John Daggett

Vincent Hardy | 1 Jul 02:07 2011
Picon

FX Task Force Charter Worksheet Update

Dear CSS and SVG Working Groups,

Please find attached an updated worksheet for the different work items on the charter for the FX task force. It adds a new column with the result of the SVG Working Group's discussion on the different work items and its proposed way forward, in an effort to help the discussion.

Kind Regards,
Vincent

.doc-date { font-weight: bold; font-size: 10pt; color: #ccc; margin-top: 0px; } .authors { display: block; font-style: italic; font-size: smaller; color: gray; } *, a, td, th, table, a { font-family: Tahoma, Geneva, sans-serif; font-size: 10pt; } body { width: 600px; margin-left: auto; margin-right: auto; background: #fff; margin-top: 0px; padding: 20px; } html { background: #eee; padding: 0px; margin: 0px; } h1 { color: #1C75BC; font-size: 12pt; margin-bottom: 0px; } table { background: white; border-collapse: collapse; } td, th { border: 1px solid #ccc; padding-left: 1ex; padding-right: 1ex; } tr:nth-child(odd) { background: #f8f8f8; } td:first-child { font-weight: bold; color: #666; } th { font-weight: bold; background: #eee; color: #666; } a { color: #1C75BC; text-decoration: none; font-weight: normal; } a:hover { color: crimson; } sup { font-size: 8pt; font-weight: normal; } li { margin-left: 0px; } ul { font-weight: normal; font-size: smaller; padding-left: 0px; list-style: inside square; } ul.subdued { color: #aaa; } .alert { color: crimson; font-weight: bold; display: block; }

FX Task Force and Related CSS & SVG Specifications and Drafts

June 6th 2011

This document summarizes the list of items listed on the FX Task Force Charter. Its purpose is to help the CSS and SVG Working Group align their charters and clarify priorities and was created as an action item decided in the CSS Working Group Kyoto Face to Face Meeting in June 2011.

Each row contains one of the topics described in the FX task force charter scope of work, with the addition of the compositing row which came up in discussions in the CSS and SVG working groups. Each column contains the related documents produced by the CSS, SVG working group and the CSS Task Force.

Topic CSS SVG FX SVG WG Resolution
2D Transform CSS 2D Transforms Module Level 3, WD 12-2009.Dean Jackson, David Hyatt, Chris Marrin SVG Transforms 1.0, Part 2: Language, WD March 20 2009Jun Fijisawa, Anthony Grasso FX 2D Transforms 1.0, Part 2: Language, ED (undated).Anthony Grasso, Dean Jackson, Simon Fraser Resolution: work on a single consolidated specification for 2D and 3D transforms that apply to CSS and SVG
3D Transforms CSS 3D Transforms Module Level 3, WD 2009Dean Jackson, David Hyatt, Chris Marrin SVG Transforms 1.0, Part 2: Language, WD March 20 2009Jun Fijisawa, Anthony Grasso FX 3D Transforms? See previous line
Animations and Transitions CSS Animations Module Level 3 (WD 2009)Dean Jackson, David Hyatt, Chris MarrinCSS Transitions Module Level 3 WD (WD 2009)Dean Jackson, David Hyatt, Chris Marrin, David Baron SVG Animations (WD 2011) (based on SMIL)Erik Dahlström et al. Web/FX Animations & Web/FX Transitions? Resolution
Proposal:
  • Work on the CSS Animation and CSS Transitions specifications in the FX task-force. Make sure they work for SVG properties and attributes.
  • Have a specification for defining timing, synchronisation and scripting API. It is not yet decided where that specification would live. This specification would be referenced by SVG 2.0 and whatever other CSS-syntax animation specifications exist.
Filter Effects No standard. Microsoft has a filter property in IE5-8. SVG Filters 1.2, Part 1: Primer (WD 2007)Erik Dahlström SVG Filters 1.2, Part 2: Language (WD 2007)Erik Dahlström SVG Filter Requirements (WD 2007)Erik Dahlström Filter Effects 1.0: Language (WD 2011)Dean Jackson, Erik Dahlström Resolution:The SVG WG agrees we should have a single filter spec. applying to CSS and SVG which will include predefined filters and extensible filters.
Compositing No current work in that area. SVG Compositing Specification (WD 2011)Anthony Grasso Web/FX Compositing? Resolution:The SVG WG think it would be preferable to work jointly on the compositing spec. but would carry it forward if the CSS WG is not interested.
Gradients CSS gradients chapter in CSS Image Values and Replaced Content Module Level 3 (WD 2011)Elika J. Etemad, Tab Atkins SVG Gradients in Scalable Vector Graphics (SVG) 1.1 (Second Edition) (WD 2011)Erik Dahlström et al. Web/FX Gradients? Resolution:The SVG WG thinks the gradient effort should be coordinated to ensure an interoperable model with SVG gradients even if there are syntactic variations. There should be a way to reference SVG paint servers. Two separate coordinated specifications seem ok.
Parameters No real equivalent I could find in CSS SVG Parameters 1.0, Part 1: Primer (WD 2009)Doug Schepers SVG Parameters 1.0, Part 2: Language (WD 2009)Doug Schepers Web/FX Parameters? Resolution:The SVG WG wants to work on parametrized SVG content and we would like to coordinate with the CSS WG on syntax and possible relation to CSS proposed features such as variables and calc().
Content Layout (extending the calc() function and flexbox for SVG) calc() function in CSS Values and Units (WD 2006)HÃ¥kon Wium Lie, Chris Lilley Flexible Box Layout Module (WD 2011)Tab Atkins, Alex Mogilevsky, David Baron No equivalent ?? Resolution:The SVG WG proposes that any spec. that specifies how any CSS layout spec. applies to SVG content would be done in an SVG WG specification, coordinated with the CSS WG.
Advanced text layout (along with XSL-FO WG)
  • Wrapping text to a shape
  • Sizing shapes to fit text
  • Vertical text
CSS Exclusions (ED 2011)Vincent Hardy CSS Writing Modes Module Level 3 (WD 2011)Elika J. Etemad, Koji Ishii, Shinyu Murakami Flowing text and graphics in Scalable Vector Graphics (SVG) 1.2 (WD 2004)Dean Jackson ?? Resolution 1: The SVG WG would like to align future editions of the SVG specification with CSS writing modes for vertical text layout.
Resolution 2: The SVG WG would like to have coordination on the CSS Floats/CSS Exclusion effort so that text wrapping inside or outside arbitrary shapes can be done on SVG elements and exclusions can be defined by SVG elements.
Resolution 3: the SVG WG would like the CSS Float/Exclusions effort to consider the ability to size text to fit in a particular shape or to size a shape to accommodate for a particular text flow.
Shared properties (such as 'image-fit') object-fit in CSS Image Values and Replaced Content Module Level 3 (WD 2011)Elika J. Etemad, Tab Atkins ?? Resolution: (with edits). The SVG WG would appreciate if the CSS WG coordinated when adding properties that could be useful for svg too. Any change to an existing shared property will need coordination between the groups, any new shared properties can probably be handled in an SVG spec if it affects svg - or directly in a CSS spec if that's deemed more appropriate when coordinating.
Boris Zbarsky | 1 Jul 02:14 2011
Picon

Re: css3-fonts: should not dictate usage policy with respect to origin

On 6/30/11 6:55 PM, Glenn Adams wrote:
> if EvilCompany does not include an Origin header in its request

EvilCompany doesn't get to generate its request.  EvilCompany relies on 
requests the user's browser makes.

> if BigCompany does not respond to fetches not containing an Origin, then
> again EvilCompany can guess an origin that permits access, resulting in
> a fetch;

EvilCompany can't make direct requests to sites inside BigCompany's 
firewall.

> EvilCompany does not need to use a UA, but can construct their own HTTP
> client to accomplish this;

No, see above.

-Boris


Gmane