1336584 - about:addons triggers consolespam: "Content Security Policy: Directive ‘frame-src’ has been deprecated. Please use directive ‘child-src’ instead."

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Daniel Holbert [:dholbert]]

STR VERSION 1:
 1. Visit about:addons.
 2. Click "Get Add-ons" in the left pane, if it's not already selected.
 3. Open Web Console (ctrl shift K)

STR VERSION 2:
 1. Visit https://discovery.addons.mozilla.org/
  (This is the domain from which content is loaded in the "Get Add-ons" pane)
 2. Open Web Console (ctrl shift K)

ACTUAL RESULTS:
The web console contains the following warning for this pageload:
> Content Security Policy: Directive ‘frame-src’ has been deprecated.
>   Please use directive ‘child-src’ instead.

EXPECTED RESULTS:
We should not be using deprecated directives that trigger warnings in our own product. We should follow our own suggestion here.

Historical note: this warning is spammed here:
https://dxr.mozilla.org/mozilla-central/rev/1d025ac534a6333a8170a59a95a8a3673d4028ee/dom/security/nsCSPParser.cpp#1116-1120
...and was added in this bug 1045891 for Firefox 45.

Comment 1

[Daniel Holbert [:dholbert]]

The network tab shows that I get the following "content-security-policy" response header from discovery.addons.mozilla.org:
=============
default-src 'none'; base-uri 'self'; child-src 'none'; connect-src https://addons.mozilla.org; form-action 'none'; frame-src 'none'; img-src 'self' data: https://addons.cdn.mozilla.net https://addons-discovery.cdn.mozilla.net https://www.google-analytics.com; media-src https://addons-discovery.cdn.mozilla.net; object-src 'none'; script-src https://addons-discovery.cdn.mozilla.net https://www.google-analytics.com/analytics.js; style-src https://addons-discovery.cdn.mozilla.net 'sha256-DiZjxuHvKi7pvUQCxCVyk1kAFJEUWe+jf6HWMI5agj4='; report-uri /__cspreport__
=============

It includes frame-src 'none', which is what's triggering the warning.  Interesting, it *also* happens to include a child-src directive! (The one that our warning is suggesting here.)  So it seems discovery.a.m.o is just sending *both* an old/deprecated directive and its new/modern replacement.

Kate, looks like you worked on "child-src" -- two questions for you:
 (1) Is it reasonable for sites to do this (send both the old & new directives)?
 (2) If "yes" (i.e. if this is a legit/maybe-common use-case), then would it be worth screening for the presence of the new directive before we spam a warning about the old one?  (It seems silly to say "You should use FOO" when in fact the site is already using FOO.)

Comment 2

[Daniel Holbert [:dholbert]]

The plot thickens!

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#Specifications :
  "Content Security Policy Level 3   [...] Undeprecates frame-src.

That spec (Level 3) describes this change here:
  https://w3c.github.io/webappsec-csp/#changes-from-level-2
...and further down, it actually says "The child-src directive is deprecated" [in favor of frame-src]!!
  https://w3c.github.io/webappsec-csp/#directive-child-src

So as of Level 3, it seems the tables have turned on which of these two directives are deprecated vs. favored.  (I assume we don't implement that level yet, given this console warning though.)

So perhaps we should stop spamming this "frame-src has been deprecated" warning, since we presumably don't want to discourage authors from using it after all?

Comment 3

[Daniel Holbert [:dholbert]]

(and of course if the solution here is to tweak/kill the warning, then this bug should be reclassified to a Gecko component like "Core|DOM: Security" or somesuch. I'll leave that up to Kate/Christoph since they presumably know the CSP spec / deprecation details better than I do.)

Comment 4

[Kate McKinley [:kmckinley, :Kate]]

Hi Daniel! CSP is currently an editor's draft, so the change to frame-src/child-src has not yet been made official. It doesn't make sense for us to change how it works yet.

It is perfectly reasonable for sites to send multiple directives in cases like this. If a browser does not understand a directive, it is supposed to ignore it. So for browsers that only support CSP 1, we still need to send frame-src.

It's still important to let web developers know when they are using deprecated directives, as those are likely to be removed in the future. As you note, in CSP3 this is likely to be reversed, so in the future we will likely send the warning for child-src instead.

Comment 5

[Stuart Colville [:muffinresearch]]

From the amo perspective we originally started serving identical frame-src and child-src  for backwards compatibility with a view to eventually removing frame-src in due course. 

Since there's the potential for back-tracking in the spec we're not likely to change anything there at the moment. 

I think it would be good to consider making the deprecation notices smarter so as not to warn if superceding rule is additionally detected however, I can see that would increase the complexity of how deprecation warnings work.

I think this is a wontfix as far as this component is concerned for now, but feel free to move this to an alternative component and reopen if there's something to do elsewhere.

Comment 6

[Daniel Holbert [:dholbert]]

Thanks for your thoughts here, Kate & Stuart!

(In reply to Kate McKinley [:kmckinley] from comment #4)
> It is perfectly reasonable for sites to send multiple directives in cases
> like this. [...]
> It's still important to let web developers know when they are using
> deprecated directives, as those are likely to be removed in the future.

These two statements don't make sense to me.

If it's reasonable (and even best-practice) for sites to send deprecated versions *along with* their modern versions, then it seems like we shouldn't warn in that scenario (specifically in the case where we can see that both versions are sent).

Having said that, I can imagine that this might make the warning logic more complicated, as stuart hinted at.

In the meantime, we're in the unhappy situation of having a piece of Firefox UI triggering a "Security Warning". :-/  That's a little embarrassing, albeit harmless.  Given potential-deprecation-reversal in the spec, I agree with Stuart that the only thing that we might want to do here would be to relax the warning logic to detect this dual-directive case... Kate, do you think that's a possible/sane thing to do?