W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2016

Some questions regarding the status of UIS and CSP

From: Jose Kahan <jose.kahan@w3.org>
Date: Fri, 11 Mar 2016 17:15:34 +0100
To: public-webappsec@w3.org
Cc: wseltzer@w3.org
Message-ID: <20160311161534.GA24475@kiribati.inrialpes.fr>
Hello, 

I'm preparing a talk presenting HSTS, UIS, CSP, and CORS use at W3C. I'd like
to ask your help with some questions.

Regarding Upgrade-Insecure-Requests (UIS):

- Could you tell me if there has been progress for adoption for
  Upgrade-Insecure-Requests by browsers other than FF and Chrome?

   http://caniuse.com/#feat=upgradeinsecurerequests

- The latest FF (45) doesn't yet send the Upgrade-Insecure-Requests. Do you
  know if there's some issue as to why they haven't yet done it?

- The latest Opera (35.0) sends the Upgrade-Insecure-Requests header but
  doesn't support the internal redirection from HTTP to HTTPS so still
  shows mixed content.

- Has there been any progress in moving forward the CR to Rec or a change of
  plans? I see there's only one open issue (dating from January)

Some few questions on CSP too:

- I'd like to know if you're planning to push forward CSP Level 2 to
  recommendation or if you will drop it in favor of CSP Level 3?

- Is it still too early to encourage people to adopt CSP in production? I see
  that many sites have already adopted it (github, twitter, ...), but I also
  see that not everyone is using the same directives and are still using
  X-Frame-Options and frame-src instead of frame-ancestors.
  
- For data: I'd like to know if you have looked at having a more
  specific granularity for data: URIs that would allow to specify
  a policy for media types. This would be interesting so that
  rather than do an all or nothing for data: we could say that
  the policy allows data:application/x-font-woff but forbids all
  other kinds of data: URIs. I didn't see a provision for this in
  the L2 or L3. I apologize if you have already discussed this in
  the past.

- How do Content-Security-Policy: and
  Content-Security-Policy-Report-Only: interact between them? Is
  Content-Security-Policy applied before
  Content-Security-Policy-Report-Only is evaluated or are both
  independent?
  
 - Why is frame-ancestors being ignored when monitoring a policy in CSPL2?
   
  [[The frame-ancestors directive MUST be ignored when monitoring a policy, and
   when a contained in a policy defined via a meta element.  ]]

  I see this is not mentioned in CSPL3 and chrome does send a report when
  monitoring this directive. FF does not send a report. This makes it harder to
  evaluate the impact of this directive before putting it in a live policy.

Thank you for your time and consideration.

-jose
Received on Friday, 11 March 2016 16:15:40 UTC

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