Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev_permissions / self_permissions key in manifest #688

Closed
jspivack opened this issue Sep 16, 2024 · 5 comments
Closed

dev_permissions / self_permissions key in manifest #688

jspivack opened this issue Sep 16, 2024 · 5 comments
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time opposed: safari Opposed by Safari topic: permissions

Comments

@jspivack
Copy link

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.

@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Sep 16, 2024
@fregante
Copy link

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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.

@xeenon xeenon added supportive: safari Supportive from Safari opposed: safari Opposed by Safari and removed needs-triage: safari Safari needs to assess this issue for the first time supportive: safari Supportive from Safari labels Sep 24, 2024
@dotproto
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time opposed: safari Opposed by Safari topic: permissions
Projects
None yet
Development

No branches or pull requests

4 participants