Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify whether images and icons must be served over HTTPS #145

Open
collimarco opened this issue Feb 11, 2019 · 4 comments
Open

Clarify whether images and icons must be served over HTTPS #145

collimarco opened this issue Feb 11, 2019 · 4 comments

Comments

@collimarco
Copy link

ServiceWorkerRegistration.showNotification() has an icon and image options. It is not clear from the standard whether those resources must be served over https or if http is acceptable as well.

Moreover Firefox and Chrome have different behaviors: Firefox shows the icons over http, while Chrome doesn't display icons and images served over http (see related Chromium issue).

Please clarify if HTTPS is required or not.

@annevk
Copy link
Member

annevk commented Feb 11, 2019

Per https://w3c.github.io/webappsec-mixed-content/#should-block-fetch it should work, but it might not be a bad idea to disallow it given it's a somewhat problematic practice and a new context for loading such problematic resources.

cc @mikewest

@beverloo
Copy link
Member

It looks like our implementation issues a warning from Document-contexts, but blocks the request from Worker-contexts. I don't think we currently have metrics in place for measuring how often this is used, but in principle I agree that disallowing it might be a good idea.

@annevk
Copy link
Member

annevk commented Feb 11, 2019

This was maybe meant to fall out of https://w3c.github.io/webappsec-mixed-content/#strict-mixed-content-checking-flag, but there's a lot of bugs around that.

@mikewest
Copy link
Member

I agree with @annevk and @beverloo: let's restrict the icon and image options to secure resources. That is both the simplest solution, and the most forward-compatible with a secure web (and, if Chrome is accidentally already shipping it, probably quite compatible with today's web as well).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants