1808431 - Reword WebMIDI site permission add-on prompt

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement, P3)

Description

[Brian G]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0

I accessed the WebMIDI API in Firefox 108.

Actual results:

I was presented with site permission add-on prompts. The wording in the prompts was concerning.

The first prompt sets the developer up as worthy of suspicion without giving them a chance to display the requested resource. A user can only properly evaluate the threat model after getting to the second prompt, and they may leave before then out of fear, uncertainty, or doubt.

The first prompt lists these potential consequences:

This add-on could be used to steal your data or attack your computer.

This statement is a bit heavy-handed and may scare users away from indie web projects that do not have name recognition. I get that it will also scare them away from malicious sites, but perhaps there is a more balanced approach.

Expected results:

One alternative would be to make explicit to the user what is being requested and why it is more dangerous than their other interactions with the browser.

Here is my take on how this could be written as a single prompt:

This site is requesting access to your MIDI devices. Device access can be enabled by installing an add-on.

This access can be dangerous because it allows the site to run software and access resources outside of the browser. Only continue if you trust this site.

[Learn more about installing add-ons safely](Link to more info)

{Don't Allow/Never Allow} {Install add-on}

I think this would be enough to inform the user that they are taking a risk that requires additional trust. The "Learn More" link could get into more detail about the potential consequences.

Comment 1

[Brian G]

For full context, this is the text displayed in the Firefox 108 prompts.

First prompt:

This site is requesting access to your devices. Device access can be enabled by installing an add-on.

This add-on could be used to steal your data or attack your computer. Only continue if you trust this site.

[Learn more about installing add-ons safely](Link to more info)

{Don't Allow/Never Allow} {Continue to Installation}

Second prompt:

⚠️ This add-on gives example.com access to your MIDI devices.

This access can be dangerous, and allows the site to act like software installed on your computer.

{Cancel} {Add}

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Bobby Holley (:bholley)]

Thanks for this. A few thoughts here.

First, we intentionally separated the flow into two prompts to nudge users off autopilot and get them to twice.

The first prompt is architecturally generic (it could in theory be used for other kinds of device access), which is why it doesn't say "MIDI". We could make it say "MIDI devices" with a modest amount of effort (primarily all the volunteer localization work of re-translating the updated text into 100 different languages). Our thinking was that for good-faith usage, the MIDI part would be obvious because the user is already intending to use their devices (either because the site is entirely about WebMIDI, or because they enabled a relevant feature). Do you think we should reevaluate that assumption?

This access can be dangerous because it allows the site to run software and access resources outside of the browser.

This swaps the description of potential consequences for a conceptual description of why this is different. The current design front-loads the former and pushes the latter into the "learn more" link, since we wanted to use our limited real estate to put the user on alert (and then give them the option to understand the situation more thoroughly).

There's some inherent tension between supporting good-faith usage and dissuading bad-faith usage, and the latter is unfortunately the dominant case on the Web right now (primarily due to fingerprinting). Based on telemetry I'd estimate that only 1-2% of access requests are good-faith (we're hoping to use bug 1806056 to identify and blocklist the biggest offenders and improve the ratio here).

Comment 4

[Maksim Lin]

There's some inherent tension between supporting good-faith usage and dissuading bad-faith usage, and the latter is unfortunately the dominant >case on the Web right now (primarily due to fingerprinting). Based on telemetry I'd estimate that only 1-2% of access requests are good-faith
(we're hoping to use bug 1806056 to identify and blocklist the biggest offenders and improve the ratio here).

To me this seems to be conflating security issues, which is what the message is warning me as a user about with privacy issues.
If that warning is intended to address concerns around websites using the WebMIDI API for finger printing than it should say so.
If its in regards to privacy concerns than the wording is inappropriate.

Comment 5

[Brian G]

(In reply to Bobby Holley (:bholley) from comment #3)

Thanks for your openness to discussing these prompts. The effort to counter fingerprinting is appreciated and absolutely one reason I am a Firefox user.

Our thinking was that for good-faith usage, the MIDI part would be obvious because the user is already intending to use their devices (either because the site is entirely about WebMIDI, or because they enabled a relevant feature). Do you think we should reevaluate that assumption?

In the long-term, I think that is a reasonable assumption. However, WebMIDI is new enough that many users may be surprised to find they can use their MIDI devices in the browser. As a developer, I would feel it was necessary to pre-explain before the prompt is displayed.

Even then, the message is scary enough that a user might reasonably ask themselves, "Wait, what devices? This is probably asking about MIDI, but am I granting permission for more than that?".

This access can be dangerous because it allows the site to run software and access resources outside of the browser.

This swaps the description of potential consequences for a conceptual description of why this is different. The current design front-loads the former and pushes the latter into the "learn more" link, since we wanted to use our limited real estate to put the user on alert (and then give them the option to understand the situation more thoroughly).

Putting the user on alert without a sufficient understanding of the threat model is scare tactics. I'm agreed that these scare tactics are helpful for combating bad-faith usage, but they are also likely to scare users away from good-faith usage.

I'd rather users have some sort of conceptual model than to simply be scared away. But if scare tactics are the order of the day, I'd rather they have as much context as possible to evaluate the request.

There's some inherent tension between supporting good-faith usage and dissuading bad-faith usage, and the latter is unfortunately the dominant case on the Web right now (primarily due to fingerprinting). Based on telemetry I'd estimate that only 1-2% of access requests are good-faith (we're hoping to use bug 1806056 to identify and blocklist the biggest offenders and improve the ratio here).

Yikes! One can only hope that this number comes down. It's disappointing.

---

Maksim raises a fair point. The prompt says

This add-on could be used to steal your data or attack your computer

but our discussion has primarily been around fingerprinting. Are there other threats at play here?

Comment 6

[Brian G]

I wanted to add a user experience report to the discussion. This report only represents one experience, so it should be taken as more of an anecdote than real data. Nonetheless, I thought it was worth sharing.

I recently updated one of my apps (https://coincident-spectra.fission.app/) to inform users that the app uses MIDI devices before the app requests MIDI access, thereby providing some context before they see the add-on prompts. I asked a user to try the updated app in Firefox.

The user is primarily a Firefox user. They have used Chrome on occasion to access the WebMIDI API before Firefox added support.

On visiting the app and moving past the welcome modal, the user was presented with the add-on prompt. They reported feeling a bit nervous, and that they had not seen anything like this in Chrome. They decided against granting permission and felt that they would be safer using Chrome. The wording about "stealing data" made them instantly want to click away.

Comment 7

[[e-mail]]

I have another user report. Before I post this I want to say thank you so much to everyone who worked on implementing WebMIDI. What an awesome feature!

Today I visited a site that uses WebMIDI and I was excited that Firefox recognized it. However as I read the modal that popped up and realized that it doesn't even mention WebMIDI, or give any other indication as to the source/reason for the security message, I became concerned. If I think about deploying this to my users here's how the flow would go:

1. They visit one of my music apps where I have enabled optional WebMIDI support.
2. They see a severe security message that doesn't even mention the reason it is showing up (WebMIDI request).
3. They feel worried and close the window.

A huge improvement would be if the popup began with the words: "This website uses WebMIDI and has requested access to your MIDI music devices." At least then the user has some context.

It would be entirely reasonable to take some queues from other browsers for how this flow could be optimized. I understand the security risk from having read the GitHub ticket and the Bugzilla thread on implementing this so I know there has to be some kind of warning and I'm not arguing against that. It seems clear that the messaging is over the top when it comes to the actual risk in this case. If you consider that e.g. WebRTC can open a port to receive network traffic without the user ever even knowing, and there is no message at all in that instance, the security messaging in this case seems excessive by comparison.

Thank you very much for all of your hard work on this and for listening to users like me, much appreciated!

Comment 8

[j.ingram]

I have a web page that uses WebMIDI, and would like to support what [e-mail] says above (in comment #7).

The prompt's current wording is definitely misleading, and even appears to be outright wrong: Firefox is not asking if it can install a potentially harmful add-on, its just asking for permission to access the site.
So I also think the text should begin with "This website uses WebMIDI and has requested access to your MIDI music devices."

+1 too for "Thank you very much for all of your hard work on this and for listening to users like me, much appreciated!" :-)

Comment 9

[Bobby Holley (:bholley)]

Hi folks — thanks for the constructive feedback and patience.

The combined input on this bug makes a reasonable case that the current consent language (1) provides insufficient context about the nature of the request and risk, and (2) is scary enough that even good-faith usage is deterred. This is supported by the data we’ve received from the “suspicious site” telemetry added a few months ago in bug 1806056. Since its inception, we’ve received quite a few clicks of the “report suspicious site” button for what appear to be good-faith uses (hooktheory.com, onlinesequencer.net, etc).

Some of the tension here between enabling good-faith usage and deterring bad-faith usage may be irreconcilable. That said, I’m willing to take another crack at threading the needle to see if we can meaningfully improve the results.

See the attached screenshots of the current flow, for which we’ve observed the following deficiencies:

• The nature of the device access is very ambiguous.
• The description of potential consequences (“steal your data or attack your computer”) is unusually vivid and makes the context feel hostile enough to make users prefer another browser.
• The description of “act like software installed on your computer” is perhaps overly-conservative.

To address these, I've also attached screenshots of the a proposed replacement.

This involves specializing the localized strings to be more MIDI-specific than they are today, but it seems clear enough that more specificity is better here.

Comment 10

[Bobby Holley (:bholley)]

Attachment: existing_step1.png

Comment 11

[Bobby Holley (:bholley)]

Attachment: existing_step2.png

Comment 12

[Bobby Holley (:bholley)]

Attachment: proposed_step1.png

Comment 13

[Bobby Holley (:bholley)]

Attachment: proposed_step2.png

Comment 14

[Maksim Lin]

Thanks for working on this, the proposed dialog box text copy is so much better than the existing ones.

Comment 15

[j.ingram]

Thanks again for working on this.
I'm still not happy with the (false) implication that the user is going to have to install an add-on. Many users will simply give up at the thought of installing anything. An installation may be the way the situation looks to Firefox, but its not the way the users need to see it.

Suggestions:
Step 1:
This site is requesting access to your MIDI musical instrument devices. Device access can be enabled by installing an add-on.
This access is not guaranteed to be safe. Only continue if you trust this site.
Learn more about installing add-ons safely
Don't allow
Continue to installation

Step 2:
This add-on gives Allow webmidi-examples.glitch.me to access to your MIDI devices?
These are usually plug-in devices like audio synthesizers, but also be built into your computer.
Websites are normally not allowed to access MIDI devices. Improper usage could cause damage or compromise security.
Cancel No
Add Yes

Comment 16

[Brian G]

(In reply to Bobby Holley (:bholley) from comment #9)

Great! This strikes a good balance in my opinion. Thank you for the wordsmithing.

I have a couple of small proposed adjustments.

This site is requesting access to your MIDI musical instrument devices.

This context setting is excellent, and I am in favor of calling out the musical use case. Power users will know when they are exploiting MIDI devices for other purposes.

I would reword this to "This site is requesting access to your MIDI musical instruments and controllers". The words "instrument" and "devices" are both nouns, so it's redundant to use both. Also, MIDI devices can be controllers, not just instruments.

Websites are normally not allowed to access MIDI devices.

The phrasing here is a bit ambiguous. As if the user were asking the browser for special permission instead of granting it. Perhaps as an alternative, "Websites need permission to access MIDI devices."?

Comment 17

[Jeff Griffiths]

Yeah agreed. :bholley I think it's irrelevant to users that you've decided to implement this feature using synthesized extensions and there is nothing to be gained by exposing this. Any number of Firefox features have been shipped as extensions without the need to expose this to the end-user, especially given that the synthesized extension is first party. As Brian said though, the proposed version is so much better than the original might as well ship it and file a followup to review the text. If you're going to do this sort of synthesized extension gating of new features a lot, it might be worth doing some user testing.

(In reply to j.ingram from comment #15)

Thanks again for working on this.
I'm still not happy with the (false) implication that the user is going to have to install an add-on. Many users will simply give up at the thought of installing anything. An installation may be the way the situation looks to Firefox, but its not the way the users need to see it.

Suggestions:
Step 1:
This site is requesting access to your MIDI musical instrument devices. Device access can be enabled by installing an add-on.
This access is not guaranteed to be safe. Only continue if you trust this site.
Learn more about installing add-ons safely
Don't allow
Continue to installation

Step 2:
This add-on gives Allow webmidi-examples.glitch.me to access to your MIDI devices?
These are usually plug-in devices like audio synthesizers, but also be built into your computer.
Websites are normally not allowed to access MIDI devices. Improper usage could cause damage or compromise security.
Cancel No
Add Yes

Comment 18

[Bobby Holley (:bholley)]

(In reply to Maksim Lin from comment #14)

Thanks for working on this, the proposed dialog box text copy is so much better than the existing ones.

Thanks.

(In reply to Brian G from comment #16)

I would reword this to "This site is requesting access to your MIDI musical instruments and controllers". The words "instrument" and "devices" are both nouns, so it's redundant to use both. Also, MIDI devices can be controllers, not just instruments.

I'm a little wary of delving into the distinction between instruments and controllers. A colleague suggested your Musical Instrument Digital Interface (MIDI) devices, which I like. It has the nice property of succinctly signaling the "music tech" context and expanding the acronym. It's a little ambiguous how best to localize it, but might be fine.

Websites are normally not allowed to access MIDI devices.

The phrasing here is a bit ambiguous. As if the user were asking the browser for special permission instead of granting it. Perhaps as an alternative, "Websites need permission to access MIDI devices."?

The intention to signal that this level of access exceeds the expected limits we want to set for web features (even those with permission prompts), in line with the rationale here and the user-facing copy here. The "not normally allowed" language is a bit imprecise but sets approximately the right tone.

In regards to the installation metaphor — the core constraint here is that we're only willing to expose raw device capabilities for users who would be otherwise willing to install software from the site. The installation experience is the whole point, and reflects an experimental effort to carve out a compromise with our longstanding stance of not supporting these features at all.

This compromise was never destined to make everyone happy, but the feedback in this thread suggests there's room to make some people more happy by refining the copy. I'm going to go ahead with that for now.

Comment 19

[Bobby Holley (:bholley)]

Attachment: Bug 1808431 — Reword first WebMIDI prompt.

Comment 20

[Bobby Holley (:bholley)]

Attachment: Bug 1808431 — Reword second WebMIDI prompt.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9d161e1551ab
— Reword first WebMIDI prompt. r=rpl,flod
https://hg.mozilla.org/integration/autoland/rev/747b5019c69a
— Reword second WebMIDI prompt. r=rpl,flod,desktop-theme-reviewers,sfoster

Comment 22

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/9d161e1551ab
https://hg.mozilla.org/mozilla-central/rev/747b5019c69a