User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

visit https://apps.coned.com/stormcenter/external/default.html

Actual results:

did not render - got a bit of nonsense

Expected results:

same as chrome on https://apps.coned.com/stormcenter/external/default.html

Hi Marc!
Could you please add some more information or exacts steps as well as which is the result expected?
I'm trying to open the URL on Nightly as well as Chrome and for both, the message was the same, connection timed out.

It opens for me and I see a page beginning with:

coned_sc_external
EN-US
America/New_York
Loading

Can you open it with Chrome? Can you open coned.com?

Resetting severity to default of --.

Hi!
I was able to reproduce it on latest Nightly version 77.0a1 Build ID 20200420095323, Beta version 76.0b6 Build ID 20200420031429 and Firefox Release version 75.0 Build ID 20200403170909 on Windows 10 connected by VPN US connection.
I attached file with evidence and I changed flags accordingly.
DOM: Security team, if this is not the right component please feel free to route this ticket to the corresponding team, thanks!

The site is sending Firefox a Content-Security-Policy: Default-src ‘self' where the opening quote is a \u0091. That's an undefined Latin-1/Unicode character, but I think it might be curly-single-quote in windows 125x (will have to check). In any case it's not a valid 'self' token so we lock it down to default-src 'none'; as defined in the spec.

I don't know if

• Chrome gets a different CSP
• They special-case the \u0091 quote character
• They handle invalid characters or invalid tokens differently

The latter is ringing a bell: need to check if chrome treats an empty "default-src" as if you didn't specify it at all, or as the spec says to treat it as "default-src 'none';". I think we had a bug on another site where they sent a Yen symbols as the opening quote (wrong charset, obviously).

In any case -- this is currently the site's bug, it's an invalid CSP. We are doing the correct thing. But in practice this is a webcompat headache for us and we might need to match Chrome's wrong thing. Even though Mike agrees it's wrong in theory (if this is like the other bug) they might have trouble fixing it if it breaks lots of sites.

Any thoughts on approach, Thomas?

I recall that we ran into this on webcompat.com issue 18902 in late 2018, where foolip mentioned that it was on Google's radar. It seems to have fallen off though... foolip, was any decision made on Chrome's behavior on CSPs with Unicode quotes and the like in them?

In the meantime, Mike can we reach out to ConEd and see if they're also willing to fix this on their end? If we don't get a response from them, this sounds like something we can work around in the WebCompat system addon for now, until we confirm whether Blink wants to align their behavior with the spec, or we have to change the spec (and Firefox) due to this being a bigger webcompat issue than we've seen so far.

I'll try to find someone to get in touch with. An intervention might be a good short-term fix, yes.

(edit: I used their Contact form, and messaged 2 devops engineers on LinkedIn, hopefully that gets to the right person)

It looks like the poking that was done back in https://github.com/w3c/webappsec-csp/pull/340 was quickly followed by https://github.com/web-platform-tests/wpt/pull/13228 and https://github.com/webcompat/web-bugs/issues/18902.

The tests are here:
https://wpt.fyi/results/content-security-policy/generic/only-valid-whitespaces-are-allowed.html?run_id=516010001&run_id=487600002&run_id=491220003

If the tests are correct it looks like Chrome was updated, but Firefox is still failing two tests. Are those the cause of this issue?

If Chrome is still parsing CSP headers incorrectly, then updating the tests would be very very good.

The issues in comment 9 are whitespace problems. In this bug they are using a bogus quote character. Only apostrophe is used in 'self', not whatever thing they used from (apparently) some Windows 125x character set.

According to Firefox, Chrome, and Curl (with either UA string), the site is sending me this value on OSX and Linux:

Content-Security-Policy: default-src*self'

Is the site sending the \u0091 only intermittently, or only for Windows or connections from the USA?

No, Tom I think they fixed the site -- I emailed them last week. It's working here too.

This bug can probably be closed, but it's worth sorting out the interop problem, so I'll let someone else decide when to close it.

I opened this and it's now fixed for me.

Hi Marc!
Thanks for your reply, I will close this as Resolved WFM based on your comment.
Please feel free to reopen it if you can still reproduce this.

I've filed https://github.com/w3c/webappsec-csp/issues/434 to follow up on the interop issue.