Proposal: Add `management.readOnly` permission for read-only access to management API

[oliverdunk]

Some extensions benefit from knowing if specific other extensions are installed, without needing full access to the management API. For example, a content filtering extension may wish to know if another content filtering extension is installed, as having two can cause conflicts which are hard to troubleshoot.

To accommodate this use case, we can add a management.readOnly permission. This would grant access to the get(), getAll() and getPermissionWarningsByManifest() APIs. It would not grant access to other APIs.

The <api_name>.readOnly pattern is something we can consider a design pattern to add to more APIs in the future.

This was discussed previously during TPAC 2025.

[tophf]

1. Conceptually "management" and "read-only" are contradictory, so maybe query would be a better modifier.

2. There's a a lot of info returned by get() methods currently, but for the use case of conflict checking maybe a simpler new method would make more sense e.g. management.query({permissions: ['contentSettings']}) that returns a list of objects with a subset of props like {id, name, enabled, mayDisable, mayEnable}, additionally it may be designed to omit disabled extensions altogether.

[oliverdunk]

• Conceptually "management" and "read-only" are contradictory, so maybe query would be a better modifier.

I don't necessarily agree with this. Part of "managing" things might be querying data. query doesn't really work for getPermissionWarningsByManifest(), and I think there is also value in using a name that we can easily copy to other API namespaces.

2. There's a a lot of info returned by get() methods currently, but for the use case of conflict checking maybe a simpler new method would make more sense

Could you clarify the benefit of this? It seems like the main difference is being able to filter by permission, which is something we could add to the existing API if we saw value. That said, I don't think the amount of data returned is a big concern, so I'm not sure we really benefit much from adding a new method for this.

[tophf]

Part of "managing" things might be querying data

You're using query, which seemingly validates my suggestion.

query doesn't really work for getPermissionWarningsByManifest()

Why? It's still querying.

there is also value in using a name that we can easily copy to other API namespaces.

Yeah that alone seems to outweigh my linguistic nitpicking.

I don't think the amount of data returned is a big concern

Try looking at this from a perspective of someone who doesn't necessarily trust your company or browser extensions in general, i.e. a sensible cautious person who doesn't have time to study the code of each thing they install: I'm just not sure users would be comfortable with the necessity of exposing all of their belongings when asked whether they have a driver's license. You would have to phrase the permission's text in such a way that alleviates even a shadow of such concern, provided you're absolutely sure exposing all that info is safe.

[xeenon]

Neutral for Safari since we don't currently support the management APIs.

[sohailrajdev97]

Does this new permission also provide access to events like management.onEnabled or management.onInstalled? For example, an extension might want to track when a conflicting extension is installed or enabled in the future.

[jspivack]

This would defintively be helpful for us from a UI conflict prevention standpoint as well-- at times we have to jump through hoops to guess whether a conflicting extension is running on a page and then try to reposition our interfaces accordingly.

Is there somewhere else we could move this API that would be more privacy-focused? E.g. to query which extensions are running content scripts on a given tab?