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

Make user's the driver of the user-agent again: bookmarklets, userscripts #444

Closed
rektide opened this issue Oct 24, 2020 · 10 comments
Closed

Comments

@rektide
Copy link

rektide commented Oct 24, 2020

Hello. I have been using https://hypothes.is for most of a decade to be able to annotate & document my travels across the web as I go.

Content Security Policy has, it seems, broken my ability to navigate the web as I prefer. When I go to popular sites like https://github.com or https://twitter.com and try to run the bookmarklet or try to run a user script, the browser now tells me that "Content Security Policy: The page’s settings blocked the loading of a resource at https://hypothes.is/embed.js . So the bookmarklet or script runs, but it cannot bootstrap, because of CSP. This is a very common technique for bookmarklets to use, to bootstrap a file, since only so much content can fit in a javascript: url.

How can we the users regain control of the navigator & make it a user-agent once more? At the moment, I have lost all user agency that I used to have. I am not a crying type of person but this has been enormously massively colossaly tumultous & disruptive, I am in deep despair over this new state of affairs. Times are hard in the world, but watching this happen to the web is tearing my heart out ya'll, this is just so so so brutal & callous, it hurts so much to be rejected by the browser & told that I have no power, after years of having userscripts and bookmarklets as a means to express agency & work with the web. I have been put into a new, daring, bold, horrifying read-only mode, where I the user have no control. This is so so so SO hard to cope with, being stripped of all power. I can not state how badly CSP has made me feel.

The power to control the experience is now being dictated to me by the sites I visit, and this is bad and not acceptable. This is a critical violation of RFC 8890 The Internet Is For End Users, and this specification needs to change to require means for the user to have >0 level of control. What are some ways we can come up with to afford the user some agency as they navigate the web?

@ArthurSonzogni
Copy link
Member

ArthurSonzogni commented Oct 24, 2020

Hi @rektide,

I totally agree we should make the user in control. Websites shouldn't take control over the users. I understand your pain with CSP. I see criticism, do you have any solution to propose?

We can't abandon CSP, this is a critical defensive security feature of the Web. I guess you might propose "detecting" what actions have been caused by the javascript: URL, and bypass security features when we "think" this was caused by the injected script. Keeping track of the chain of causality looks like an intractable puzzle, not sufficiently defined.

Security is critical for the web. Especially with all the powerful features the Web now provides (WebPayment, WebUSB, Authentification, ...)

Using Bookmarklet to inject script into the page is hazardous. What if the https://hypothes.is got hacked and the https://hypothes.is/embed.js is replaced by a script used to exfiltrate your credentials? Currently this isn't possible on https://github.com, https://twitter.com or https://google.com, because they are using CSP. Isn't this a nice property?

Instead of navigating toward javascript: URL. I would recommend using extensions. I see https://hypothes.is/ is providing one. Does it resolve your issue?

I strongly discourage this, but you can even disable CSP using an extension. This is the proof users have still enormous power. This extension sounds like shooting yourself in the foot, but you can use it if you really wanted to.

Even if navigations toward javascript: URL is convenient, this has been a huge pain for me to continue supporting it. This caused several security bugs. This prevents simplifying the architecture and improving the web browser. If I could go back in time, I would beg this hack wasn't introduced in the first place. Now we need to live with it for decades.

Looking forward for your responses,
Arthur

@annevk
Copy link
Member

annevk commented Oct 26, 2020

FWIW, I think this is an issue with your browser, not with CSP. CSP has no authority over those features. I recommend filing a browser bug.

@ArthurSonzogni
Copy link
Member

FWIW, I think this is an issue with your browser, not with CSP. CSP has no authority over those features. I recommend filing a browser bug. ~@annevk

This surprised me. So I tried Firefox (68.12.0esr). I stored "javascript://alert('hello')" in a bookmark. While being on the https://github.com page, I navigated to it. It got what I expected:

Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

So I don't think this an issue with a browser in particular. This is just the way CSP is expected to work.

@annevk
Copy link
Member

annevk commented Oct 27, 2020

I'm not sure how that proves anything? What browsers allow users to do is very much up to them.

@ArthurSonzogni
Copy link
Member

Okay Thanks! I get your point.

@rektide
Copy link
Author

rektide commented Oct 31, 2020

There ought to be well defined Paved Roads for implementing user agency. Closing this issue & leaving it to everyone to & thtry to give users back some modicum of power is a wild mind blowingly anti-user stance for the web standards groups to push.

The CSP spec should define heightened user agency overrides, which browsers can optionally implement. User agency ought to be a standardized behavior.

@ArthurSonzogni
Copy link
Member

ArthurSonzogni commented Oct 31, 2020

Sorry, I didn't see any response from you for a week. I didn't see any proposal in your first message. I thought this was closed.
(reopening this issue)

@dveditz
Copy link
Member

dveditz commented Nov 2, 2020

One problem with bookmarks is that they are more of an emergent phenomena than a defined feature. Bookmarks exist, javascript: urls exist, let's try bookmarking a javascript: url! From a user's point of view it would be nice to give the bookmark version extra authority, but from a browser's point of view the mechanics of a bookmarklet is simply navigating a page to the given URL, and when navigating a page to a javascript: url CSP limits what that can do.

It could be done differently but that would take a bunch of work creating a new way to execute bookmarks, and unfortunately the number of people who run complex bookmarklets is extremely small in the scheme of things. It doesn't help the cost/benefit calculation that web extensions, which are used by many more people, do execute this correctly and therefore are a reasonable workaround (as far as the browser vendors are concerned!).

Userscripts, if run in an extension (e.g. GreaseMonkey), should also work just fine.

Every one of us who worked on the CSP standard are completely sympathetic to what you want bookmarklets to do (and in at least my case, what I want bookmarklets to do), but I can't realistically see it happening. I now only use bookmarklets for straightforward scripting, and have written userscripts or full-blown web extensions for everything more complex.

@rektide
Copy link
Author

rektide commented Jul 30, 2022

Just for reference, there is a Firefox bug for this. like Chrome, Bookmarklets/userscripts can be loaded, but cannot bootstrap their code.

I realize many folks wish userscripts didn't exist, but many many users seem to love them. The impedance is very low, & while yes, that is a hazard, it's also a boon many have loved. I realize it's hard to build a spec that encompasses users using longstanding capabilities that were never well specified, but it's still sad to me that we've left these people out in the cold.

There was a thread with a lot of love for bookmarklets/userscripts on popular nerd-news aggregator HN last night. CSP ruining people's experiences came up numerous times. With Manifest V3 making extensions even harder to use & wrecking GreaseMonkey/TamperMonkey/VioletMonkey, good ole userscripts would be an excellent thing to have working, but they've been broken by this specification.

Manifest V3 recently got a registerContentScript which also has this problem.

@rektide
Copy link
Author

rektide commented Oct 2, 2022

Thanks for the patience all. The spec does officially say in § 9.1. Vendor-specific Extensions and Addons:

Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].

Given this, I agree with @annevk's assessment:

FWIW, I think this is an issue with your browser, not with CSP. CSP has no authority over those features. I recommend filing a browser bug.

It would be excellent if there were some idea for what could be specified to support common use-cases like Bookmarklets, some kind of security realm that could be defined in the CSP spec to help fit this purpose. Right now it seems like a big burden on implementers to figure things out for selves, which is probably why all browsers are in violation of §9.1. I would be ok if we close this, but I do also think leaving this issue serves a useful purpose, as this is an outstanding issue for CSP implementers in general & it seems like more help is needed somehow.

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

No branches or pull requests

4 participants