1742635 - website interaction with midi api and site permissions needs definition

Status: NEW

(Core :: DOM: Device Interfaces, task, P2)

Description

[Shane Caraveo (:mixedpuppy)]

With addon gated addons, a site permission must be inserted through the installation of an addon to enable access to the APIs. However, the interaction of a website with those APIs needs more definition.

Does the navigator API remain visible to all websites, or only those sites that have an addon installed? ( see suggestion in https://phabricator.services.mozilla.com/D131857#4289593 )

How does a website determine that it needs to request that the user installs the addon? Calling navigator.requestMIDIAccess without the addon installed will [bug 1742471] behave the same as if the user denied access, there is no way to know the difference between user denial and the need to have the addon installed.

Comment 1

[Bobby Holley (:bholley)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #0)

Does the navigator API remain visible to all websites, or only those sites that have an addon installed?

The latter.

How does a website determine that it needs to request that the user installs the addon? Calling navigator.requestMIDIAccess without the addon installed will [bug 1742471] behave the same as if the user denied access, there is no way to know the difference between user denial and the need to have the addon installed.

If the UA is Firefox, and the |navigator.requestMIDIAccess| property doesn't exist, they should request that the user install the addon.

Comment 2

[Bobby Holley (:bholley)]

Also, the installation of the addon would ideally trigger the exposure of the property without the user needing to refresh the page.

Comment 3

[Shane Caraveo (:mixedpuppy)]

If the UA is Firefox, and the |navigator.requestMIDIAccess| property doesn't exist, they should request that the user install the addon.

This is just some of my thoughts around this.

UA detection isn't super reliable (e.g. a ton of addons tamper with the UA). I also don't see any impact by having requestMIDIAccess exposed, the patch in Bug 1742471 prevents it from prompting to allow the access if the addon hasn't already injected a permission. However even with that exposed, it doesn't provide a means by which you can reliably know that the addon is necessary. A more reliable mechanism would be something like navigator.isAddonGated(permissionName). That still doesn't provide the knowledge that the user already installed the addon, but disabled it, or that they otherwise disabled the permission.

Comment 4

[Bobby Holley (:bholley)]

I'm not worried about UA spoofing, but I think you may be right that there's little harm in exposing requestMIDIAccess everywhere. And if we do that, we can solve this problem by communicating the need for addon gating in the promise rejection parameter. Presumably there's some kind of "permission denied" exception that gets passed, and we could add a different "API is addon-gated" exception which sites could check for.

Comment 5

[Rachel Tublitz [:rachel]]

Gabriele, are you also planning to pick this up and get it landed for FX 97? I see it's marked as a blocker for 836897 so just to confirm.

Comment 6

[Gabriele Svelto [:gsvelto]]

Yes, I'll pick it up as discussed on Slack/Matrix. This is not my area of expertise though so I can't assess how long it will take me to do it.