dev_permissions / self_permissions key in manifest

[jspivack]

Summary

As an extension developer, we sometimes run into cases where the permissions that help with the process of development, testing, and internal observability are not necessarily useful to our end users (and additionally would trigger negative warnings at installation). The issue is heightened by the fact some of these tooling-centric permissions, such as debugger and devtools, are not able to be specified as optional in the manifest, presumably as these are high-powered APIs and user security is a critical consideration.

I propose a dev_permissions or self_permissions key in the manifest schema which would grant permissions that apply only to unpacked installations, thus being inapplicable to builds uploaded to and installed from the web stores. A parallel but not identical concept is Node's devDependencies which specifies different instructions to the npm installer based on the environment in which it's being run.

Workaround

The only current workarounds I'm aware of are: either maintaining a separate manifest file entirely for development vs web store builds, or modifying the manifest file permissions key as a part of extension build and release.

[fregante]

I see a couple of problems with this:

• the extension works locally but then it fails once published, because you forgot to add the permissions to the right array
• often I need to customize web_accessible_resources and the CSP to allow debugging, so perhaps a dev_overrides object that accepts most manifest keys would be better.

I think it’s just easier to use a build tool that lets you customize the manifest during development exactly as you please.

[jspivack]

If developer error is a primary concern, isn't custom build tooling and manifest manipulation a more dangerous footgun?

A dev_overrides key as you suggested would be nice as well. It may also help to mitigate developer mistakes through the virtue of being nested under a separate section.

[dotproto]

I'm also worried about creating inconsistencies between environments. I've seen developers get tripped up on the few, small inconsistencies that browsers have between "development" and "production" behaviors and they've been frustratingly hard to debug.

That said, a dev_permissions or dev_overrides field could create an interesting opportunity. Stores could use this as a clear signal that a given submissions is either a development or production build, allowing them to warn the developer or reject the submission outright.

[jspivack]

I'm also worried about creating inconsistencies between environments. I've seen developers get tripped up on the few, small inconsistencies that browsers have between "development" and "production" behaviors and they've been frustratingly hard to debug.

That said, a dev_permissions or dev_overrides field could create an interesting opportunity. Stores could use this as a clear signal that a given submissions is either a development or production build, allowing them to warn the developer or reject the submission outright.

This would solve our primary goal of keeping those permissions out of the store package as well. Sounds like a great solution.

[dotproto]

During our backlog grooming session on Tuesday Sept 24, 2024 the preferred solution discussed was that developers use built steps to strip unnecessary permissions from the extension manifest at submission time and to use optional permissions. Separately, there was general consensus that all permissions should be optional (where possible).