Questions re: chrome.userScripts documentation

[Brenton Partridge]

Very excited to see the development of the userScripts API - it was one of the key gaps of MV3, and it opens up incredible possibilities for users to customize their browser experience.

That said - and I understand things are in progress - the documentation on https://developer.chrome.com/docs/extensions/reference/userScripts/ could use more information about what capabilities the various execution worlds have.

I came across this proposal https://github.com/w3c/webextensions/blob/main/proposals/user-scripts-api.md#user_script-world but I'm not sure if the details there are still valid in this implementation. Namely:

- can a userscript in the USER_SCRIPT world do window.postMessage and have it seen by a userscript in the MAIN world, and vice versa?

- do both worlds share the same DOM?

- if configureWorld({messaging: true}) does that mean that both MAIN and USER_SCRIPT world userscripts can call runtime.sendMessage?

- will a script running in the USER_SCRIPT world have the ability to access fetch, XHR APIs, etc. to access remote content (subject to whatever connect-src CSP is specified in configureWorld)?

- if configureWorld sets an 'unsafe-eval' CSP, can scripts in the USER_SCRIPT world use eval()?

More generally, bringing a bunch of the rationale from that proposal into the documentation could go a long way towards clarifying how the API should be used.

Looking forward to seeing this go live in Chrome 120, and getting clarity on the capabilities!

[wOxxOm]

Indeed it would be helpful to clarify all these points in the documentation.

> can a userscript in the USER_SCRIPT world do window.postMessage and have it seen by a userscript in the MAIN world, and vice versa?

Yes, because this is not what gets isolated per world: only JS variables/functions/expandos are isolated.

Note that using window.postMessage is generally a bad idea here because you can break a site that's using this mechanism with data of a certain shape. You should use it only to cooperate with a site's onmessage listener intentionally or when your extension targets a specific site which you can test for compatibility, otherwise it's safer to use CustomEvent to transfer structured-clone-compatible objects or MouseEvent + relatedNode to transfer DOM nodes. The id of the event should be random ideally if you want to reduce the risk of collisions, chrome.runtime.id might work as well in the non-MAIN worlds (in the MAIN world you can pass it via args in executeScript).

> do both worlds share the same DOM?

Yes, world separation works the same as for the default (ISOLATED) content scripts vs page scripts: everything except JS stuff is shared, like the standard DOM properties (i.e. not JS expandos), timer ids, RAF ids, events, etc.

> if configureWorld({messaging: true}) does that mean that both MAIN and USER_SCRIPT world userscripts can call runtime.sendMessage?

configureWorld is only for USER_SCRIPT world.

In the MAIN world it's available when at least one extension's externally_connectable matches the document's URL.

> will a script running in the USER_SCRIPT world have the ability to access fetch, XHR APIs, etc. to access remote content (subject to whatever connect-src CSP is specified in configureWorld)?

Guess it should be impossible, the same as in the default ISOLATED world, because CORB enforcement for content scripts doesn't depend on the internal CSP for content scripts.

> if configureWorld sets an 'unsafe-eval' CSP, can scripts in the USER_SCRIPT world use eval()?

Guess it should be possible as the USER_SCRIPT world was designed to allow running arbitrary code strings.

> Looking forward to seeing this go live in Chrome 120

It's already live in Chrome Canary, it uses a separate user profile, so you can install it safely.

There are also non-optimized and buggier trunk snapshots of Chromium released every several hours.

[Pavel Aronovich]

Developer mode is still needed if the extension is installed by the ExtensionSettings policy?

Usually in companies, the developer mode is prohibited by policy!

суббота, 18 ноября 2023 г. в 00:29:55 UTC+3, wOxxOm:

[wOxxOm]

Yes, and there are more problems:

• The devmode switch also enables other features e.g. chrome.declarativeNetRequest.onRuleMatchedDebug which may severely reduce the performance of the content blocking extensions, depending on how it's used.
  
  
• The users won't know that they need to enable the devmode switch unless the extension says it, so every such extension will have to waste translation team effort to present the explanation in multiple languages.
  
  
• There's no global indication in the browser for whether devmode is enabled, so people may have enabled it to test something out and then forgot to disable it, which leaves them vulnerable to accidentally installing a malicious extension that has "userScripts" permission among others, e.g. many extension developers have devmode switch constantly enabled. The only workaround is user-unfriendly: ExtensionSettings policy with blocked_permissions for "*" and allowed_permissions for the individual extensions.

Overall, the devmode switch is a no go in the long term, it's conceptually the same as chrome://flags/#enable-experimental-web-platform-features, which is only for testers of the new features, so hopefully a proper solution will be implemented once userScripts API graduates from this experimental stage. What about a dedicated option in the extension's icon context menu like "Allow running userScripts" when the extension has "userScripts" permission maybe even with an additional indicator?

[Joe Floe]

I second that Developer mode will be an issue for customers of our extension, because of policies restrictions.

Is it posible to review this requirement from Chromium side?

[Stryder Crown]

Additional questions re: Developer mode;

If a user enables developer mode, is that enabled for all extensions or only ones the user trusts?  Not trying to overly criticize, but it seems short-sighted to create a security restriction like this due to concerns about malicious extensions only to make it an 'All or Nothing' setting. i.e. a user might know they can trust extension A, but requiring them to sacrifice a measure of protection against all extensions for one they know is safe makes a user not only less secure, but also puts developers who might otherwise be building Good Things at a significant disadvantage. I don't want my users entire security profile to be compromised just because I utilize this One Weird Trick that they love. Putting me in that position means my users have to decide between my Awesome Extension and their potential security.

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/36c73692-5adf-4cb7-9b6e-cecfad4e41den%40chromium.org.

[Seema Habib]

Okay 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CADq%3D7qv1uucav2_J0Sd13oSiT01Qo72afVKX6VYFyvuxMOeOtg%40mail.gmail.com.

[Oliver Dunk]

If a user enables developer mode, is that enabled for all extensions or only ones the user trusts?

Yes, developer mode is a global setting which applies to all extensions. There's definitely a tradeoff here as you say.

As a general note, I just wanted to say that we've been keeping an eye on feedback, including everything in this thread. We'll continue to discuss it internally, we certainly want to spend more time on the User Scripts API over the next few months :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[hrg...@gmail.com]

May I ask what is the motivation for having two user-authorization mechanisms (the userScripts permission and the developer mode checkbox) behind the userScripts API?

Why is the userScripts permission not enough authorization?

[Kamt Schatka]

We are also developing an extension that is rolled out by most of our customers using registry keys. They can't require users to manually enable developer mode, for them it is often a legal requirement to have it enabled on their users machines.

[Oliver Dunk]

May I ask what is the motivation for having two user-authorization mechanisms (the userScripts permission and the developer mode checkbox) behind the userScripts API? Why is the userScripts permission not enough authorization?

The `userScripts` permission doesn't currently have an associated warning, so it isn't presented to users at install time. Instead, we rely on host permissions (which is similar to what we do in the `scripting` API for example). Host permissions are used for lots of other things, though, so it felt like additional steps were needed to reduce the chance this feature is used by a user that doesn't fully understand the risks.

There's definitely a lot of discussion here, and I agree with some of the concerns which I'll definitely raise with the team, but that's the context behind what we have now :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[hrg...@gmail.com]

I see.

It really looks like that mechanism for user approval could be improved.

Id like to suggest the following idea:

1. Make the userScripts permission strictly optional. i.e. it cannot be asked at install time, only after installation.
2. Require that the userScripts permission can only be asked alone, not as part of a group
3. Give the userScripts permission its own warning
4. Eliminate the "Developer mode" requirement

RATIONALE:

Asking the userScripts permission after installation forces the user to pay attention to the request; whereas asking the permission at install-time as part of a set of permissions is easily overlooked because users tend to accept any install-time dialogs without much hesitation.

If the userScripts permission has its own dialog box which shows up once the user opens the options page, then this permission request cannot be overlooked. The user is forced to read the dialog box and approve the userScripts permission explicitly. And, therefore, there's no need for the "Developer mode" requirement.

[Pavel Aronovich]

If the extension is installed by policy, then you do not need to require anything additional for userScripts to work.

понедельник, 27 ноября 2023 г. в 20:32:43 UTC+3, hrg...@gmail.com:

[Joe Floe]

We have an extension that may be used in --headless=new mode for running automated test (chrome profile is created from scratch for each test), and we want to use userScript API there. 

How may we achieve this goal, givent that enabling Developer Mode requires manual interaction?

[wOxxOm]

>  --headless=new mode

If the automation driver allows setting options, 1) set "extensions.ui.developer_mode" to true.

Otherwise 2) use "master_preferences" file or 3) patch the Preferences file in the user data directory or 4) navigate to chrome://extensions and click() the switch element.

[Lionel Rowe]

At my company, we maintain a number of userscripts to provide various functionality to users both inside and outside of our organization (so any workaround that requires setting enterprise-level policies won't work for us). Requiring developer mode would place a significant burden on adoption, as most of the users are non-technical. I'd support a change making user-script permissions prompts more explicit and intuitive for users to understand the risks, but requiring developer mode is really a non-starter from our point of view.

[nascent]

As Lionel,  we use TamperMonkey at work, and forcing dependency on developer mode would mean we can no longer use it. That'd be devastating for us.

[Oliver Dunk]

I appreciate all of the feedback here. We're continuing to pass it on to the engineering and product teams.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Henrik Jensen]

Forcing a global state to manage a local problem is just bad design. Please don't do there.

[Christian Walde (Mithaldu)]

Warning users is a good thing. Locking users out of a feature they may have very intentionally chosen is just harmful.

This feels like a problem was identified and then the first and most simple solution chosen with zero consideration of effects on users.

[Cassie Conger]

I can't even find how to enable developer mode! I rely on Tampermonkey! I've searched... I've gone through every page of settings... if we can't easily figure out how to set it to developer mode, how are we supposed to be able to continue using an extension we have come to rely on? You need to put something about developer mode so it can be searched at the VERY least... but it doesn't make sense that something so obscure is going to be required. Not everyone is tech savvy. I had to have someone talk me through Tampermonkey. It's like you don't care if we get to use what we've downloaded. 

[Patrick Kettner]

Hi Cassie,

You can enable developer mode by going to chrome://extensions. There is a toggle in the upper right corner of the page. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8b8081b6-aed2-44fb-b0cf-3178b2af472bn%40chromium.org.

[Deco]

So I have been following this thread with relative interest due to the ramifications that it has on end user points.

Due to the privilege that the userScripts is naturally inheriting I understand the rationale behind having it enabled by the Developer mode only for the prototype stage, however when deployed this results in a anti-pattern for even considering to be used at all for this restriction. 

I think Cassie's overall point is the restriction is far too severe to even consider the potential to use it to begin with, which I agree with.

The developer mode was primarily made for loading unsigned extensions and has never in memory that I can recall been used for permission escalation directly. 

This check assumes that the user themselves is a "developer", and if stuck to presents a lot more danger than may initially meet the eye, in the pursuit of attempting to stop malicious executions, it is actually making it easier by exposing the ability to do to begin with.

The dependency has to be removed, the user prompt for permission acceptance should be used for this, not having to switch on a manual toggle for this behaviour to function.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAPAuxoDXvBaTeC0zTjSitQfgS1WA-B8jDR_xSTv%3DBneCBY7ESA%40mail.gmail.com.

[Patrick Kettner]

I just wanted to say I really appreciate the feedback, and it is absolutely something the team is taking into account and discussing.

[Cassie Conger]

You never helped me... I don't know where to turn it on in BRAVE

[Patrick Kettner]

Hi Cassie,

Apologies, I wasn't aware you were using Brave. The same steps are true, just using brave://extensions rather than chrome://extensions.

[Kamt Schatka]

Is it a fact that you do not need developer mode if it is installed by policy, or is that wishful thinking?

On Tuesday, November 28, 2023 at 11:09:10 AM UTC+1 Pavel Aronovich wrote:

[Oliver Dunk]

Hi Kamt,

There isn't currently an exception for policy-installed extensions.

If you have a strong use case, I'd love to hear. This isn't something we are necessarily against but just something we haven't implemented yet.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[wOxxOm]

The requirement itself should be removed altogether for a variety of reasons explained by multiple developers. Chrome team hasn't provided any coherent answer to those arguments yet.

[Kamt Schatka]

I have already provided my use case before:

"We are also developing an extension that is rolled out by most of our customers using registry keys. They can't require users to manually enable developer mode, for them it is often a legal requirement to have it enabled on their users machines."

I was just reacting to the message by "Pavel Aronovich" wo claims "If the extension is installed by policy, then you do not need to require anything additional for userScripts to work."

TBH this communication is a complete mess up to now. We received an update on the google store policy on Saturday that the policy has changed to make the use of external code possible again (via debugger API and userscript API), but at this point, the UserScript API is completely unusable due to the requirement to have the developer mode active. This is not something that works with policies and this is not something that works reasonably well for end users. 

The end of MV2 is only months away and we still have to deal with this huge uncertainty. I would really expect more from a huge company like google, but obviously I was mistaken.

[Oliver Dunk]

I was just reacting to the message by "Pavel Aronovich" who claims "If the extension is installed by policy, then you do not need to require anything additional for userScripts to work."

This is something we've discussed, but right now I believe you do need to manually enable developer mode in all cases. I'll follow-up with the team on policy installed extensions to see if we are still open to changes there.

TBH this communication is a complete mess up to now. We received an update on the google store policy on Saturday that the policy has changed to make the use of external code possible again (via debugger API and userscript API), but at this point, the UserScript API is completely unusable due to the requirement to have the developer mode active. This is not something that works with policies and this is not something that works reasonably well for end users.

Would you be able to clarify your concern with the policy change? In practice, we have always allowed Remote Hosted Code with the User Scripts API - this policy update was simply to reflect that and make sure our policy was in line with what we were enforcing in practice. The hope is to try and make things as clear as possible. I appreciate that needing to enable the developer mode toggle does not work for your use case - as mentioned, that is definitely something I appreciate and hope we can solve.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Kamt Schatka]

No concern regarding the update, I was just assuming that if you send out such an update for something that was known to developers for some time now, that there would actually be solutions to the concerns people have been voicing since the introduction of this move to MV3 (years ago). But nothing has changed, people are left hanging and it is now mid April, when this change is rolling out starting in June.

[hrg...@gmail.com]

Given that you deploy your extension using the registry, you have the option to enable the ExtensionManifestV2Availability policy which will keep MV2 support until June 2025. Hopefully that will be enough time for the various MV3 annoyances to be solved by then.

[Ximing Chen]

With only a few months left until end users are disabled with the MV2 extension, why hasn’t this issue been fixed yet?

[Oliver Dunk]

Hi Ximing,

Did you have a specific concern?

We know there is still feedback around policy installed extensions, but there is a policy available to extend MV2 support for an additional year.

We're also keeping in mind the feedback around the developer mode requirement. This shouldn't stop anyone from using the API in the meantime, but I'm certainly hopeful that we can make some changes based on it. Patrick and I are continuing to pass along this feedback and if there are any updates we'll be sure to share them.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Valve]

I'm finding the docs out of date or not clear right now. The `matches` property is listed as optional, but Chrome keeps saying it's required. The `includeGlobs` property feels like it does nothing or I'm just not sure how to use it.

[Oliver Dunk]

Hi,

`matches` is listed as optional since we re-use this type across API calls. It is required for a call to register(). It does look like we have an issue with a reference there so I will look at fixing that.

Could you share what you have tried with globs that isn't working?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Victor Alvelais]

Hi Oliver,

Thanks for the clarification. As far as globs, I'm trying to resolve legacy userscripts. Some of the @include params target openly like `*groups*` so that the script runs on domains like groups.google.com but not others. I'm assuming since matches is required that I can match for google.com, then use includeGlobs to only match the `groups` URLs. Please correct me if I'm wrong, but my test scripts run on all the google.com URLs instead of the groups filter as I expect.

[Oliver Dunk]

Hi both,

As far as globs, I'm trying to resolve legacy userscripts. Some of the @include params target openly like `*groups*` so that the script runs on domains like groups.google.com but not others. I'm assuming since matches is required that I can match for google.com, then use includeGlobs to only match the `groups` URLs. Please correct me if I'm wrong, but my test scripts run on all the google.com URLs instead of the groups filter as I expect.

For the User Scripts API, we intentionally deviated from content scripts and `matches` and `includeGlobs` are additive: https://github.com/w3c/webextensions/issues/279#issuecomment-1311037536

However, I do think for the reasons you mention requiring `matches` to be present is an unhelpful limitation. I found a related bug and tagged one of our engineers: https://issues.chromium.org/u/1/issues/41483539#comment11

Are we expected to use chrome.alarms to poll every 30s until developer mode is enabled, then show the quick start guide?

Could you clarify why your onboarding isn't able to open if developer mode is disabled? Our suggested approach is similar to what you mention, to immediately open onboarding on install and then poll if user scripts are available: https://developer.chrome.com/docs/extensions/reference/api/userScripts#developer_mode_for_extension_users

I know this is tricky and we're continuing to talk about the developer mode requirement internally :) 

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

On Fri, May 17, 2024 at 10:18 PM Tom Doan <thd...@gmail.com> wrote:

How are you guys handling opening the quick start guide when the extension requires developer mode? Usually, we'd launch the quick start guide from chrome.runtime.onInstalled, but if the user doesn't have developer mode mode enabled when installing the extension, the quick start guide never opens.

Are we expected to use chrome.alarms to poll every 30s until developer mode is enabled, then show the quick start guide?

[wOxxOm]

>  I know this is tricky and we're continuing to talk about the developer mode requirement internally :) 

"tricky" is an understatement that has a very deceptive connotation as though it takes some kind of exceptional skill to master this super advanced feature. For something that has so many inherent problems as multiple developers pointed out a better description would be weird, awkward, wayward, counter-intuitive, confusing.

[Tom Doan]

FYI I am using the same codebase for the Firefox version and there is no such silly requirement as enabling developer mode when certain APIs are used (I don't think Firefox even has a developer mode toggle switch), and this has been working out fine afaik.

[hrg...@gmail.com]

>  I know this is tricky and we're continuing to talk about the developer mode requirement internally :) 

"tricky" is an understatement that has a very deceptive connotation as though it takes some kind of exceptional skill to master this super advanced feature. For something that has so many inherent problems as multiple developers pointed out a better description would be weird, awkward, wayward, counter-intuitive, confusing.

I would just call it a bad solution.

A solution that affects all extensions simultaneously is a bad solution.

A solution that is coupled with an entirely separate functionality is a bad solution.

A solution that forces the user to leave the current UI flow is a bad solution.

A proper solution is one that:

1. Works on a per-extension basis.
2. Is not coupled with unrelated settings.
3. Doesn't have side effects.
4. Can be integrated in the extension's own GUI (such as a popup dialog box).

I've mentioned before in this forum that we should never underestimate the capacity of the Extensions Team to surprise us with their "create solutions".

With this one they have excelled themselves.

[Pavel Aronovich]

+1000

Enabling Developer mode is not possible in a corporate environment. This requirement is absurd.

вторник, 21 мая 2024 г. в 07:31:39 UTC+3, hrg...@gmail.com:

[Oliver Dunk]

As I mentioned, we're very open to changes. I do want to set honest expectations - I expect we'll be able to address a lot of the feedback here (like coupling unrelated settings). At the same time, we may not have a fully in extension flow, as we do want some friction that reduces the risk of a user simply accepting a dialog without understanding what it means.

Enabling Developer mode is not possible in a corporate environment. This requirement is absurd.

Enterprise is definitely a unique environment and I do think we might not want the developer mode requirement there. I want to avoid shipping a solution that only works for enterprise and doesn't help everyone else, though. Since policy-installed extensions have until June 2025 using the ExtensionManifestV2Availability policy, there's still some time to figure this out.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[wOxxOm]

> we do want some friction that reduces the risk of a user simply accepting a dialog without understanding what it means.

The current solution increases the risk because it uses an entirely unrelated switch. A number of much more reasonable alternatives were suggested in this group.

  > As I mentioned, we're very open to changes.

Currently the only reaction we see is no reaction. It's basically the same thing you did when you initially promised to close the gap between webRequestBlocking and DNR, then you waited for a few years and simply redefined the gap to a few cherry-picked problems, dismissing everything else as insignificant. Just like you didn't substantiate your decision back then, you also don't explain why you keep the highly problematic requirement in place now, which shows you're neither open nor reasonable.

[wOxxOm]

If chromium team consider userscripts to be a feature for power users, I'd argue it's the wrong idea and roughly half of the users are casual gamers.

[Tom Doan]

If Google's goal was to increase friction, then congrats they succeeded. This has created more than one type of friction: this has turned out to be a custom support nightmare, and I'm not alone. Case in point:

https://github.com/Tampermonkey/tampermonkey/issues/2018

I had to do something similar just to avoid a flood of one-star reviews from casual users who don't realize they needed to enable developer mode. Even adding a FAQ entry & popup instructions, some customers are still confused. I think the end result is increased confusion, which proves that a lot of people who depend on user scripts are not techies.

[Brook Hong]

I just found some error is being raised when calling `chrome.runtime.sendMessage` from USER_SCRIPT even with `messaging` enabled with below code.

    chrome.userScripts.configureWorld({
          messaging: true
    });

The error is `Error: Could not establish connection. Receiving end does not exist.` Is there anyone here succeed to sendMessage in USER_SCRIPT?

And yes, the requirement of developer mode to use the userScripts API is truly absurd to me.

[Oliver Dunk]

Do you have a listener for the corresponding onUserScriptMessage event?

We split things up to make sure a user script isn't able to invoke message handlers intended from other parts of your extension.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Victor Alvelais]

Thank you for your clarification and advocacy, Oliver. Looking forward to the adjustment.

On May 21, 2024, at 10:58 AM, Oliver Dunk <olive...@google.com> wrote:



[Brook Hong]

Thanks, it works with onUserScriptMessage.