Safari’s default media controls blocked when applying a Content-Security-Policy
1–6 of 6 posts
Re: Safari’s default media controls blocked when applying a Content-Security-Policy
#2> This can be a security risk as a data URI is considered to be equivalent to the unsafe-inline source.
wow. This is absolutely as insecure as `unsafe-inline` IMHO. I wonder why the spec doesn't mandate the `unsafe-` prefix for `data` too.
CSP really feels a bit half-baked between the various browsers. With the issue brought up here, all major browsers with CSP support have some annoying or even show-stopping bugs:
- Chrome treats responses with `content-type: application/pdf` as responses rendered with a plugin even though Chrome renders PDFs without the need for a plugin to be installed (the fact it's a plugin doing the rendering is an implementation detail). So if you want to even just link to PDFs, you have to enable `object-src`
- Firefox treats scripts running from bookmarklets as being scripts that are directly on the page. This means that unless you list `script-src: unsafe-inline`, your CSP policy can disable the user's ability to use bookmarklets. This is the single instance where a site owner has control over the user agent without the user having ultimate veto powers.
Re: Safari’s default media controls blocked when applying a Content-Security-Policy
#3> This can be a security risk as a data URI is considered to be equivalent to the unsafe-inline source. wow. This is absolutely as insecure as `unsafe-inline` IMHO. I wonder why the spec doesn't mandate the `unsafe-` prefix for `data` too. CSP really feels a bit half-baked between the various browsers. With the issue brought up here, all major browsers with CSP support have some annoying or even show-stopping bugs: -…
Bookmarklets are Dead… …we just don’t know it yet.
https://medium.com/making-instapaper/bookmarklets-are-dead-d...
Re: Safari’s default media controls blocked when applying a Content-Security-Policy
#4> This can be a security risk as a data URI is considered to be equivalent to the unsafe-inline source. wow. This is absolutely as insecure as `unsafe-inline` IMHO. I wonder why the spec doesn't mandate the `unsafe-` prefix for `data` too. CSP really feels a bit half-baked between the various browsers. With the issue brought up here, all major browsers with CSP support have some annoying or even show-stopping bugs: -…
And another: Edge doesn’t support nonces for script files. It supports them for inline scripts though.
Re: Safari’s default media controls blocked when applying a Content-Security-Policy
#5This is consistent with expected behavior from my point of view. A bug in safari's controls would not infect the website. The site clearly sends a policy and safari clearly follows it. Perfectly sensible behavior.
Of course CSP does not allow a way to say -> browser controls are okay. Hence, a debate is quite welcome on whether such a specification is needed.
Re: Safari’s default media controls blocked when applying a Content-Security-Policy
#6> This can be a security risk as a data URI is considered to be equivalent to the unsafe-inline source. wow. This is absolutely as insecure as `unsafe-inline` IMHO. I wonder why the spec doesn't mandate the `unsafe-` prefix for `data` too. CSP really feels a bit half-baked between the various browsers. With the issue brought up here, all major browsers with CSP support have some annoying or even show-stopping bugs: -…
>Firefox treats scripts running from bookmarklets as being scripts that are directly on the page. This means that unless you list `script-src: unsafe-inline`, your CSP policy can disable the user's ability to use bookmarklets. This is the single instance where a site owner has control over the user agent without the user having ultimate veto powers.
about:config -> security.csp.enable -> false