RFP: WebUSB API

[Jxck]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebUSB API
• Specification or proposal URL: https://wicg.github.io/webusb/
• Caniuse.com URL (optional): https://caniuse.com/#feat=webusb

Other information

• WebKit Not Considering: https://webkit.org/status/#feature-webusb
• TAG Review: WebUSB w3ctag/design-reviews#108

[AntoineTurmel]

For reference, WebUSB was being developed at the time for FirefoxOS, see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=674718

[dbaron]

Some comments from elsewhere include #95 (comment), w3ctag/design-reviews#108, the minutes from Thursday 2016 July 28 TAG meeting. Major concerns raised there include:

• security issues related to attacks on devices that, once compromised, could be used to attack the user's computer more generally
• the permissions model (whether a question can be posed to the user that yields informed consent, whether there should be a CORS-like model for devices to say that they want to interact with particular domains which may improve security but hurts openness)

[karelbilek]

It would be interesting for me to know this status too

[ekr]

I believe we should mark this "harmful". @martinthomson

[dbaron]

I have a PR in #193 to do that that ended up gathering a bunch of discussion on the rationale we should state (discussion that should probably have happened here instead). I need to figure out how to revise that...

[annevk]

Closing as that PR was merged.

[marcoscaceres]

From a discussion elsewhere, Chrome allows flashing Android phones via WebUSB:
https://www.androidauthority.com/android-flash-tool-1078391/

[marcoscaceres]

Another example that came up on twitter was a custom USB driver for a thermal printer:
https://twitter.com/samccone/status/1280709905595285505?s=20

(Sorry for the noise, just collecting "as seen in the wild" use cases as people bring them to my attention on twitter)

[karelbilek]

Trezor (a cryptocurrency Hardware wallet) - my former employer - uses WebUSB, when available, for communication with web wallet, if used from a browser. (I wrote the WebUSB code into both the website and the C firmware.)

I think in the next, planned version, they offer Electron app first, which does not use WebUSB, but includes local server in go and c++ (because it's still easier for debugging to use the raw OS calls), but if you decide to skip Electron app and use web, it goes to WebUSB.

one reason why they plan to push Electron instead of web app is that Firefox doesn't support WebUSB :)

[marcoscaceres]

Appreciate the input @karel-3d, thank you.

[wisniewskit]

For reference, WebADB is now using WebUSB and its lack of support for non-Chrome browsers was just reported on webcompat.com.

[martinthomson]

ADB is an exemplar of the sort of access that is most problematic. Great example.

[mash-graz]

mozillas refusal of WebUSB support is a really unpleasant limitation.

it's nearly impossible to implement adequate substitutes for this feature on small micro controller gadgets (in my particular case: measurement devices).

WebUSB would provide a much more secure and privacy protecting solution for this kind of applications, than using this very weak IP stacks for µCs/RTOSs, which in most cases will never become updated etc., and depend on centralized web-server infrastructure outside, because proper and user friendly SSL/TLS certificate handling for private networks (RFC 1918) is nearly impossible.

because of this reasons WebUSB refusal does IMHO more harm to security and privacy efforts in practice, than protecting users from real dangers.

[fabricedesre]

it's nearly impossible to implement adequate substitutes for this feature on small micro controller gadgets (in my particular case: measurement devices).

Measurement devices are an interesting use case indeed. You certainly want your measurements to stay correct, but the security model used for webUSB doesn't guarantee that the code that communicate with the device hasn't been tampered with. Transport security is not enough for that.

[esafwan]

Digitally signing documents with USB Flash Disk is another emerging use case. I wouldn't trust any other browser if at all such a time comes.

[tobozo]

Is there an addon, a shim or a polyfill for WebUSB that would allow hardcore Firefox users to work on embedded projects?

Found this plugin but it's not an addon and the (linux) documentation seems rather outdated.

[karelbilek]

Hm. In theory, you could run a small HTTP server with localhost exposed, that reads/writes to USB, and connect to it in JS via polyfill.

But then all your users would need to install this. And it has all the security negatives of WebUSB. 🤷

[karelbilek]

When I worked for Trezor, we did something like that, just for our devices

https://github.com/trezor/trezord-go

but note, most of the code there deals with peculiarities of edge-case issues on both different OSes and the devices itself. USB is actually very tricky to get right, and LibUSB is actually kind of bad, at least on Windows. It's only popular because there is nothing better that is cross-platform.

Chrome ended up re-implementing USB access from scratch (and into C++ Chrome-isms), because libusb (that they used before) was very VERY unstable on Windows. And the code itself was just horrible... not sure of the state now

https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L1433

yeah it's still the same old, even when they refactored it a bit

(I really like WebUSB, I just wish they stuck with the earlier security design, where the device itself need to opt-in to URLs via device descriptor. That would make a lot of fears go away and Mozilla could implement it as-is. But that ship has long sailed I guess... years now)

ok anyway I digress. Good luck. (Or maybe just use Chrome.)

[karelbilek]

You can see that the new-ish USB code at Chrome is leagues better than the libusb mess

https://source.chromium.org/chromium/chromium/src/+/main:services/device/usb/usb_service_win.cc;l=510

vs

https://github.com/libusb/libusb/blob/master/libusb/os/windows_winusb.c#L1433

too bad it's so tied to Chrome

[tobozo]

@karelbilek thanks for all these useful resources

Now back to the original topic of this thread: what can I do to reopen this discussion and hopefully have Mozilla reconsider, maybe changing the stance from "considered harmful" to "considered both benefial and harmful"?

Here's my contribution to the discussion:

If some users want to keep their only use Firefox stance, then not implementing Web Serial API will be harmful to Mozilla's user base, by progressively losing support from the embedded devices developers community fans, and helping the competitors consolidate the market share.

[ghost]

WebUSB isn’t harmful, you can just add a warning when selecting a usb device. I don’t understand why this isn’t implemented yet.

[bastian2001]

Up until now, I have never heard of any security problems with WebUSB (although I can definitely think of some). With the right warning however, I think it is very clear to the user, that they should trust the website.

On the other hand, WebUSB is very useful for FPV drones. People do not like to install a full-fledged program on their PC, hence there are many tools in this area, that use WebUSB: EdgeTX Buddy for configuring the RC, ESC Configurator for configuring motor drivers, FPV.WTF for Video Livestream from the FPV Goggles

IMO Mozilla should reconsider implementing it. Even with a big warning, saying "If you let this website access this USB device, the website could destroy your computer within a second.", I still think it is better to have it. I hate having to open another browser for this.

[nondebug]

In Chrome we are implementing support for WebUSB from extension service workers since the current practice of accessing the API from an extension's background page will no longer work with manifest V3.

Chrome Platform Status: https://chromestatus.com/feature/5200265459269632
Explainer: https://github.com/nondebug/webusb/blob/service-worker-explainer/extension-service-worker-explainer.md

We're doing the same work for WebHID as noted here.

Mozilla is experimenting with exposing powerful APIs, particularly WebMIDI but potentially expanding to other device APIs like WebUSB. We're interested in any signals Mozilla can provide on the proposal linked above, as well as Mozilla's current thoughts on how we can safely expose this capability on the web (and to extensions).

[dmitriid]

The moment Mozilla implemented WebMIDI, they immediately discovered that web sites are using these capabilities for fingerprinting. See https://twitter.com/denschub/status/1582730985778556931

Quote from the comment: "Chrome allows web developers to enumerate attached MIDI devices without user consent or even a notification."

This is and/or will be true for any "powerful API", and this is not solved by throwing a thousand notifications asking users for permissions or by silently allowing everything.

[aspiers]

@dmitriid wrote:

The moment Mozilla implemented WebMIDI, they immediately discovered that web sites are using these capabilities for fingerprinting

Then their implementation was wrong. Obviously sites should not have access to any attached devices by default. That doesn't mean there is no good way to implement WebMIDI.

This is and/or will be true for any "powerful API", and this is not solved by throwing a thousand notifications asking users for permissions or by silently allowing everything.

It's not "a thousand notifications", it's either one per device, or at most one per device per website (exactly how Chrome allows users to permission extensions either for access to all sites or only to individual selected sites). For example, I would only ever need WebUSB for my Trezor device on a handful of highly trusted websites, and not for any other USB device - so that would be something like 5 notifications spread out over weeks or months.

In other words, we're talking about a tiny number of notifications for the typical user in order to achieve a perfectly reasonable and convenient approach which:

• is 100% secure by default, since without explicit consent, no site can access any attached devices, and
• allows users the freedom to assess the balance between functionality and security risk which best suits their own individual circumstances.

This is far preferable to assuming that all users are incapable of making educated judgements about what levels of risk they are prepared to accept in order to gain functionality. All browsers already ask users to make those judgement calls on a very regular basis, so I doubt there is any good reason why WebUSB should be the exception.

[dmitriid]

Then their implementation was wrong.

And what other implementations of similar APIs may or may not be wrong?

Note: Chrome still hasn't added a prompt saying that they can't rush into fixing this because this will break functionality on sites that rely in this behaviour.

It's not "a thousand notifications", it's either one per device, or at most one per device per website

• dozens of APIs
• per web site

Even ten web sites take this into "100 possible notifications" realm.

n other words, we're talking about a tiny number of notifications

It really isn't a tiny amount of notifications. This is the ting I keep seeing over, and over, and over again: when discussing an API people are completely blind to the fact that other APIs exist, and many of them require premissions, too.

And don't forget that on top of these permissions we have all other notifications: from "hey sign up to our newsletter" to malicious GDPR miscompliance.

This is far preferable to assuming that all users are incapable of making educated judgements about what levels of risk they are prepared to accept in order to gain functionality.

It's not an asumption. It is a known, well researched and understood fact. Do you know why so many Android apps ask for a gazillion permissions on install?

[tobozo]

so the only remaining problem is how many notifications this will generate?

[aspiers]

Then their implementation was wrong.

And what other implementations of similar APIs may or may not be wrong?

Sorry, I don't understand the question (or the point, if it's a rhetorical question). Please could you expand?

Note: Chrome still hasn't added a prompt saying that they can't rush into fixing this because this will break functionality on sites that rely in this behaviour.

That sounds like a serious error of judgement by the Chrome team to me. It doesn't justify Mozilla avoiding a chance to do it right though.

It's not "a thousand notifications", it's either one per device, or at most one per device per website

• dozens of APIs
• per web site

Even ten web sites take this into "100 possible notifications" realm.

I was talking about just WebUSB, but if I understand you correctly, you're extending the scope of the discussion to every API which a website could possibly request. That's an entirely different discussion.

My claim was that adding WebUSB support in a way which requires any website to get the user's permission to use it would add a tiny number of notifications on top of the ones which the browser already generates. For example, if the user has to endure 100 notifications over n websites, then I claim that for most users, adding WebUSB support in the way I've suggested would increase that by a tiny amount, because the majority of sites have zero genuine need for WebUSB.

So for the sake of this example, let's say it increases it to 102 notifications across n + 2 sites, because the user only ever visits two sites which need WebUSB. If I understand your argument correctly, in this scenario your point would be that 102 notifications is far too many? I would agree, but I would also point out that:

• The real problem there would be the 100, not the extra 2. That should certainly be fixed, but it's nothing to do with the topic of WebUSB support.
• The delta increase of 2 is negligible and entirely justified when there is a genuine need for Web USB.
• If the concern is the lack of genuine need, i.e. that a whole bunch of spammy or malware sites would request permission to access WebUSB, then that is easily addressed in two separate ways:
  1. Any site which spams its users with notifications and requests for permission to access many APIs is very likely to severely harm its own user engagement, people get quickly turned off when they are constantly spammed. So sites are already incentivized not to spam their users.
  2. The browser can simply set the default permissioning mode for WebUSB to "deny access" rather than "ask the user", and then for sites which need WebUSB, the user can manually enable it rather than having to respond to requests. This instantly eliminates all spam.

n other words, we're talking about a tiny number of notifications

It really isn't a tiny amount of notifications. This is the ting I keep seeing over, and over, and over again: when discussing an API people are completely blind to the fact that other APIs exist, and many of them require premissions, too.

I'm not blind to that, but as explained above, it's not relevant to this WebUSB topic. If other parts of the browser are doing a poor job of protecting the user from notification spam, that's not a good reason to avoid doing it right for WebUSB.

And don't forget that on top of these permissions we have all other notifications: from "hey sign up to our newsletter" to malicious GDPR miscompliance.

Sure, but again, this is not relevant to WebUSB as I already explained above.

This is far preferable to assuming that all users are incapable of making educated judgements about what levels of risk they are prepared to accept in order to gain functionality.

It's not an asumption. It is a known, well researched and understood fact.

Wait, did you really just say it's "a known, well researched and understood fact" that all users are incapable of making educated judgements about what levels of risk they are prepared to accept? Surely you can't have really meant that?

Do you know why so many Android apps ask for a gazillion permissions on install?

Yes I do, but I don't see how that's relevant here.

[wisniewskit]

Just FYI, as per https://groups.google.com/a/mozilla.org/g/dev-platform/c/15O04X2jE28/m/deXYDi85CQAJ , Firefox now has support for WebMidi as of 108. It's not a huge leap to imagine that a similar approach could be used for WebUSB as well.

[dmitriid]

@aspiers @tobozo @wisniewskit

Let's start from the start, shall we.

Yes. Firefox now supports Web MIDI. And here's what Fireofx has to say about it: https://twitter.com/denschub/status/1582730985778556931

Remember when everyone yelled at Mozilla for not supporting WebMIDI, with claims that privacy and security concerns were overblown and "holding back the web"?

Well, just a day after shipping an impl to Firefox Nightly, [we discovered] WebMIDI-fingerprinting.

Chrome still allows web developers to enumerate attached MIDI devices without user consent or even a notification, btw.

Note: Chrome still hasn't added a perission prompt saying that they can't rush into fixing this because this will break functionality on sites that rely in this behaviour.

So, what "similar approaches" can we apply to WebUSB as well? Oh, perhaps... hide access behind a permission prompt? But then we're back to square one on permissions. So we have location, microphone, camera, web notifications, clipboard permissions already. And then we'll need web midi, web hid, web usb, web bluetooth permissions... And god knows how many more that Chrome spits out with zero care or oversight.

I keep saying: for some odd reason people completely ignore that all other APIs that require permissions. The APIs that you propose that browser add, do not exist in a vacuum. You can't blame the browser for "doing a poor job of protecting the user from notification spam" and insist that the browsers add even more notification spam. You can't pretend an API adding new notifications and permission prompts is somehow separate and isolated from every other API also requesting permissions and showing notifications.

Also, you can't pretend that users are knowlegeable enough to understand what each of these permissions do. We know they don't.

You can't pretend that all this isn't relevant to the API you're so want. All in all you can't pretend this is an issue even though we know this is an issue.

[dmitriid]

Oh. Right. Forgot one more thing.

Claim:

is 100% secure by default, since without explicit consent, no site can access any attached devices,
The browser can simply set the default permissioning mode for WebUSB to "deny access" rather than "ask the user"

Reality (using Web MIDI as an example)

Chrome still allows web developers to enumerate attached MIDI devices without user consent or even a notification, btw.

The more complex an API, the more the chance it will be implemented incorrectly, inconsistently, or differently enough for it to matter.

[tobozo]

Also, you can't pretend that users are knowlegeable enough to understand what each of these permissions do. We know they don't.

If you know they don't, please share that survey so that we can see it is not biased (e.g. based on Mozilla users exclusively).

If this survey is internal only, there's another possible angle to "We know they don't" => "We unintentionally made sure they don't" when users who did understand permissions threw the towel and just picked another browser supporting the extra API, thus consolidating the survey bias.

[tobozo]

The more complex an API, the more the chance it will be implemented incorrectly, inconsistently, or differently enough for it to matter.

it didn't sound like FUD when all of this happened to the Audio API, and it can't possibly be an acknowledgement of incompetency, so what does it imply exactly, could it be worked around as an extension or bound to a config flag disabled by default, or even limited to a different edition of Firefox (e.g. LibreWolf)?

[aspiers]

@aspiers @tobozo @wisniewskit
Note: Chrome still hasn't added a perission prompt saying that they can't rush into fixing this because this will break functionality on sites that rely in this behaviour.

I already replied to this statement so I'm not sure why you're repeating it.

So, what "similar approaches" can we apply to WebUSB as well? Oh, perhaps... hide access behind a permission prompt? But then we're back to square one on permissions. So we have location, microphone, camera, web notifications, clipboard permissions already. And then we'll need web midi, web hid, web usb, web bluetooth permissions... And god knows how many more that Chrome spits out with zero care or oversight.

I already explained in detail (with an example) why I don't accept that argument.

I keep saying

Please don't, I heard you the first time, as evidenced by my last reply.

for some odd reason people completely ignore that all other APIs that require permissions. The APIs that you propose that browser add, do not exist in a vacuum.

I already acknowledged that point by explicitly referencing the presence of other APIs and corresponding notifications.

You can't blame the browser for "doing a poor job of protecting the user from notification spam"

Yes I can.

and insist that the browsers add even more notification spam.

It's not spam. It's small in quantity, justifiable, and easily kept under control for reasons I already explained. You seem to be arguing for something like O(mn) scaling of notifications, where m is the number of APIs and n is the number of websites, but that's fundamentally inaccurate.

Also, you can't pretend that users are knowlegeable enough to understand what each of these permissions do. We know they don't.

I find that to be a very supercilious over-generalization. You seem to be portraying a world split into two types of people: "we", the imaginary group of clever people, who know best what "they" need, the imaginary group of poor dumb users who are incapable of looking after themselves. I want no part of such an unpleasant and inaccurate perspective.

You can't pretend that all this isn't relevant to the API you're so want. All in all you can't pretend this is an issue even though we know this is an issue.

I'm not pretending anything, despite your repeated assertions otherwise. I was trying to have a rational and non-emotional debate, but I can tell this has very little chance of being productive, so I'm out of this discussion and this will be my last reply to you.

[dmitriid]

It's not spam. It's small in quantity, justifiable, and easily kept under control

How is it "easily kept under control" when it adds even more notifications to the platform?

You seem to be portraying a world split into two types of people: "we", the imaginary group of clever people, who know best what "they" need, the imaginary group of poor dumb users who are incapable of looking after themselves.

You seem to imagine that I said or thought something I never did said or thought.

I was trying to have a rational and non-emotional debate, but I can tell this has very little chance of being productive

In order to have a rational and non-emotional debate you need to hear what the other people are saying, and not dismiss their reasoning out of hand just because you don't like it or because you keep ignoring the reality (the amount of APIs that require permissions, most users unable to understand implications of those permissions, the vast scope of these APIs etc.)

[dmitriid]

If you know they don't, please share that survey so that we can see it is not biased (e.g. based on Mozilla users exclusively).

• https://cups.cs.cmu.edu/soups/2012/proceedings/a3_Felt.pdf
  A minority of users demonstrated awareness and understanding of permissions

• https://www.researchgate.net/publication/367216696_Stuck_in_the_Permissions_With_You_Developer_End-User_Perspectives_on_App_Permissions_Their_Privacy_Ramifications
  a previous survey study has explored end-users’ understanding of what different permission requests meant, finding that end-user participants struggled to correctly identify what a permission request did (only 6.1% of participants answered
  all comprehension questions correctly)

  some end-user participants stated they had no idea how to remove permissions (57.9%)

etc.

[dmitriid]

it didn't sound like FUD when all of this happened to the Audio API, and it can't possibly be an acknowledgement of incompetency, so what does it imply exactly, could it be worked around as an extension or bound to a config flag disabled by default, or even limited to a different edition of Firefox (e.g. LibreWolf)?

Sorry, but I couldn't understand this question

[tobozo]

Even though it's android and not a desktop OS, it looks like most users understand the implications of permissions:

4.3 (...) end-user participants viewed the location, photos, and storage permissions as sensitive with privacy ramifications (a lot or above: 68%, 62.8%, and 61.8%, respectively)

And it's not surprising: a driver can understand the security and permissions of their vehicle without having to know anything about mechanics.

Sorry, but I couldn't understand this question

I'll rephrase: what does Mozilla's stance imply exactly, could WebUSB be worked around as an extension or bound to a config flag disabled by default, or even limited to a different edition of Firefox (e.g. LibreWolf)?

[dmitriid]

it looks like most users understand the implications of permissions:

Amazing, really. The studies: "A minority of users demonstrated awareness and understanding of permissions" and "only 6.1% of participants answered all comprehension questions correctly" somehow is perverted to "most users understand permissions".

This is nothing short of amazing.

And it's not surprising: a driver

https://en.wikipedia.org/wiki/Argument_from_analogy

I'll rephrase: what does Mozilla's stance imply exactly

It doesn't "imply" anything. It's loud and clear. The problem is you are willingly refusing to hear it, and imagine things that are not there while ignoring everything else.

---

On this note I'll bow out of this rather pointless discussion.

[bastian2001]

Since this discussion has moved to privacy rather than security concerns, my two cents: I don't see the problem. Never have I seen a website ask for permission to use a USB device that doesn't actually need it. I can see how enumerating USB devices without user consent can be a problem, but I don't see when a website would actually need that. The way that I know WebUSB works, is:

1. JavaScript asks the browser to show a prompt to the user to select a USB device
2. User selects a USB device and hits "ok"
3. Website has control over this one USB device
   The fact that the user has to select one specific USB device before the website can control it (i.e. the user has to do something and not just click ok), eliminates the fingerprinting concerns, if I am not mistaken. And I cannot see why the website should be able to list devices without user consent the way that was described with WebMIDI.

Maybe someone can tell me, what security or privacy concerns they can see, as long as these (easy to fulfill) conditions are both met:

1. When selecting the USB device, a warning is displayed that theoretically the website can gain full control over the PC (e.g. by flashing a microcontroller with malicious code that emulates a keyboard and does some cmd magic).
2. The website cannot do anything with WebUSB as long as the user did not actively select a device (not even list devices).

IMHO implementing WebUSB in browsers is even more privacy-aware because the alternatives (using other (less privacy focused) browsers that allow it or downloading full programs) generally have many more vulnerabilities.

[fabricedesre]

Maybe someone can tell me, what security or privacy concerns they can see, as long as these (easy to fulfill) conditions are both met:

You still have no guarantee that the code served by the site won't damage your devices, because trusting the origin of the code doesn't mean you can trust the code itself (eg. if an attacker replaced it by something malicious). This is less a problem with regular web APIs that can't have destructive behavior thanks to the web sandbox.

A better trust model for code is needed to enable these APIs, not just claims that "it works because Google does it and users are smart enough".

[bastian2001]

trusting the origin of the code doesn't mean you can trust the code itself

Trusting the origin means to me, that I trust the origin, so also the code that they give me (as long as it has not been tampered with). Just making this clear, but I think this is also not what you meant.

if an attacker replaced it by something malicious

HTTPS only + same domain for those parts of the script that access the USB device, the same as with service workers, would work, right?

not just claims ...

Where did I claim that it works because Google does it? What I said is, that the user has to do something other than just clicking ok for something bad to happen (they have to select a USB device). No user will randomly select a USB device and then click "ok" if the website has no reason whatsoever to access a USB device.

[fabricedesre]

HTTPS only + same domain for those parts of the script that access the USB device, the same as with service workers, would work, right?

No, HTTPS only ensures that no tampering happened in transit. That doesn't give you any kind of guarantee about the code not being replaced at the source by a malicious version.

[dev-nicolaos]

Maybe we need to step back for a minute. I think the main tension in this thread boils down to...

• USB access is a powerful feature and thus should require a high level of trust of any software that can make use of it. But...
• There's a low level of confidence that most users can make an informed decision about when to allow software access to said powerful feature.

Additional valid concerns:

• Some things users need to do simply require USB access. The existing approach is to download an executable which will have unlimited permissions, and is thus a larger attack vector than the web model where permissions can be allowed individually.
• The common browser UX of presenting a notification for each individual permission a site requests could cause a lot of friction for users on sites which need several permissions.
• A permissions model that only requires access to be granted once is vulnerable to an attack where a trusted site becomes compromised at some point in the future.

It strikes me that most of these concerns are not really unique to Web USB, though depending on your point of view, the stakes may be higher in this case (i.e. a bad actor with usb access can do worse things than a bad actor with webcam access).

With this context, I think there are two (maybe more) questions that need answers to move the discussion forward.

• What type of user action (in any system, not just the existing web platform) would give us confidence that the user was making a reasonably informed decision about the power they are giving access to?
  • Is there an example we could reference and/or look to for inspiration?
• Is it possible to rework the browser's permissions UX to address some of the concerns around too many notifications and "ask once for all time"?

[bastian2001]

not being replaced at the source by a malicious version

@fabricedesre I guess you are talking about signing the code? This is more than what most semi-famous software does, even for full blown programs/apps. Making this widely available could be expensive and throw off devs to only support Chrromium browsers

confidence that the user was making a reasonably informed decision

IMO the fact that the user has to select one specific USB device already mitigates the "just click ok" problem. A warning on that selection screen is sufficient if you ask me.

[fabricedesre]

@fabricedesre I guess you are talking about signing the code? This is more than what most semi-famous software does, even for full blown programs/apps. Making this widely available could be expensive and throw off devs to only support Chrromium browsers

Signing code is one way to do it, but not the only one. Trusting a known hash of the code can be enough - the tricky part being to bootstrap the trust chain. I found this approach interesting: https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/

IMO the fact that the user has to select one specific USB device already mitigates the "just click ok" problem. A warning on that selection screen is sufficient if you ask me.

I agree that using a device picker step is good API design to limit fingerprinting, but this doesn't tackle the "trusting code" part at all.

[martinthomson]

Thanks to everyone for the lively discussion, but I think that this has again gotten to the point where we need to take a pause. For an issue like this, where the original request has been resolved, we try to keep discussion open in case new information arises, so we'll reopen this again in a little while. For now, the discussion seem to have started to retread arguments that have already been made.