You can use the following URLBlacklist policy to block bookmarklets:

{
  "URLBlacklist": ["javascript://*"]
}

Closing this FR since this capability is already present in the product.

Unfortunately the URL Blacklist policy as it currently works do not appear to block this issue.

The issue appears to be that bookmarklets can start with "javascript:" (without the "//"), which are not blocked by "javascript://*" on the URL blacklist.  And it is not possible to specify "javascript:*" on the blacklist - the Google Admin Console gives the "not a valid URL pattern" error.

To replicate the problem:
1) Set up "javascript://*" on the URL Blacklist policy for the user, and confirm as the user (using chrome://policy) that the policy is activated for the user.
2) As the user, set up the following as a bookmarklet (this opens up wikipedia within an iframe on the current webpage):

javascript:((function()%7Bvar a,b,c;c="https://www.wikipedia.org/",b=document.createElement("iframe"),b.setAttribute("src",c),b.setAttribute("id","rusic-modal"),b.setAttribute("style","position: fixed; z-index: 999999; width: 600px; height: 400px; right: 10px; top: 10px; border: 5px solid #8834af; overflow: hidden; background-color: #fff;"),a=document.getElementsByTagName("body")%5B0%5D,a.appendChild(b)%7D)).call(this)

3) Browse to any webpage, and click on the bookmark.  The bookmarklet still executes, opening an iframe within the webpage and navigates to wikipedia.

OK, thanks, you are correct that URLBlacklist doesn't work - I was screwing up my test by trying to apply my bookmarklet to the new tab page (bookmarklets don't work on that page, so I think I was testing the policy on the NTP and mistakenly thinking the policy worked :)

I think the issue is that URLBlacklist relies on blocking top-level navigations, but bookmarklets don't trigger navigations.

ultrotter/poromov: I'm marking this as a bug since I think it's a bug that you can't block bookmarklets with URLBlacklist. I'm fine if we decide to address this issue by adding a new policy that just blocks bookmarklets directly though, since I suspect it will be difficult to make URLBlacklist cover cases that don't involve navigation.

qq: if we are blocking storing javascript commands as a bookmark, won't students be able to simply open the developer console and execute the javascript action from there? It seems that without disabling developer tools fixing this might not fix the actual problem, just require a further workaround, am I right?

There is already a chrome policy to disable developer tools. We ask schools to do this for students as part of the set up of our product on their domains.

Thanks. And does this Bookmarklets workaround work even with developer tools disabled? Or does disabling developer tools also close this?

Thanks!

Unfortunately bookmarklets still work even when developer tools are disabled.

Thanks!

Could someone please give me an update on this issue?  Our customers are asking us about this issue.  Is there an ETA on this?

Thanks very much
Tony

We will proceed by investigating whether this would work enabling javascript:* in URLBlacklist as a modification in CPanel or whether to just disable them in client when developer console is disabled. Sorry there was a delay, due to the holiday period.

Thanks,
Guido

Please don't extend the devtools policy for this. If you can't make URLBlacklist work for bookmarklets then let's add a dedicated policy to disable booarklet urls.

Looks like that URLBlacklist is checked only for external protocol handlers, it has nothing to do with pseudo-url like “javascript:…” or “chrome:…”. I have altered policies on my testing device (via local files) and "javascript:*" neither blocks bookmarklets nor even manually-entered javascript in omnibox.

So, solution could be to move blacklist-check in earlier stage of url handling, or, as stated in comment #17, add a new policy for this.

Although we have to distinguish “javascript:…” link that comes from bookmarklet or omnibox (and block it according to policy) and one that comes from site itself (if an element on the page has “href="javascript:…"” property instead of “onclick="…"”, it's still no reason to break it).

This makes me think that extra policy may be a better idea than adding blacklist checks in some more places. Otherwise we will get a complex logic somewhere, like “IF it's javascript or another debug link (because normal links we want to black later, when we can show nice “is blocked” page) AND it comes from user (by typing or by activating a bookmark, but not my clicking a link on a page) THEN do an extra blacklist-check before handling navigation request”.

Could you please give me an update on this issue? This continues to affect teachers using our product to monitor and manage students using chromebooks, and the loophole is becoming more and more widely known.  Thank you.