Manifest V3: Remotely-Hosted Code and Tampermonkey

[Jan Biniok]

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]

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

[零欸特]

I also wonder if this will affect userstyle managers like Stylus:

https://chrome.google.com/webstore/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne

>  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]

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]

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]

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]

How do you publish these customized extensions?

I don't, the users can publish it themselves, use in dev-mode, etc. 

[Charles Haynes]

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]

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]

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]

This affects tampermonkey right? 

[Hachirama Ngainmall]

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

[Darren Govoni]

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/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/e1e0d4c6-c50b-4881-9a2d-69afdc7da273%40chromium.org.

[Sergio _]

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]

I'm a daily user of Tampermonkey scripts, and this change would force me to switch to Firefox.  Please reconsider this.

[Kaden Mansius]

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]

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]

"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]

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/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/2f7ed919-b7b6-4676-ab65-47a97e2c8f6a%40chromium.org.

[PhistucK]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAN-ZBUdKu8FPox5cppM-AaKyfuujjwSRXTm7mpw%3DTNuJrMA%2BMA%40mail.gmail.com.

[Matt Collinge]

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]

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]

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]

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 написал:

[Darren Govoni]

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]

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]

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]

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.]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

I use small Tampermonkey scripts to meet my accessibility needs, including selectively changing font sizes and enabling keyboard shortcuts. As I understand the loss of functionality this would make some websites much more difficult to use. 

In addition I use Tampermonkey to overcome flaws in certain websites and services - including Google Bookmarks (where recently, for a number of months, there was a faulty release and there was a community developed Tampermonkey script to overcome it). 

For my main use cases an alternative approach of strict sandboxing of external scripts so that they could just alter the DOM and intercept local events, and not import scripts or other information from the network nor send information out, would be OK, although I expect that that would not meet the needs of other Tampermonkey users who have commented here.

It might also be worth considering using more explicit whitelisting/blacklisting to improve control. For instance, for security I have blacklisted sensitive sites in Tampermonkey itself so no script could operate on them, and this could be achieved from within Chrome itself.

[Clint Priest]

I've been a long time user of Tampermonkey and it's predecessor, I also write full-blown extensions.  Tampermonkey is invaluable to me for the ability to quickly make some changes to a specific website or to change the behavior of all websites for specific needs.

In addition it gives access to hundreds or thousands of people who know 'a little javascript' to customize their experience, opportunities which they would pass on if they had to learn how to write an entire extension, publish it and go through the hassle of dealing with all that comes with writing and publishing an extension.

Personally, I even use Tampermonkey to quickly prototype and test new extension ideas.  It would be sorely missed, and I too would begin looking for another solution somewhere.

The community of userscript developers has also been taking on the challenge of code security to help protect users, given more time (and perhaps resources), these simple little scripts could be scanned for issues and warn users, etc.

Being a developer of over 20 years, I think the v3 Draft limitations which would disable TamperMonkey completely is a mistake.  Perhaps there is another way to achieve your v3 goals without disabling extensions.

[tm developer]

I am both a user and developer. It you remove the ability to use userscripts, not only would I have to switch browsers, but I would actively encourage others to do so, so they could continue using my scripts. 

Userscripts have been a mainstay of web browsing since at least Firefox 2, before Chrome was even conceived. They allow small fixes that extensions are overkill for. 

These scripts are intentionally limited in their abilities. The vast majority run entirely in a website's content scope. Some do use certain extended APIs, but most of these are low risk. The only one I can think of being a problem is being able to make a cross-origin HTTP request. However, these require confirmation from the user at install time, and even further if broad premissions are sought.

Userscripts are not a widely known malware vector, either. They cannot be added without the user's permission due to current security practices in both Tampermonkey and Chrome. If a site tries to install a userscript, the user must confirm the script in a rather scary looking dialog. And modifying Tampermonkey's storage from outside of Chrome would invalidate the signing. 

Removing userscripts nets at most a minor security increase for a large usability decrease. It is not just power users that use userscripts, any more than only power users use Adblock. 

There is a reason why, when Firefox changed models, it was made imperative that userscript engines would still work, to the point that Firefox has actually added special userscript APIs to help GreaseMonkey work in as secure a manner as possible, putting its scripts in proper sandboxes. 

It is extremely important to developers and users alike that userscripts remain viable in a modern web browser. 

[Владислав Большаков]

Well.
There is only 2 reasons for me, as a regular user to stay with chrome:
1. Extensions like Tampermonkey, uBlock, etc. 8/10 extensions I'm using right now DO use " remotely-hosted code" in one way or another.
2. Account data syncronisation. 
  Now this one is kinda.... well. Let's just say that chrome is not the only browser that has that feature right now.

Right now - chrome on it's own has waaaay to many security issues. ex - "Seeker" on github. Currently even if the user on google chrome would NOT give the script any permissions - some data (OS version, GPU, screen resoulution,...) would still be send to the host.

Also keeping in mind the fact that after each update chrome uses more and more ram (tested on 3 different PC) this change would be the last straw. There would be no reason for me to keep using that browser.

[Andrea M]

I'm using Tampermonkey on daily basis to automate my work on many websites. Some scripts are just too simple to turn into a standalone extension as it would pollute the extension ecosystem. If this change lands I will move to Firefox.

[Darren Govoni]

I noticed that Firefox has a similar policy in place but you can override it in the manifest which I presume takes the reasonable and logical action of informing the user - who, in my opinion, should retain complete control over their environment and risks therein unless it is controlled by  trusted internal enterprise group policy (not outside for profit company).

Fyi.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy#Location_of_script_and_object_resources

--

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/5e601757-1b1e-4e08-9276-9146102ea61e%40chromium.org.

[gigit...@gmail.com]

I have developed dozens of Tampermonkey scripts over years, which help me better use information on websites.

Calculating and displaying the total price per night (including taxes and fees) of a hotel on booking sites (which tend to obfuscate this exact information so to make the price appear cheaper) is just one tiny example.

Highlighting keywords which are important to me in reviews so I don't have to read through hundreds of review paragraphs and I can just scroll to my highlighted words is just another small example.

Being unable to do these things makes Chrome extremely limiting and *sadly*, it would no longer be a wise choice to use this particular browser if I am no longer able to have these useful functionalities I created to make my daily online life much easier.

I believe that the Chrome community will lose many valuable members as a result of such a limiting move, and it's a shame.

There are countless ways to implement the added security without banning the functionality of running personal scripts through extensions like Tampermonkey altogether.

I hope Google doesn't throw the baby out with the bath water while hardening security according to the new manifest.

Thank you for your consideration,

Gigi

[Oliver Peplowski]

Is it possible to have extensions (like Tampermonkey) stll have the option to run remotely-stored code? People in this thread were referring to a startup flag. I was wondering if an option could be made to:

- Create a startup flag (aka "extension-whitelist") which allows for remote code execution

- Create a whitelist, which specifies that [extension-1], [extension-2], etc... are the only extensions allowed, along with some type of cryptographic signature to authenticate the list

- etc...

That way, people have to explicitly enter a flag, and add extensions to a custom list.

Going this far into "securing a browser" is a honorable cause, but there has to be an out, other than using a dev- style flag. I don't think power users are asking for a barn door to be blown off the hinges, but more of a window that can be opened by power users, who are reminded that the window is open. This somewhat reeks of a heavy-handed UAC, and even the Microsoft Windows team backed off from that option (to an extent).

Thank you,

Oliver

[Álvaro]

There's no real benefit in strip this functionality from the browser. A 'vanilla' user certainly never tampered with those codes, therefore removing it for safety (presumably, of the average joe)  is a weak excuse. A decision like that will reap several utilities that the native browser does not offer and probably never will. A substantial migration to competitors should follow.

[James B]

There are an awful lot of "me too" posts in this thread.  Can we get some feedback from the Google team on whether or not this is helpful?  I think by now it's abundantly clear that there are a lot of people who use Tampermonkey and that it's very important to them, critical to their business, would cause them to switch browsers if disabled, etc etc.  I would guess we have enough reports of that nature by now that the Googlers working on Manifest v3 have the information they need to make an informed decision.

It's not helpful to take a negative tone, threaten to quit Chrome, etc.  It's also not helpful to pretend that this is a sinister plot to hurt users or developers.  It's not helpful to pretend that there's no security threat, or that the proposed changes to block dynamic/remote code have no potential to improve end-user security.  There *are* extensions out there that pass the web store review process then download malicious code; there *are* such things as malicious userscripts that run in TM/GM.  The only useful discussion is whether (and if so, how) to limit or eliminate the ability of extensions to do this.

Let's keep the discussion constructive, please.

V/R

James

[wOxxOm]

So far we don't know for sure whether any discussion is fruitful since we see no feedback from Google except for the vague deflections about this plan being a draft. People have seen enough of such PR stunts from big corporations and no longer trust them by default so it's only natural that the lack of info is perceived as suspicious. Regarding negativity, I'd say people are just stating the obvious as it's not a threat to say one wouldn't be able to use the browser. Also let's not exaggerate. 99% of the feedback here is either a description of use cases or of another possible solution(s).

Just because there are malicious extensions that abuse the API it doesn't mean all extensions and their users should suffer. Again, let's not overreact, otherwise with this approach you would forbid people to use their hands or brains or speech or knives as they can harm other people by abusing those. There are several good suggestions in this thread that could be implemented instead of destroying the entire ecosystem.

[Radiant One]

Well put. And to James preach platitudes about what is and is not helpful. This change isn't a light matter. Businesses and productivity of many will be ruined by the occasional malware. People should speak up with the intensity this deserves. Criticizing how people express themselves and soap boxing us how to do it is off topic.

Back to the topic. This is a classic case of blaming the tool. It should be easy enough for Google and indeed the community at large to police extensions for malware and then black flag them. Sure a few might get caught in the net at first but sparing the 99% of us from the alternative makes that a no brainer.

Instead of throwing your arms up Google be creative. Define a community policing protocol. Engage us to help build a solution. You might even find people will be extensions to monitor for malware. 

But if you throw out user discretion, community and public blacklisting, app store review sandbox (actually using the extension and monitoring code), and ignore internally hosted group policy protocols which deploy in house extensions. Then that's a complete fail.

You're using a sledgehammer when a scalpel is needed. Provide a solution that let's the community fill in the gaps. But we need options in the manifest to do this. 

--

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/01be7a67-8ac8-456d-bf82-f5b49318a604%40chromium.org.

[James B]

To be clear, I wasn't saying all that to defend the V3 proposed changes, I just wanted to make sure that the discussion here could at least potentially be useful to the team working on it.

I personally think that remote code use should be its own manifest permission, and that its use should be treated with extreme caution.  Maybe that means that using the permission requires additional review before the extension is listed on the web store.  Maybe it requires extra user prompting before install (though of course, we all know that Users Don't Read), and/or periodic reminders that hey, this extension can basically do anything to any page at any time.  Google can throw its UX PhDs at the problem of getting it through users' skulls that they are installing a huge gun with which to shoot themselves in the foot.  But I absolutely agree that they should not remove that capability entirely.

As for Radiant's comment about "preaching", I hope my previous message wasn't taken as a personal attack by anyone.  I just saw multiple posts per day coming through making basically the same argument (don't break this, it's too useful) without addressing the other side of the argument.  There's a security tradeoff being made, which has to be taken into account.  You're not going to get anywhere suggesting that they change nothing.


V/R

James

[Darren Govoni]

Those are some good ideas James. This is what Google should be proposing. A solution that accommodates the 99% use case while addressing the concerns of the 1% exceptions. Not removal due to lack of proper solution.

--

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/b2c917c1-47e4-4379-8148-28afdc1053e3%40chromium.org.

[Chang Yao]

I think most developer using TemperMonkey for small automation tools development like me. Which makes the browser more 'intelligent' for developers. Restriction of such function is lose more than gain.

[Steve Horne]

Please at least allow a developer option that will enable external scripts.  Taking away Tampermonkey would be a big loss of functionality for me that I don't think I can get any other way.  I can't afford to write chrome extensions every time I need to script something.

[momonga sama]

First official response - https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/WcZ42Iqon_M 

No mention of remote code or anything related to that.

[tm developer]

I don't think framing this as a power user issue is the best idea. While I am a power user, many of those who use my scripts are not. And most people will assume "power user" means a small fraction of users, when userscript use is actually fairly high. 

Power users can download dev versions (like we already can to use unsigned extensions). Power users can mess with convoluted settings. These aren't really practical for the normal user, and still greatly reduces the ability to make small userscripts.

I think the better focus is on showing how userscripts on their own aren't that large a threat. Those that run in the web content space are no more a threat than bookmarklets, which still work. The big risk is logging data and sending it somewhere, but you can only do that if you can cross site boundaries, which are disabled by default in TM. 

I'd actually like to know how big the usage of scripts that grant GM_xmlHttpRequest even are: it may be that we could do without those, having those turned into extensions but not other scripts.  

[Andrew Stott]

Building on the thoughts in tm-developer's post, is there some middle ground between the need to tighten security and the continued support of the most common use cases?

• the proposal is to prohibit the extension executing code not in the extension itself. But would a distinction between locally hosted code outside the extension and remotely hosted code outside the extension help? - in essence making Tampermonkey and similar extensions a simpler way of executing local code than switching on developer mode and having an unsigned extension? If an attacker can install code locally they'll surely go after the treasure directly rather than waiting for Tampermonkey to execute code. The alternative of having large numbers of non-developer users turn on developer mode and install unsigned extensions is not attractive.
• are there capabilities that could be disabled within Chrome itself (rather than just disabled by default in Tampermonkey) that reduced the risks, albeit with effects on some high-end use cases? 
• are there functions within Tampermonkey that could be elevated to within Chrome itself, so that extensions that need to use them could do so in a controlled way rather than grant privileges potentially to all extensions (with the code review etc overhead)

On Tuesday, 19 February 2019 13:13:57 UTC, tm developer wrote:

...

Power users can download dev versions (like we already can to use unsigned extensions). ...  These aren't really practical for the normal user, and still greatly reduces the ability to make small userscripts.

[Dylan Barrell]

We develop a set of extensions used by organizations to audit their Web applications for accessibility issues. The changes that have been proposed impact our ability to allow our customers to augment the audits with their own rules

This really impacts our business and the ability of these organizations to give their developers the tools they need to effectively provide accessible applications. In addition, the other changes represent a bunch of busy work for us to refactor our extensions to fit the new interaction model for seemingly no real benefit. What is the explicit benefit of getting rid of the background page for example?

There seems to be conflicting information as to whether remote code execution will be completely disabled or simply a new, more vigorously enforced permission. Which is it to be?

[Dylan Pearson]

I consider myself an intermediate user of chrome. I like the flexibility that is available for me to customize how I use chrome.

I don't like the idea of always ruining chrome in dev mode, so I would like to see an option for controlling security levels and I have a few ideas on on how it could be implemented.

1. add a medium security mode where you can choose to open a site in a new semi-secure tab. implemented similar to incognito where there is visual indicators that the tab you are in is not the standard. allowing users to add and configure extensions similar to what we can currently.
   
2. offer a per extension extended permission with advanced control over what the extension can and can't do. eg. control permission for the extension to:
   
• permissions to load data from specific site/domain or any source **unsafe
  
• permissions for local storage access
• permissions to access account information
• etc.
3. even better would be solution which allows custom sets of extensions that have more flexibility.
   I would envision this as a drop down menu which allows re-loading the page using a different set of extensions and an icon/color that visually indicates which profile is in use. This would also help a lot with the situation where I often have so many extension active that I can't see half of them and some even conflict with each-other. it might even have possibility for people to save and share the extension sets (like we used to be able to do in the past, or was that only a Firefox thing??)
   eg:
• Max Security profile: only google verified extensions which conform to high security standards.
• default out of the box profile which has high security levels recommended by google and allows community verified extensions.
  
• custom user defined profiles with their own security levels/permissions and different sets of extensions.
• my game profile - where I might have a medium security level and extensions which relate to games that I play. 
  
• my testing profile - where I might have low security level and extensions like Tampermonkey and other dev extensions that let me test and learn.. perhaps option to ask for confirmation when site or extension sends requests that access personal information or edit personal files etc.
• my reading profile - where I might have bookmarking and readability extensions
• my apps profile - where I would have extensions for working with google drive and other apps
• my social profile - where I might have extensions for google, Facebook, Twitter, digg and other social plugins.
• my productivity profile - where I set high security and only a few extensions which help with tasks/emails/docs and ones which remove distractions.