W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: Processing of meta element

From: Oda, Terri <terri.oda@intel.com>
Date: Thu, 13 Feb 2014 11:05:20 -0800
Message-ID: <CACoC0R-Q4qmepKEgLcTKYothh8pDS0fmd_JwdvEL4DJid-hPaA@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
I asked a question about this during the conference call that I think
wasn't clear, but since we were already nearly overtime for that section of
the agenda, I figured it makes more sense to discuss here.

My question was "how did we determine that meta was the best route to
increase security for the type of site we're talking about?"  I understand
that many folk using, say, github or wordpress might not have an easy way
to change their headers (heck, I gave a presentation at web 2.0 security
and privacy back in the day about this).  But I'm wondering whether we have
looked at other alternatives that might work for these folk, given the
security issues later-stage policy enforcement.  ("Better than nothing"
doesn't mean it's the *best* alternate solution to the standard CSP
headers!)

To give a concrete example of an alternative: folk securing their
github-hosted sites generally can upload arbitrary files, and could perhaps
upload a separate manifest file.  This would avoid the javascript policy
injection risks at the price of a round-trip request (a potentially high
cost), but it might also allow for a good road to eventual CSP support by
host github, who could eventually script it so that specific files could be
converted and sent as headers.

It's entirely likely that alternatives to meta have been discussed at
length, but as a new member I was asking what had been discussed, and
whether we'd talked to hosting sites about what they'd actually want their
members doing to secure their individual sites.  Feel free to point me to a
starting point in the archives!

 Terri
Received on Thursday, 13 February 2014 19:05:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC