Proposal: Targeted Permissions

[erosman]

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

[xeenon]

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]

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]

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]

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]

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