Live data from Hacker News

Show HN: Favicons for HN

gist.github.com

31–40 of 73 posts

Re: Show HN: Favicons for HN

#31
post #6

Doesn’t work (at least for me in Chrome with Tampermonkey) due to Hacker News’s Content-Security-Policy header. > Refused to load the image ' ' because it violates the following Content Security Policy directive: "img-src data: 'self' ". Overriding this would probably require an extension with a Service Worker that edits the CSP header.

Yeah, appears XHR/fetches are similarly blocked – was looking into data URIs. Good job HN for getting a decent CSP set up!

All I need in my life right now is trying to debug someone else's XHR problems. Lord, why didn't you send me this sooner.

Re: Show HN: Favicons for HN

#35
post #6

Doesn’t work (at least for me in Chrome with Tampermonkey) due to Hacker News’s Content-Security-Policy header. > Refused to load the image ' ' because it violates the following Content Security Policy directive: "img-src data: 'self' ". Overriding this would probably require an extension with a Service Worker that edits the CSP header.

This modification works for me: https://greasyfork.org/en/scripts/443687-hn-favicons. It uses GM.addElement to bypass CSP restrictions.

Re: Show HN: Favicons for HN

#36
post #10

Earlier quoted context omitted.

This - an alternative approach could be to create the images with a URL of '{domain}/favicon.ico' and then add an onError event to switch the URL to the DDG URL only for instances where the site's favicon isn't in the default location.

Many sites have png favicons that may be stored anywhere. You kind of need to parse the HTML to be sure, and I guess that's what the DDG service does.

For sure, but even a lot of those sites maintain a favicon.ico to support legacy crawlers/systems - then for those that don't (i.e. trigger onError), falling back to DDG's icon is an easy way to skip all that parsing.

Re: Show HN: Favicons for HN

#37
post #18
post #6

Doesn’t work (at least for me in Chrome with Tampermonkey) due to Hacker News’s Content-Security-Policy header. > Refused to load the image ' ' because it violates the following Content Security Policy directive: "img-src data: 'self' ". Overriding this would probably require an extension with a Service Worker that edits the CSP header.

It's possible that GreaseMonkey on Firefox has different policies than other extensions on Chrome

Greasemonkey injects scripts into the content context [1], which is (arguably) more secure than injecting them directly into the page. From there they run with similar permissions to the extension which installs them. They can't be blocked by the page's CSP settings, and requests they make aren't subject to the same-origin policy. On the other hand, they're isolated from the page, which provides an additional layer of protection from the page accidentally getting access to privileged APIs like GM.xmlHttpRequest, which is a historic issue with user script managers.

ViolentMonkey supports this API, but unfortunately doesn't use it by default. You can enable it with `// @inject-into content` in the header.

Firefox additionally has an API and context specifically for user scripts (the userScript API), but GreaseMonkey doesn't use this unfortunately. A pull request adding support for it to either GM or ViolentMonkey would be nice if someone knowledgeable were so inclined. This API provides some additional protection (scripts are subject to SOP unless the extension breaks them out, and scripts are in addition isolated from each other), so it's a "nice-to-have" but not totally necessary if your user scripts come from trustworthy sources (i.e. you write them yourself).

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Post reply on HN