dotproto

Sure. If you're the only one using it, you can just run the extension locally as an unpacked extension. Check out the step-by-step getting started guide: https://developer.chrome.com/docs/extensions/mv3/getstarted/

For your case, you'll probably want to save the bookmarklet as a JS file, let's say content.js, and inject in when you click the extension's icon. Here's the basics to get you started.

manifest.json

  {
    "name": "Demo",
    "version": "1.0",
    "manifest_version": 3,
    "permissions": [
      "scripting",
      "activeTab"
    ],
    "background": {
      "service_worker": "background.js"
    },
    "action": {}
  }

background.js

  chrome.action.onClicked.addListener((tab) => {
    chrome.scripting.executeScript({
      target: {tabId: tab.id},
      files: ['content.js'],
    });
  });

content.js

  alert('It worked!');

Manifest V3 does not currently support user script managers, but we are planning to address that gap in the coming months.

Yes-ish?

So the extension itself is basically a bundle of web resources like HTML, CSS, and JS files. Today, the only way an extension can ask Chrome to automatically inject a content script on a page is to declare what scripts should be injected on which sites in the extension's manifest. For example…

  "content_scripts": [
    {
      "matches": ["*://*.nytimes.com/*"],
      "js": ["content-script.js"],
      "run_at": ["document_start"]
    }
  ],

This snippet from a manifest file will inject a file in the extensin's bundle called "content-script.js" onto all New York Times web pages the user visits right as the page start loading. The downside to this approach is that this is a static declaration; after the extension is installed it can't say "hey Chrome, I also you want you to inject that same script on BBC websites.

In the quote you highlighted, what I was trying to say was that we are also planning to give extensions the ability to modify the set of content scripts while the extension is running. This means the extension will be able to ask Chrome to automatically inject the same script on BBC websites.

For clarity, injecting a script that is not included with the extension is expressly disallowed by the Chrome Web Store Developer Program Policies.

> Some common violations include: > > * Including a <script> tag that points to a resource that is not within the extension's package

https://developer.chrome.com/docs/webstore/program_policies/...

Original blog post author here. The short answer is that Manifest V3 does not currently support these extensions (or their broader use cases), but we want to support them and have some ideas that we plan to explore.

Original blog post author here. Some quick personal thoughts (i.e. I'm not speaking on behalf of Chrome here).

> - Blocking webRequest to change CSP to authorize our overlay script to execute

I can't exactly say I'm keen on extensions relaxing CSP rules for a site. The approach I'm interested in exploring here is allowing extension resources to bypass CSP restrictions on a given site. IMO a typical extension shouldn't be able to weaken a site's security, but it should be able to load its own images and scripts on the site.

> - executeScript: in most case, the script we execute is just inserting a script tag so it would still work in Manifest v3, but with webapps using Service Worker we have to resolve to download the scripts and execute then directly via executeScript, which will not be possible in v3.

This is not a viable approach in Manifest V3 as reviewers would consider this remote code injection and therefore a violation of the "Additional Requirements for Manifest V3" section of the policy.

https://developer.chrome.com/docs/webstore/program_policies/...

Bundling the overlay engine with the extension sounds like it may do the trick. Just make sure that the engine cannot be used for malicious purposes (e.g. harvesting user data, arbitrary script injection, etc.).

What changes are you most concerned about? How does Manifest V3 negatively impact your extensions?

You may want to consider getting involved in the recently announced WebExtensions Community Group in order to discuss your concerns with the future of browser extensions with browser vendors and other extension developers.

http://w3c.org/community/webextensions https://github.com/w3c/webextensions

> it just seems so trivial to me too build a small interpreted system that circumvents the "no dynamic JavaScript" rule

While it's possible to build an interpreter in JS, doing so in an extension is an unambiguous violation of the Chrome Web Store Developer Program Policy. The goal isn't to make abuse impossible so much as to limit potential attack vectors in order to make enforcement more tractable.

> They already disallowed remote code loading in extensions with a Chrome Web Store policy update nearly two years ago. They didn't have to invent a new API full of breaking changes to do it.

Blog post author here. This comment is incorrect on two main fronts.

First, the Chrome Web Store's Developer Program Policy did not prevent the use of remote code, it only forbade the obfuscation of remotely loaded code. An alternative, stricter reading of the policy was that extensions could not use remotely hosted code to obfuscate it's operations. Regardless of which of these interpretations you favor, using remotely hosted code in Manifest V2 extensions is not forbidden by our policies.

Second, I strongly disagree with the implication that policy changes could have addressed the abuse issues we're seeing. Even if we did have policies disallowing the use of remotely hosted code, that does not somehow compel developers to comply or simplify the enforcement process. I have a ton of respect for my colleagues in review, but policy enforcement is complex and virtually impossible to get right 100% of the time. So, some amount of malware will get through review, some number of users will be exploited, and some amount of harm will result. How much harm should we accept as "the cost of doing business", especially when we have a way to address a major exploit vector?

Speaking as a developer, I'm not exactly thrilled to lose capabilities that I've been using responsibly because other people are exploiting them. On the other hand, as a member of the team maintaining this platform I don't see a practical alternative to address the problems that arbitrary code execution presents for the average user.

"They already win on UX"

As someone that has tried and failed to get some small personal sites running on AWS a couple times, I'm going to have to tag this snippet with [citation needed].

You're giving HN a bit too much credit.

The CWS developer program policy does not allow extensions to request unnecessary permissions. If an extension doesn't have a good reason to observe network requests in MV3, it will/should be rejected.

So yes, it's technically possible to observe network requests but in practice few should be doing it.

Correct, apps are depreciated and you can still upload new extensions.

This white paper may help https://support.google.com/chrome/a/answer/9296680?hl=en

At some point I want to put together a simple Node.js server and ExtensionSettings policy to demo a basic working setup, but unfortunately that's back-of-the-bus level backseat at the moment.

https://cloud.google.com/docs/chrome-enterprise/policies/?po...

You may be able to reach out to the Chrome Enterprise Browser Support team for assistance. https://support.google.com/chrome/a/answer/4594885?hl=en

Self-hosting is def an option. Check out "Managing Extensions in Your Enterprise" https://support.google.com/chrome/a/answer/9296680?hl=en. That's probably the single best resource for hosting your own extensions and installing them on managed devices.

What's your extension ID?

Can't speak for other Chromies, but what's crossed my radar has been direct outreach from developers and bug reports.