New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 233903 link

Starred by 56 users

Issue metadata

Status: Assigned
Owner:
OOO until 4th
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 233904


Show other hotlists

Hotlists containing this issue:
Top-Starred-Bugs


Sign in to add a comment

CSP: Bookmarklets should bypass pages' policies.

Project Member Reported by mkwst@chromium.org, Apr 20 2013

Issue description

Bookmarklets. People love them, and CSP breaks them.

Instapaper, for instance, injects a script tag to load instapapering code from Instapaper's origin. I suspect it would end up injecting CSS as well. Though the bookmarklet itself executes as expected, it's actions on the page are subject to the page's policy, so these loads are likely blocked. That's certainly the case on mikewest.org and github.com.

Ideally, we'd bypass the page's policy for these loads, exactly as we do for extensions. That's unfortunately a tough problem.
 

Comment 1 by mkwst@chromium.org, Apr 20 2013

(I would love for you to have brilliant ideas on this topic, Adam. :) )

Comment 2 by mkwst@chromium.org, Apr 20 2013

The best idea I have at the moment is to change WebFrameImpl::loadJavaScriptURL to evaluate the URL in an isolated world, and to ensure that world is set up in the same way extensions' worlds are constructed wrt CSP.

That would be a fairly substantial change in behavior for bookmarklets, as they'd act like content scripts, and no longer have access to page's variables.

I'm not sure that's a change we can make.

Comment 3 by mkwst@chromium.org, Apr 20 2013

Blocking: chromium:233904

Comment 4 by abarth@chromium.org, Apr 20 2013

Yeah, I think that running them in an isolated world would break many bookmarklets that expect access to the page's global scope...

Comment 5 Deleted

Comment 6 by oyas...@gmail.com, Apr 21 2013

Yes, that would fix the generic bookmarklets like variants on ShareThis, but not site-specific bookmarklets that integrate a little deeper.

I'd hate to see bookmarklets go the way userscripts did in Chrome 21, as the net effect is that we're raising the threshold for people to meaningfully fix and improve the web and share those improvements. And I know that would presuppose that all sites get CSP headers or default policies for CSP tightens, but as the latter pretty much needs to happen, I do. Punting on the issue now kills those properties of bookmarklets and the web indefinitely.
Any update on this?  We're big fans of increasing web security, but this seems like it breaks tools that users purposely install to enhance their experience of the web.

Our bookmarklet (the main way to use http://TipTheWeb.org/ ) no longer works on GitHub pages, for example, which is a pretty big bummer.

Comment 8 by abarth@chromium.org, Jun 22 2013

Please consider writing a browser extension rather than a bookmarklet.  You might want to use a "page action" or a "browser action" as a UI surface.

Comment 9 by Deleted ...@, Aug 28 2014

Hello.

Will this be fixed?
Is there any workaround? 

My bookmarklet clipper loads a script tag inside the page to load the app. And this seems not permitted by Chrome.

See related SO question: http://stackoverflow.com/questions/25531038/content-security-policy-for-extensions-and-bookmarklets



The spec says: "Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets." 

I, too, use many bookmarklets and am disappointed when they're disabled on websites because of CSP. It would be great to get this bug fixed to follow the spec.


Comment 12 by cvreb...@gmail.com, Dec 10 2014

This bug is breaking Bootstrap's Bootlint tool on some sites: https://github.com/twbs/bootlint/issues/201

Comment 13 by Deleted ...@, May 9 2015

I have created a work-around "fix" for this issue using a Greasemonkey userscript (in Firefox). You can now have bookmarklets on all CSP and https:// sites, plus have your bookmarklets in a nice, easily-editable library file instead of being individually squished into a bookmark.

See: https://groups.google.com/d/msg/greasemonkey-users/mw61Ynw5ORc/Gl_BNUhtSq0J

A *very* simple solution would be to embed a "CSP override" rules for every bookmarklet (it could be included in the bookmarklet itself, like "use strict"; code, see below). When the user trigger the bookmarklet, merge the "CSP override" with the current CSP, and run the code. Please notice that this scheme does not allow "bookmarklet-downloaded" script to modify the protection rules, so it's safe from "compromised" exploitation. 

Typically, the process would be:
1) User drags the bookmarklet into its bookmark bar.
2) The bookmarklet code contains a line on top:
 "Content-Security-Policy-Override: script-src instapaper.com, form-action instapaper.com";
3) A window opens asking if the user allow this bookmarklet to "download script from instapaper.com" and "post content to instapaper.com"
3.1) If no, the bookmarklet is not installed. This is very important, as it means that if a bookmarklet is in the bookmark folder, it's allowed to run
4) On any page with or without CSP header present, clicking on the bookmarklet merge the CSP override rules, and run the script (which will now be allowed to do the work that was previously forbidden)

In the end, there is no need to taint the bookmarklet code/script/action, it's very short to do (since it only require changes in the "bookmarklet" run code and install code, and nothing anywhere else in the JS or Net code.

The only drawback is that bookmarklet provider will have to update their "initial" bookmarklet, but that's not really a problem since currently, their bookmarklet don't work, so an action is required anyway.
Without bookmarklets to work i have to use proxy by modifying my own host file, and faking URL. Otherwise we can also use snippets in devtools to hot load ours scripts.... but both of this are weird solution... Please guy. Make it works. #PowerUser
Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.

Comment 17 by tkent@chromium.org, Feb 19 2016

Components: -Blink>CSP Blink>SecurityFeature
 Issue 595004  has been merged into this issue.

Comment 19 by arn...@b-lex.nl, Aug 17 2016

If you'd be willing to do what's mentioned in Comment 14, why not generate a random identifier at startup, eg "Content_Security-Policy-Override: BOOKMARKLET_VERYRANDOM_12345", autoinject that into javascript: bookmarks on execution, and recognize that to avoid CSP blocking ?


Labels: Hotlist-EnamelAndFriendsFixIt
Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment