W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2012

CSP and inline styles

From: Yoav Weiss <yoav@yoav.ws>
Date: Fri, 28 Dec 2012 14:58:52 +0100
Message-ID: <CACj=BEjwgoDHbXuXFRJJ3WB=az6ZTTNpUoijmws7xOrMeiyxnw@mail.gmail.com>
To: public-webappsec@w3.org
Iím worried regarding the possibility of CSP banning the use of inline
styles altogether.

Inline style tags are an important part of Web performance best practices.
Only recently, Googleís Bryan McQuade wrote about the performance benefits
of loading the required initial style sheet as inlined[1]. Forcing the
initial style sheet to be external would add at least 2 RTTs to the initial
paint, which on a mobile connection can be significant.

Furthermore, with the recent addition of `@viewport` to CSS, banning inline
styles would prevent the HTMLPreloadScanner/Speculative-parser from
evaluating media queries, since viewport modifications may be applied in
external CSS that is loaded and parsed *after* the HTMLPreloadScanner have

Evaluating Media queries in the PreloadScanner is an important part of a
markup based responsive image solution (such as the `srcset`[2] or
`picture`[3] proposals). The PreloadScanner must address the viewport size
and make decisions according to it. Otherwise, it may load the wrong
resources, which will negatively impact users both in terms of bandwidth
and user exeperience.

I have shown (at part of the RICGís `picture` element prototyping[4]) that
MQ evaluation in the PreloadScanner can work, and a responsive images
markup (`picture`, `srcset` or any other solution) will be able to preload
the required image resources without being blocked waiting for external
styles. That will no longer be the case if inline styles are forbidden, and
`@viewport` rules will be present in external styles. The implications of
that would be a performance penalty, resulting in worse user experience.

What I propose is one of the following:
 * Allow inline style in the pageís `head`, possibly using an
`unsafe-inline-in-head` directive
  - Iím not certain, but I think itís safe to assume that user-generated
content does not get included to the pageís `head`, at least in most cases.
  - The same directive can probably be beneficial for scripts as well.
 * Allow a nonce to enable inline styles, even if inline styles are blocked
by default.
  - Since this is permitted for scripts, I donít see any security downsides

Please note that a ďnonceĒ based solution will make it impossible for some
Web developers to include only certain inline scripts and styles, since
they only have control on their siteís client-side code and a random nonce
requires server-side logic. A recent survey [5] I ran as part of the RICG
showed that ~27% of Web developers have no access to their Web server
configuration, let alone to add server-side logic. Therefore, I believe
that an `unsafe-inline-in-head` directive may be the best way to go,
preferably as a default.

Yoav Weiss

[2]: http://dev.w3.org/html5/srcset/
[3]: http://picture.responsiveimages.org/
Received on Friday, 28 December 2012 13:59:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 December 2012 13:59:25 GMT