Manifest V3: Remotely-Hosted Code and Tampermonkey

7,481 views
Skip to first unread message

Jan Biniok

unread,
Jan 27, 2019, 3:23:00 PM1/27/19
to Chromium Extensions, rdcr...@google.com
Hi Chromium developers, Hi Devlin

I'm the Tampermonkey developer and I have not studied all the planned changes in detail yet, but this is the one that worries me most. 
> Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code.  This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore.  Server communication (potentially changing extension behavior) will still be allowed.  This will help us better review the extensions uploaded, and keep our users safe.  We will leverage a minimum required CSP to help enforce this (though it will not be 100% unpreventable, and we will require policy and manual review enforcement as well).

While the text above might be interpreted in a way that an extension like Tampermonkey can continue to exist, I got the following explanation from Devlin in an email:

> Note that we will be limiting remotely-hosted/arbitrary code execution in all contexts.  The goal is that we should be able to perform an in-depth security review of an extension and be confident in what it does and whether it poses a security or privacy risk to users (which is possible through web page contexts, as well).  But let's move this conversation to another thread. :)


I understand the need for security, but this means that V3 P1, in the way it's currently planned, will stop Tampermonkey from working entirely, because arbitrary code execution is Tampermonkey's main functionality. Every little userscript would then have to become an own extension. Anyone who wants to do that has to pay $5 to be able to publish an extension. There are so many use cases for userscripts so I hope that this planned change is reconsidered. 

One possibility would be e.g. a new permission that relaxes this constraint and allows remote code execution again. All extensions with this permission could then be provided with a special warning and be examined more intensively. What do you think?

I've been working on Tampermonkey since Chrome version 4 or 5 and I could not live without it anymore. :)

Thanks,
Jan

fe...@wranggle.com

unread,
Jan 27, 2019, 9:47:12 PM1/27/19
to Chromium Extensions, rdcr...@google.com
Jan, this new remotely-hosted code restriction also affects my project, a process automation / RPA system. (wranggle.com
I asked the team about it at the Chrome Dev Summit last November, bringing up TamperMonkey as an example of a productive and popular use of remotely-hosted code, arguing that a permission showing a big scary warning on install should be adequate. Their response was that remote code is too big a threat vector, extensions can do too much harm, that even an extension that starts out benevolent might be later compromised. They seem pretty committed to the decision. 

My solution is to output a custom browser extension for each customer, one containing all the automations/user scripts they use/want. If you're interested in using this kind of approach for TamperMonkey, I'd be happy to collaborate. 

It avoids the new restriction but does complicate the script update process, requiring the user to rebuild periodically. I have some ideas for reducing rebuild frequency though, by making it easy for script authors to serialize css selectors and dom interactions. And luckily, user updates won't get delayed by the store review process--the team said unlisted and domain-locked extensions don't require review.

Best, -Jeff

零欸特

unread,
Jan 28, 2019, 5:48:09 AM1/28/19
to Chromium Extensions, rdcr...@google.com
I also wonder if this will affect userstyle managers like Stylus:

>  output a custom browser extension for each customer

How do you publish these customized extensions?

Jan Biniok於 2019年1月28日星期一 UTC+8上午4時23分00秒寫道:

wOxxOm

unread,
Jan 28, 2019, 9:58:29 AM1/28/19
to Chromium Extensions, rdcr...@google.com
BTW, just in case some Google/Chrome people didn't know - without Tampermonkey, uBlock Origin, and similar extensions, the browser will be totally unusable for millions of power users. Although I guess this number is an acceptable casualty rate.

PhistucK

unread,
Jan 28, 2019, 11:13:07 AM1/28/19
to wOxxOm, Chromium Extensions, rdcr...@google.com
Be wary of using the term "power users" ;) Chrome explicitly tends to cater for non-power users.

PhistucK


On Mon, Jan 28, 2019 at 4:58 PM wOxxOm <wox...@gmail.com> wrote:
BTW, just in case some Google/Chrome people didn't know - without Tampermonkey, uBlock Origin, and similar extensions, the browser will be totally unusable for millions of power users. Although I guess this number is an acceptable casualty rate.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/5207279f-c0cc-40d5-a9cc-e5af5d7f2fd5%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

wOxxOm

unread,
Jan 28, 2019, 11:24:12 AM1/28/19
to Chromium Extensions, wox...@gmail.com, rdcr...@google.com
A tangible objective fact is that for the last 5-10 years Chrome was used by the power users since it allowed extensions to extend its UI/UX.
Whether it was intended or not doesn't change the fact.
My goal was merely to remind of the fact.

fe...@wranggle.com

unread,
Jan 28, 2019, 12:57:35 PM1/28/19
to Chromium Extensions, rdcr...@google.com

How do you publish these customized extensions?
I don't, the users can publish it themselves, use in dev-mode, etc. 

Charles Haynes

unread,
Feb 6, 2019, 9:42:55 AM2/6/19
to Chromium Extensions, rdcr...@google.com
Would it not be possible to run Tampermonkey in dev-mode? Maybe not be able to install it via the web store though?

James B

unread,
Feb 6, 2019, 10:17:14 AM2/6/19
to Chromium Extensions, rdcr...@google.com
I'd be interested to know if this is the case -- if "more dangerous" permissions will live on behind some kind of "I know what I'm doing" flag -- but I also want to make sure it's clear what does or does not meet the use case.  Dev mode is decidedly not for everyday browsing, checking your email, using online banking, etc.  We can debate whether it's wise to do those things in a session where TM is installed, but I'm certain it's being done plenty often in the current version of Chrome.

Does it make sense to continue supporting that model, where one session is used to do both "custom" things that require the flexibility of TM, and "sensitive" things that require confidence that the browser is secure?

fe...@wranggle.com

unread,
Feb 6, 2019, 1:11:44 PM2/6/19
to Chromium Extensions, rdcr...@google.com
Regarding dev mode, I'd prefer it to behave as close to production mode as possible to minimize environment-specific problems. 
A chrome setting would be great though. (Or even a buried flag.)

In my project, the user must explicitly start the script in each tab if they want it running there, and its icon changes while running. 
Perhaps Chromium could have a set of permissions that are tab-scoped, requiring user consent?

L Lawliot

unread,
Feb 6, 2019, 10:25:31 PM2/6/19
to Chromium Extensions, rdcr...@google.com
This affects tampermonkey right? 

Hachirama Ngainmall

unread,
Feb 7, 2019, 3:16:19 AM2/7/19
to Chromium Extensions, rdcr...@google.com


เมื่อ วันจันทร์ที่ 28 มกราคม ค.ศ. 2019 3 นาฬิกา 23 นาที 00 วินาที UTC+7, Jan Biniok เขียนว่า:

Darren Govoni

unread,
Feb 7, 2019, 9:58:34 AM2/7/19
to Jan Biniok, Chromium-extensions, rdcr...@google.com
Chromium,
    Please disable this requirement for locally hosted or manually installed extensions. While the community appreciates vigilance in deterring bad extensions it's hardly the rule and we shouldn't void the good ones. We support thousands of users that will be dead in the water if you enforce this for non web store extensions.

Let's be logical here. 

Thank you

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

Sergio _

unread,
Feb 7, 2019, 10:43:19 AM2/7/19
to Chromium Extensions, rdcr...@google.com
I'm using Tampermonkey on daily basis to automate my work on many websites. It's to many effort to make separate extension per each task. How can we influence to keep old policy? 

Casey Picker

unread,
Feb 7, 2019, 11:32:47 AM2/7/19
to Chromium Extensions, rdcr...@google.com
I'm a daily user of Tampermonkey scripts, and this change would force me to switch to Firefox.  Please reconsider this.

Kaden Mansius

unread,
Feb 7, 2019, 4:53:54 PM2/7/19
to Chromium Extensions, rdcr...@google.com
As a regular user of all sorts of extensions in chrome, and tampermonkey scripts, I would have no way of gaining certain functionality or customization in Chrome. There are many other's who can say the same, and I would request that changes to this feature be minimal and non-intrusive to avoid hurting the functionality of the browser as a whole. 

Thanks,
Kaden

Yümmy Bríoche

unread,
Feb 7, 2019, 5:12:48 PM2/7/19
to Chromium Extensions, rdcr...@google.com
My livelihood currently depends on Tampermonkey/Greasemonkey scripts. My clients are very mistrustful of Chrome extensions and will be forever since they have far more power and can hide malicious code. A script executed on the *monkey platform is completely benign and open source. You can read and edit the script you are running, unlike a typically obfuscated Chrome extension. Please allow remotely-hosted code execution. The alternative is Firefox or a python-based browser, forcing my three million clients to ignore Chrome altogether.

Salem Beats

unread,
Feb 7, 2019, 6:14:16 PM2/7/19
to Chromium Extensions, rdcr...@google.com
"Embrace, extend, extinguish".

This used to be Microsoft's thing, but now Google has taken Microsoft's place as the Evil Empire, building trust by providing tools, and then gimping those tools that people have come to rely on.


On Sunday, January 27, 2019 at 12:23:00 PM UTC-8, Jan Biniok wrote:

Darren Govoni

unread,
Feb 7, 2019, 11:18:20 PM2/7/19
to Salem Beats, Chromium-extensions, rdcr...@google.com
The irony with this perplexing move by Google is that WEBSITES and chrome extensions are essentially the same thing. They use the same web platform as everything. So Google. Why bothering doing this at all? People use chrome to visit websites at their own caution just the same. Websites load remote code. This is how internet works.

If you want to protect the app store then you can easily just load and test each extension in a safe environment. When it loads code, then look at it. 

Stop stripping the features away for the 99% of the good users. 

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

PhistucK

unread,
Feb 8, 2019, 6:01:44 AM2/8/19
to Darren Govoni, Salem Beats, Chromium-extensions, Devlin Cronin
Not really the same thing, because extensions have additional more powerful APIs that normal websites do not have, so the damage remote scripts can do is considerably bigger.
(Not advocating that remote code should or should not be restricted, just countering your apparently mis-guided "irony")

PhistucK


Matt Collinge

unread,
Feb 8, 2019, 6:22:03 AM2/8/19
to Chromium Extensions, rdcr...@google.com
Please don't nerf Tampermonkey. It allows me to add time-saving functionality to any website I regularly visit, or where I have an issue with their UI I can easily override the CSS and present it how I want it. I'd have to seriously look at going back to Firefox.

Mohit

unread,
Feb 9, 2019, 6:27:06 AM2/9/19
to Chromium Extensions, rdcr...@google.com
I absolutely love Tampermonkey and would really hate it if all the scripts that I use were made into individual extensions thereby increasing RAM usage on my already slow laptop. I request the Chrome developer team to not go ahead with these changes.

Simon Devlin

unread,
Feb 9, 2019, 10:08:28 AM2/9/19
to Chromium Extensions, rdcr...@google.com
This is extremely disappointing.  I've dozens of scripts that I've developed that are in daily use to help automate work-day tasks.  Security improvements are to be applauded but is there no way to move to feature switch or consent option that will allow this type of extension to continue to fulfil a very useful role?  I don't want to switch to Firefox but this would certainly drive me in that direction.

VSE NN

unread,
Feb 9, 2019, 12:07:25 PM2/9/19
to Chromium Extensions, rdcr...@google.com
I think that the main Goole's goal is to put out all the possibility to block Google's ads, syndycation etc. (Google's primarily, but others too), to download video, especially from Youtube. To control all the extended functionality. It will be easy for them to block and remove all the extensions, which won't meet Google requirements and rules.

воскресенье, 27 января 2019 г., 23:23:00 UTC+3 пользователь Jan Biniok написал:
Message has been deleted

Darren Govoni

unread,
Feb 10, 2019, 8:29:40 AM2/10/19
to PhistucK, Salem Beats, Chromium-extensions, Devlin Cronin
Yes but the level of damage and the risk of it is far more widespread in web pages than extensions. Not even close.

Chris Hughes @chews

unread,
Feb 10, 2019, 2:11:57 PM2/10/19
to Chromium Extensions, rdcr...@google.com
This is a disappointing change that could easily be overcome with a change in permissions to allow this functionality to exist.
Tampermonkey derives from Greasemonkey and it was built by Aaron Boodman who later went on to work on Chrome.... is this not lost on EVERYONE here?

This type of functionality is central to how browsers should work, we as users aught to have the ability to control what runs in our browsers.

I really am disappointed by this crude security fix packaged somehow as progress.

Many thanks to the Tampermoney developers, I sure hope Google sees the err in their ways here.
-Chris

Bryce

unread,
Feb 11, 2019, 3:18:52 AM2/11/19
to Chromium Extensions, rdcr...@google.com
I use more than 20 userscripts to automate daily tasks while browsing. Switching from Tampermonkey to 20+ extensions would be too heavy a burden on my RAM and Chrome is already notoriously RAM hungry. I hope the developers don't go ahead with their planned changes to disable Tampermonkey

Tomáš Burkert

unread,
Feb 11, 2019, 3:54:36 AM2/11/19
to Chromium Extensions, rdcr...@google.com
Hi Chrome devs,

I wanted to ask you to reevaluate axing Tampermonkey too. It's extremely useful especially small tweaks and usability improvements, which can be unnecessarily cumbersome to bundle as Chrome extensions.

Thanks in advance

Alino S.

unread,
Feb 11, 2019, 6:07:00 AM2/11/19
to Chromium Extensions, rdcr...@google.com
Dear chrome devs,

Disabling Tampermonkey is going to affect me and my company and many many users. Please reconsider this.
Perhaps you could create a policy which would enable you to whitelist certain extensions like Tampermonkey or Greasemonkey to allow user scripts.
Otherwise we will need to start using alternative browsers.

Thanks

Ignat Remizov

unread,
Feb 11, 2019, 2:13:29 PM2/11/19
to Chromium Extensions, rdcr...@google.com
Dear chromium developers,

Please do not remove this useful functionality! I use various tampermonkey scripts, some I wrote myself, and use on many many many websites. Please let tapermonkey continue to live in its current form, I would be fine if there is an extra permission to agree to or a hidden flag that I would need to set. There are several other extensions I use that also may execute remote code, so this change will force me to use a different browser, and I just don't want to be forced to do that.

Thanks,
Ignat

Jim Compton

unread,
Feb 11, 2019, 3:40:31 PM2/11/19
to Chromium Extensions, rdcr...@google.com
Just to add my US$ 0.02 to the conversation: Our company uses Tampermonkey in our day-to-day operations as a way to get various real work done within a variety of web applications. Through Tampermonkey we use home-brew scripts to automate repetitive tasks, address capability gaps in the host systems, and optimize UIs (that we don't control) for the tasks that we need to perform through them.

The "homebrew" nature of this practice is crucial for us, as we share scripts, tweak them, customize them, and then trash them when we don't need them anymore-- all very rapidly. This practice enables us to keep up with the chaotic pace of the projects that we're serving and creates the opportunity for our fledgling JavaScripters to "cut their teeth" on real-world problem solving with minimum overhead. I'm concerned that we would lose these dynamics entirely if each script had to be developed and reviewed as a formal, standalone plugin on the Chrome store.

I understand the security impetus here, but in our situation, I don't see much real-world risk. All the scripts that we use are authored by our employees and hosted by us, and the end-users who run them do so deliberately.

It would be great for us if the Chromium team could find a way to address security concerns without compromising the inherently important role that TamperMonkey serves in our day-to-day operations. Thanks!

-Jim  

Kris Habraken

unread,
Feb 12, 2019, 4:50:56 AM2/12/19
to Chromium Extensions, rdcr...@google.com
Dear Chrome Devs

Please do not remove the functionality required for TamperMonkey to operate.
While I am fully in favour of making web browsing more secure in its default state, TamperMonkey is an important and easy to use tool for those looking to modify and automate websites to fit their needs, and this ability to extend the web should not be removed.

As an example, I play a game developed by Niantic, called Ingress (the precursor to Pokemon Go). Niantic puts very little resource into the Ingress 'Intel' website (a realtime global map of the game board), so over 5+ years, the community has built up hundreds of TamperMonkey scripts, both public and private, dedicated to improving the Intel website experience. These scripts transform the stock website into an something powerful enough to manage real-time competitive events (https://ingress.com/events), with dozens of Intel 'operators' coordinating in excess of 2000 players on the ground. All of this is 100% community driven, and without TamperMonkey as a platform for these scripts, these events would likely cease to be viable.
It is not feasible to package every script as an individual extension, due to the cost involved, the rapid timescale for changes to be pushed out, the interdependency and data sharing between scripts, the numerous script authors, and the requirement for some scripts to be private (script source dynamically loaded after a bootstrapper checks credentials etc).

What would be a reasonable compromise, in my view, would be to add a new permission that extensions such as TamperMonkey can require, eg 'Allows remotely hosted code'.
At install time, it should displayed prominently, with enough info to dissuade users who aren't specifically after such functionality, while allowing users who do require it, to continue to having it.

Regards
Kris

pwalker

unread,
Feb 12, 2019, 5:21:56 AM2/12/19
to Chromium Extensions, rdcr...@google.com

Implementing this change would force me to use a different browser for sure.
I don't think the benefit of this change would outweigh the damage it does to the dev extension community and all the Chrome users.

Costantino Grana

unread,
Feb 12, 2019, 6:04:30 AM2/12/19
to Chromium Extensions, rdcr...@google.com
Another community affected would be that of https://planets.nu a wonderful VGA Planets replacement. Many, many userscripts. 

On my own, if a website paginates too aggressively, I can fix it in a second with a custom userscript. If I miss a link button, I can add it as well. Making an extension is not even an option for such trivial tasks.

Best,
Costantino

SpatiumX

unread,
Feb 12, 2019, 4:56:31 PM2/12/19
to Chromium Extensions, rdcr...@google.com
Dear chromium,

I'm a daily user of Tampermonkey scripts, and this changes would negatively affect me.  Please reconsider, 

Thank you.





On Sunday, January 27, 2019 at 11:23:00 PM UTC+3, Jan Biniok wrote:

Bluep

unread,
Feb 12, 2019, 5:10:13 PM2/12/19
to Chromium Extensions
Dear devs,

please reconsider your drastic plans concerning remotely-hosted code. I'm a heavy Tampermonkey user, running a handful of userscripts on dozens of sites for my everyday work and entertainment, most of them coded by myself. Therefore I know that those are not malicious, and nobody needs to protect me from them. More precisely, everybody how tries to do that scares me away.
Please go on and enforce security, that's a good thing in the web, but make it possible to add exceptions for extensions - with a nice little warning similar to chrome://flags/
If you want to go on - the day I can't use my userscripts anymore will be the day that I uninstall Chrome.

Good luck!

Cory Novak

unread,
Feb 12, 2019, 5:55:05 PM2/12/19
to Chromium Extensions, rdcr...@google.com
I strongly oppose the dumbing down of Chrome. Enough user experience is forced upon me that making the web better has to happen, for me, in my browser with the help of userscripts. I do not want, or need more top-down decisions about what I'm supposed to use or how. Please reconsider. Tampermonkey is worthwhile and should stay usable the way it is.

pinkb...@gmail.com

unread,
Feb 13, 2019, 5:01:43 AM2/13/19
to Chromium Extensions
Dear devs, please reconsider this or allow whitelisted extensions like Tampermonkey to continue to function as intended. We use Tampermonkey across 8,000 workstations with custom scripts to automate routine and repetitive tasks. We cannot, under any circumstances, make this code available in the webstore as it would expose valuable intellectual property to competitors. If this goes ahead we will have no option but to change our SOE to Firefox and Greasemonkey. We may also issue a statement to the tech media stating why we had no option but to ditch Chrome. I don't want to say at this stage which company I am talking about, but it's one most people in the tech industry would know.

Please consider one of the following options:
1) Ditch this plan entirely.
2) Whitelist extensions such as Tampermonkey to allow running userscripts.
3) Provide advanced settings and whatever warnings are deemed necessary to allow running userscripts.

Andrew Stott

unread,
Feb 13, 2019, 7:03:41 AM2/13/19