Hacker News Reader

Comment by Ayesh | Hacker News Reader

Sites can impose a Content Security Policy, that (among other things) can disable inline JavaScript. This makes it a real PITA to modify web sites with user CSS/JS.

I am personally aligned with pro-CSP because it can greatly reduce the attack surface of web sites I host, and is quite effective and precise.

Browser extensions can, and do, play around CSP.

Bookmarklets has no overhead in the browser, because they are just bookmarks that do not interact with the browser unless I click it. Having a little addon for each little functionality is annoying, slow, and difficult to maintain and review.

View on HN

Why do browsers enforce CSP against bookmarklets and user scripts, though?

The goal is to prevent any way for attackers to inject code.

Bookmarklets and user scripts are collateral damage.

That's probably the right choice, but it sounds like there should be a "captcha" to separate programmers from non-programmers.

The browser remains in a locked down kiddie mode until you solve these riddles three!

Naive users can be convinced to run random code.

Go to discord.com (no need for account) and open browser console.

You will see

> Hold Up!

> If someone told you to copy/paste something here you have an 11/10 chance you're being scammed.

> Pasting anything in here could give attackers access to your Discord account.

presumably they added it after it kept happening. And likely the same things happens when random user can somehow run code they got from scammer :(

I can see something like that as a separate red box above the actual console in opera and firefox, regardless of the current site. Annoys me as hell, cause there is no way(?) to turn it off.

It looks like Mozilla fixed it for bookmarklets[1] three years ago in Firefox 69.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478037

Bookmarklets & user scripts evaluate in the page's context.

CSP literally says, only talks to these specific domains. https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#exampl...

The browser doesnt block thr bookmarklet from running (iirc). But most bookmarklets immediately try to download & run some libraries to do their thing. Or they try to send data somewhere. And CSP is blocking those connections.

Its hard form me to guess how much of this is intentional anti-user lock out, and how much is just oversight or technical diffifulty. I could see not wanting to drill backdoors through your own security policy, which is more or less what it woild take, but it sure feels lile a loss. Users can turn off csp for the browser with a flag if they want, but we can only do that to the whole browser, not site by site. Also worth pointing out that just disabling csp for thr browser/site (rather than carving exceptions for userscripts/bookmarklets) is something sites can detect (by succeeding in a request that ought not go through) & could potentially decide not to serve you content or what not if they wanted to be petty. That said, extensions exist & arent readily detectable so there's options... they are just nowhere near as direct to author & use.

I found the bug I opened against the csp spec, asking for it to not obstruct userscripts. https://github.com/w3c/webappsec-csp/issues/444

I don't see how this could be truly secure if it's JS running on the client. There is nothing stopping a user from running a custom version of Chromium or otherwise that ignores CSPs... Maybe I'm not fully understanding what is being restricted here and where the code is being run.

I guess it's reducing the attack surface for your users, as you can't have a malicious userscript that would log your cc number or something

Reply on news.ycombinator.com