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

Proposal: Targeted Permissions #687

Open
erosman opened this issue Sep 12, 2024 · 5 comments
Open

Proposal: Targeted Permissions #687

erosman opened this issue Sep 12, 2024 · 5 comments
Labels
supportive: chrome Supportive from Chrome supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari topic: permissions

Comments

@erosman
Copy link

erosman commented Sep 12, 2024

Proposal: Targeted Permissions

Background

The current permissions are designed to be comprehensive. It simplifies the API access, however, users may become wary of the access given to the extensions, as reflected by the associated permission warnings.

There are many occasions when developers require minimal non-private data/function from an API.

For example, general data is accessible in tabs.query() without the need for tabs permission.

clipboardRead & clipboardWrite is another example of the targeted permission.

APIs such as bookmarks, downloads, history, and more, offer a mix of general non-private access, and more in-depth private access.

While it may add to the back-end processing complexity for the browsers, targetted permission should benefit developers, users, and browsers in the long run.

Proposal

Introduce a method in API permissions to separate general data/functions from privacy-concerned data access

Method

I can think of two approaches at the moment:

  • Making the general and non-private data/functions available without any specific API permission, as in tabs.query()
  • Introducing a 2 tier API permission, for example, with a sub-permission with limited access (non-private) for the API e.g. bookmarksBasic (or bookmarksLimited, etc)

Use Case Example: history

General

  • history.addUrl()
  • history.deleteUrl()
  • history.deleteRange()
  • history.deleteAll()

Privacy Concerns

  • history.search()
  • history.getVisits()
@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 12, 2024
@xeenon xeenon added neutral: safari Not opposed or supportive from Safari and removed needs-triage: safari Safari needs to assess this issue for the first time labels Sep 12, 2024
@xeenon
Copy link
Collaborator

xeenon commented Sep 12, 2024

This is the main reason why Safari auto-grants API permissions without notifying or warning the user, with privacy controls centered on granted host permissions. For instance, even with the tabs API permission, you can't access tab.title or tab.url without the corresponding host permissions for the tab in Safari.

I'm neutral on this issue, as it wouldn't impact Safari's overall permission model, but I can see the benefit to other browsers' permission models.

@dotproto
Copy link
Member

I like the idea of opening up the ability for an extension to use WebExtensions capabilities that don't expose sensitive information to the extension, but I'm not quite sure how best to accomplish it.

I expect @rdcronin and @Rob--W can speak to the details better than I can, but an advantage of our current approach is that it allows browser to limit the amount of binding necessary to initialize an extension's JavaScript context. I may be out of my lane here, but I think this may reduce startup times or have other performance benefits. It also provides a useful signal the capabilities an extension is requesting for static analysis and browser telemetry purposes. If we do allow extensions to access non-sensitive parts of existing namespaces, we may want to consider other ways to preserve the beneficial aspects of the current design.

@xeenon: For instance, even with the tabs API permission, you can't access tab.title or tab.url without the corresponding host permissions for the tab in Safari.

The tabs permission is unusual in that it originally did gate access to the entire tabs namespace, but that was changed in CR 10829186. As Aaron noted in comment 2 of the associated issue:

Ideally we'd have made the tabs namespace have no warning message and had a different permission that actually represented access to privacy sensitive data. But we didn't think of that at the time. This is the best we can do now without breaking changes.

Besides tabs and the clipboardRead and clipboardWrite permissions that @erosman mentioned, the only other permission I can think of right now that doesn't gate access to an entire namespace is nativeMessaging. I think it might be useful to distinguish between API permissions, which grant access to a namespace, and permissions that grant access to restricted methods or properties. Maybe "capability permissions"?

@erosman
Copy link
Author

erosman commented Sep 18, 2024

APIs with tiered permissions:

  • clipboard

    • clipboardRead
    • clipboardWrite
  • declarativeNetRequest

    • declarativeNetRequest
    • declarativeNetRequestFeedback
    • declarativeNetRequestWithHostAccess
  • downloads

    • downloads
    • downloads.open
  • menus

    • menus
    • menus.overrideContext
  • webRequest

    • webRequest
    • webRequestAuthProvider (Manifest V3 and above)
    • webRequestBlocking
    • webRequestFilterResponse
    • webRequestFilterResponse.serviceWorkerScript
  • storage

    • storage
    • unlimitedStorage
  • tabs

    • limited access without permission
    • tabs
    • tabHide

@oliverdunk oliverdunk added neutral: chrome Not opposed or supportive from Chrome and removed needs-triage: chrome Chrome needs to assess this issue for the first time labels Sep 26, 2024
@oliverdunk
Copy link
Member

oliverdunk commented Sep 26, 2024

Reducing the permissions needed for capabilities such as webNavigation would be desirable. However, I think this needs to be discussed on a case by case basis so adding neutral for now.

Edit: Switching to supportive following discussion at TPAC. We feel this more accurately represents our feelings on the general concept but would still like to see a more concrete proposal(s).

@xeenon xeenon added supportive: safari Supportive from Safari and removed neutral: safari Not opposed or supportive from Safari labels Sep 27, 2024
@oliverdunk oliverdunk added supportive: chrome Supportive from Chrome and removed neutral: chrome Not opposed or supportive from Chrome labels Sep 27, 2024
@xeenon
Copy link
Collaborator

xeenon commented Sep 27, 2024

I'm supportive of adding tiered permissions for a read / write split for things like cookies, downloads, etc.

@Rob--W Rob--W added supportive: firefox Supportive from Firefox and removed needs-triage: firefox Firefox needs to assess this issue for the first time labels Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
supportive: chrome Supportive from Chrome supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari topic: permissions
Projects
None yet
Development

No branches or pull requests

5 participants