search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
653 stars 73 forks source link

Serial API #336

Closed computersarecool closed 4 years ago

computersarecool commented 4 years ago

Request for Mozilla Position on an Emerging Web Specification

Other information

According to https://github.com/WICG/admin/issues/108#issuecomment-626475273 there is no input from Mozilla. I hope Mozilla does provide input as this spec would be a useful addition to moving the web forward.

dbaron commented 4 years ago

Also cc @martinthomson.

marcoscaceres commented 4 years ago

cc'ing @reillyeon, who might be able to provide input on Chrome's status.

This has very similar security characteristic as Web MIDI, Web BlueTooth, etc. so probably the same concerns apply.

reillyeon commented 4 years ago

An MVP of this API is available as an Origin Trial in Chrome, and the feature can be enabled with a flag in other Chromium-based browsers. The specification is still a work in progress, with the prototype in Chromium allowing me to flesh out the details beyond the initial API sketch @marcoscaceres provided in the original specification. Time permitting I plan to finish updating the specification based on the prototype this quarter.

tomayac commented 4 years ago

There's a codelab written by @petele available to illustrate the mechanics of the API.

martinthomson commented 4 years ago

As @marcoscaceres points out, this shares a lot of characteristics with WebUSB (and friends).

It appears that the only security mechanism protecting devices from sites is user consent. And that is only at a "RECOMMENDED/SHOULD" level.

We don't believe that user consent is adequate protection for anything that provides this level of capability. Serial access is a relic from an age where a physical connection conferred a great deal of trust. For instance, many devices offer administrative control to anything that connects over this interface without any form of authentication; in my experience, this often extends to privileges that transcend even what a root user can do.

Even with the additional safeguards in the WebUSB spec, we still regard that as harmful. The dynamics are slightly different with serial than USB, but they seem at least comparable. Even if we could establish that the risks are manageable in the same way, the protections are also considerably weaker.

I'm going to recommend we mark this as harmful.

reillyeon commented 4 years ago

This is a somewhat pedantic point but since this has come up in other contexts I feel it is worth mentioning here. RFC 2119 defines "SHOULD" as,

This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

In the area of permissions I feel that "SHOULD" is an entirely reasonable requirement. For example, both Firefox and Chrome provide enterprise policy controls which allow an administrator to make policy decisions on behalf of their users. Chrome supports this for WebUSB permissions and would be out of compliance if the specification said that it "MUST" prompt the user.

kgiori commented 4 years ago

@dbaron -- I wish that I could understand this "harmful" position that Mozilla is taking for web serial, but I cannot. Am I wrong in presuming that such a position will likely keep Firefox from implementing it? If so, then K12 education in the area of "physical computing" (programming microcontrollers for data science collection, robotics, mechatronics, electronic music and art, STEM, and IoT) will need to run Chrome. I feel sad that educators will not have a choice of browser when it comes to teaching these important new technology subjects. :(

To point to a specific example, look at recent comments (May 25) to the webserial bug from jmaloney to better understand why web serial is so important. John created a recent video of cool 0.5 MicroBlocks features that shows how amazing this project is. The video shows how some microcontrollers can interact with the web as http clients (~14 min) or servers (~15 min), and how you can stream images and sound to them (~17 min). MicroBlocks also supports a "Web Thing" library that enables microcontroller boards to be directly managed and monitored (just like commercial IoT devices) by the WebThings Gateway by Mozilla (where the gateway's web thing API is close to the W3C Web of Things standard). These two projects work really well together, and are examples of amazing new tools for education that rely on the open web, and web standards.

Supposing users were allowed to enable web serial as an extension in Firefox, is there anything that could be done or run on the microcontroller side of things to help reduce whatever security risks there are? Can anyone provide an example of a product or service that might pose a risk to me if I was able to use a web serial extension in Firefox? As you can see, I'm looking for ways to overcome or work around the security risks to Firefox users so that I do not have to give up on using it... :(

bromagosa commented 4 years ago

I genuinely don't understand the risks either. What is it that is so harmful about serial access vs, say, the privacy risks involved in accessing cameras and microphones from the web, also secured "only" behind user permission?

I may be overlooking something, but WebSerial involves devices that have a serial interface, which I believe rules out pretty much every single end-user commercial USB device and puts this standard into a totally different category than WebUSB.

fabricedesre commented 4 years ago

The main issue is that it's impossible to get informed consent from the user with just a permission prompt for an api like WebSerial. It's pretty clear what the consequences can be when you allow a page to use your camera or microphone, much less so with an api that exposes a low level protocol.

Ultimately, this is an issue with establishing trust: how do you trust the page to not serve code that will damage your equipment? It's not enough to trust the developer, because its infrastructure can be compromised to serve harmful code. Web of trust doesn't help much either since you can target different payloads to different people. SRI suffers from a "trust of the root" bootstrapping issue.

Native platforms rely on code signing by their store: users trust the store editor to properly vet the app. This is also what FirefoxOS/KaiOS do with signed packaged to grant powerful permissions. Here the drawback compared to regular web pages is that you can't easily link into packages (they need to be installed first) and you may have to wait for updates to be approved.

That puts the web in a tough position. Maybe a solution would be to layer "store like" signing on top of web packages to preserve urls, or only allowing web-extensions to use these apis and verify these extensions are safe?

HenrikJoreteg commented 4 years ago

Just had a lengthy discussion with @marcoscaceres about all this on twitter. Twitter doesnt' make it easy to share it all, but it starts here: https://twitter.com/marcosc/status/1296677919813582848

Going to pull in relevant pieces here:

Marcos: If you tell me, "I can't build my business because my users can't do X", then I'm all ears. But, cases like "be cool if I had access to X because I want to fool around with X... not so much".

Me: This isn't a "would be cool" scenario.

Quick background: I built http://AnesthesiaCharting.com with a partner. We help doctors/dentists/oral surgeons/CRNAs produce "sedation records" which is a specialized kind of medical chart that you have to produce when you anesthetize someone.

Marcos: Go on... what can't you do?

Me: Biggest thing customers wanted after we built/launched our initial version was to pull patient vitals (heart rate, blood pressure, etc) directly off of vitals monitors.

These vitals monitors are not typically very modern, standardized, or easily upgraded.

Many of these that are out in the wild only have simple serial interfaces.

Or require local TCP connections.

Marcos: Ok, you are hitting on the problem. These devices were never designed to interface with an extremely hostile software environment.

So you need some kind of socket connection?

Me: At minimum I would love to be able to initiate a TCP connection to a known port. Ideally I would also be able to open a server and listen for incoming connections. I realize the latter is more complex.

My customers don't want to install anything. I don't want to maintain and ship updates to a distributed piece of software for multiple platforms.

And if I could just get this to work on the web... all these problems go away.

This is a huge deal to me.

This project is not some giant, corporate thing. My business partner and I realized we could possibly save a few lives from accidental deaths via mistakes that occur in anesthesia procedures.

Of course I want to make money with this, but only because I want to be able to work on it and similar problems.

Having a distribution platform like the web that has these types of APIs opens up whole new worlds.

Marcos: Let's just spitball here... you could connect the equipment to a server, then have the sever authenticate users, then proxy commands over web sockets... for instance.

Me: I did exactly that, actually. I wrote a node gateway server that would sit on the local network and broadcast data back to my API.

Think about what this does to my business model.

Instead of distributing software on the web... now I'm distributing hardware?!

This also sucks. Distributing/maintaining software updates to a distributed piece of hardware living on these local networks... Is a completely different game with a completely different set of constraints and costs.

If I want to be able to make a business out of this and keep costs low for customers thereby lowering costs of medical care, I need a way to make these connections.

What's the real risk of allowing a user to allow permission for me to connect to a specific IP/port they approve?

Marcos: It's the user that approves, not the machine... the machine doesn't assume you are hostile. You can then manipulate the machine, set it on fire, or do whatever you want if it's not expecting a hostile actor.

Me There's nothing new here. If I'm running software on your local network I can do whatever the hell I want.

The local gateway/server idea is not more secure.

This is a privilege every native app enjoys, no?

At least here we're talking about explicit permission.

The alternative here is that somebody does the exact same thing I'm doing with an iOS app or a really crappy Windows app.

Again, this is not more secure.

Just go ask oral surgeons how they do it right now 😅

Marcos That's not a net loss... the web has always lived alongside native apps and iOS/MacOS can be pretty secure (it hosts web browsers after all).

I'm not saying I'm giving up here. The responsibility of privacy/security needs to be shared amongst all parties.

Me What it does do, IMO... is limit who gets a shot it fixing these types of problems.

There's a whole other level of cost/complexity involved if you have to distribute/update/maintain software for a plurality of platforms. The magic of the web is that it removes so many barriers.

Centralizing API access through the web is an incredible tool for leveling the playing field for humanity as a whole (going back to Mozilla manifesto).

Instead of needing 3 full teams of devs for 3 years I can ship an app myself that potentially lowers medical cost for many.

That is a big deal to me.

This is about access....and wow as you mentioned... think about education.

Holy shit! Can you imagine how much amazing stuff could be produced if we lowered the barriers to entry like this? Would be incredible.

Marcos: I personally think it's a game changer. But I don't represent Mozilla or their position on the matter (link below for those following along).

And I also understand what Mozilla's concern are. They are valid.

Me: They are valid in isolation.

I believe if you look at the whole threat model... that the alternatives are worse.

In terms of holistic impact... preventing evolution of these APIs is just leading to crappy workarounds.

I really appreciate you hearing me out.

As I said in another conversation this week... disagreements just mean that people care.

What I'm trying to provide is a concrete example of a real-world use case that I believe is significantly improved by adding these APIs to the web ❤️ https://mozilla.github.io/standards-positions/#webserial

HenrikJoreteg commented 4 years ago

for additional context, the final outcome of these not being available is me building/maintaining an Electron app. I first built an iOS app that was rejected for not using IAP.

Distributing cross platform software sucks, by which I mean, it's prohibitively complex, expensive, and time consuming. (EV code signing anyone? https://twitter.com/HenrikJoreteg/status/1295563511863549953).

Anything that is possible through the web, dramatically levels the playing field and lowers the barriers to entry.. which i feel would ultimate help Mozilla live up to its manifesto.

That is why I always have and will continue to bet on the web. I also wrote a whole post about adding shiny new capabilities to the web and why I think its so important ❤️

gniezen commented 4 years ago

I'm very much in the same boat as @HenrikJoreteg . I help to develop and maintain the Tidepool Uploader, enabling people with diabetes to upload their device data. These devices include blood glucose meters, CGMs (Continuous Glucose Monitors) and insulin pumps, and the data from these devices help them manage their diabetes and facilitate discussion with their clinicians. Most of these devices communicate using serial over USB, so serial access is definitely not a relic from a different age. These are modern consumer devices used by millions of people with Type 1 and 2 diabetes every day.

At the moment the Tidepool Uploader is an Electron app. Why is this a problem?

Why do we want to have a serial API in the browser?

I would argue that adding a serial API to the browser is the opposite of harmful - it improves safety and security. Why force people to install software that has root access to their machines, when you could use a web app running sandboxed in the browser instead, with a standardised method of interacting with their devices?

Also, I think we should stop patronising users by thinking they won't understand user permission prompts. The onus is on the browser vendors to make these clear and easy to understand, not the users.

andreicristianpetcu commented 4 years ago

Chrome team: users don't understand URLs, we need to simplify them. It's easy to trick/phish users. Also Chrome team: let's give any web site permission to access any serial devices.

I understand the medical device need but the risks are huge. Maybe a WebExtension API, not a web API, is a better fit since there is an approval process and blacklists for abusers.

HenrikJoreteg commented 4 years ago

@andreicristianpetcu where can I read about the risks and the threat model used that led to the determination that the "risks are huge"?

People are going to connect to these devices either way. We either help make it as secure and obvious to the user as possible... Or we ask them to install some app that has access to everything.

I think it's important that the threat model includes what happens otherwise: poorly supported, quickly thrown together, electron apps not getting updated when there are security issues. At least on the web you can blacklist a domain at a browser level.

For the web, we're talking about somebody physically having to plug something into their device (that right there pretty much eliminates most mobile phone users). Then they have to explicitly grant permission by selecting the specific device from a list. And the web page has to know enough about the device it's communicating with to properly use the protocol that that particular serial device uses (these are anything but standard from what I've seen so far).

I fail to see how installing some sort of native app/driver from somewhere is more secure.

fabricedesre commented 4 years ago

I think a fair characterization is:

The Chrome side argues that the progress made justifies shipping the web version, some other vendors disagree.

If you are worried about medical devices vendors not properly supporting their native apps, there is also a risk that they don't have good enough security on their web properties and that someone manages an attack that can be both non obvious to detect (so no quick browser blacklist) and devastating for the users.

HenrikJoreteg commented 4 years ago

@fabricedesre where can I read about the risks and the threat model used that lead to the determination that the risks are "devastating for users"?

HenrikJoreteg commented 4 years ago

@fabricedesre has the existence of WebUSB proven to be devastating?

kgiori commented 4 years ago

Chrome (and Edge) allow MicroBlocks, an amazing learning tool for physical computing, to run in the browser if a specific chrome flag is enabled. Check out MicroBlocks in your browser here.

The value of a Web Serial API for browsers is that is allows an educational application like MicroBlocks to program USB-connected microcontroller boards, such as the BBC micro:bit. That value is huge. (Again, Chrome works, Firefox does not.) There is a native MicroBlocks application, but installing it can be tricky, and is usually not allowed by students or even educators. Sadly, as MicroBlocks takes off in K12 education, using Firefox won't be an option. Users will choose the tool that does the job for them. By blocking web serial in Firefox, no protection is being offered to these educational users because they will simply be using Chrome instead.

fabricedesre commented 4 years ago

@HenrikJoreteg : @gniezen describes a tool "enabling people with diabetes to upload their device data". Just altering the readings can put these users at significant health risk.

About WebUSB, absence of proof is not proof of absence. It's not been a major issue because usage is likely very low. Wait for it to be an interesting target before making any conclusion about it being safe. I don't expect to convince you that the current security model is not strong enough, but please stop make these false equivalences.

fabricedesre commented 4 years ago

@kgiori the disagreement is not about "can this be useful". It's about "how do we expose that safely for all". Not doing anything is not acceptable, but the "relaxed" approach from chrome is not either.

I think @andreicristianpetcu idea of exposing some of these apis to web extensions and not directly to web sites is an interesting one that could help sandbox the dangerous bits to a signed code package.

kgiori commented 4 years ago

@fabricedesre and @andreicristianpetcu -- is there example code or more information on how to make MicroBlocks work (communicate to a USB-connected microcontroller board) in Firefox through a web extension? Installing a web extension is better than no chance at all.

tantek commented 4 years ago

In response to (most of) the continued commentary here.

This issue is not the place to make pitches for use-cases.

While we (Mozilla) are definitely sympathetic to use-cases that help users, a better place to capture those is either on your own blog with blog posts, or perhaps as pull-requests to add them to the respective Explainer, e.g. in this case:

https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md

Better yet both, so you can fully express the use-cases yourself and then cite them with a brief summary in the Explainer.

On the specific medical use-cases provided, if anything these are great examples both in terms of greater potential harm to users, and more vulnerable infrastructure due to systemic IT process issues. Those are both good reasons to expose fewer potentially risky features, not more.

(Originally published at: https://tantek.com/2020/234/t1/)

HenrikJoreteg commented 4 years ago

@fabricedesre making "false equivalences" was certainly not the goal. I was trying to think of the closest thing that exists that might give some idea of the impact of something like this because my understanding was that similar conversations were had there.

Regarding the diabetes example. I have type 1 diabetes, since 2000, to be exact. The lack of access to device data is a far bigger problem than worrying about someone mucking with the data when uploading historical bloodsugar information. That's not what's used to make immediate treatment decisions, it's simply establishing historical patterns. If it was modified it would be pretty obvious. But more importantly, what motivation exists to do such a thing? Someone would need to figure out how to talk the required serial protocol to communicate with these devices. They would then need to manipulate that data (to what end, or for whose benefit is unclear). They would then need to get you to visit their site, and agree to upload your historical blood sugar data. What would this gain them?

Anyway, that's all a bit of a distraction to my point:

Is there a threat model document, or something outlining the explicit dangers we are exposing users to here? Something that explores this in real world scenarios that also takes into account the other means that exist to accomplish the same goals?

As @kgiori pointed out, and as I said too, the end result is just telling more users not to use Firefox. Firefox isn't protecting anyone if users just use other tools to do the same thing.

I'm still waiting to hear what about Chrome's implementation/approach is so problematic.

reillyeon commented 4 years ago

Chromium supports the Serial API in extensions, as they are just another origin which can be granted permission to access a device. Limiting support in Firefox to code loaded from signed extension packages seems like a reasonable path forward to gain multi-implementor experience on the API.

fabricedesre commented 4 years ago

@HenrikJoreteg the threat is that code can be changed server side without the user noticing because you can't bootstrap a trust chain. From there, the scenarios are only limited to attackers imagination.

ekr commented 4 years ago

Is there a threat model document, or something outlining the explicit dangers we are exposing users to here? Something that explores this in real world scenarios that also takes into account the other means that exist to accomplish the same goals?

This question is properly directed at the proponents of that API. It's not our job to do that threat analysis in this repo.

There has been some discussion of this in the WebUSB issue, which has similar properties.

In terms of "so problematic", our belief is that users will find it very difficult to give informed consent. Therefore, to the extent to which this API is risky (in part for the reasons that Fabrice indicates) that consent is not an adequate defense. FWIW, it is well known that medical devices are often highly insecure: https://www.nsf.gov/cise/cns/watch/talks/fu.jsp. Consider the case where a user is invited by the Web site to upload some of their medical data and in reality the Web site rewrites the firmware on their device.

andreicristianpetcu commented 4 years ago

Consider the case where a user is invited by the Web site to upload some of their medical data and in reality the Web site rewrites the firmware on their device.

And then offer a bitcoin address for ransome.

computersarecool commented 4 years ago

And then offer a bitcoin address for ransome.

😂😂😂

@andreicristianpetcu Now that was funny.

I am interested in this logic though... "I trust the website enough to upload medical data (which I think is right up there in terms of financial data in terms of stuff you want to protect) but whatever they did to make me trust them enough to do this concealed the fact that their true goal was to rewrite the firmware on my phone..."

I also think this is an example of where user notification would be enough to prevent the problem. "I am trying to upload a document, why is it requesting serial port access?" I think this would seem weird to most users...

Any native program you download from the internet, any game you download, could access the serial port. Are people going through every line in the Firefox source code to ensure it is is safe before they compile it and use it? Are people checking these NPM modules that they install?

How about PUTTY which actually uses the serial port... It is downloaded directly from a website (no signatures or anything) and people just run it.

This thread makes me feel like browsers will never be able to have native device access. They just can't do it for safety reasons. It is not possible under the current structure of the world wide web, and nobody even can explain how to do it.

I think though, that is malarkey and hopefully, in time, anybody feeling this way will think it is malarkey as well.

andreicristianpetcu commented 4 years ago

I'm not sayng browsers should not have serial access, I'm saying they should not have it on the web. A WebExtension API would be secure enough. WebExtensions go trough code review, can't run remote code, are digitally signed and can be blocked by browser vendors.

I think the WebUSB should have been a WebExtension API. Now let's all hope I'm wrong.

SuperUserNameMan commented 4 years ago

the threat is that code can be changed server side without the user noticing because you can't bootstrap a trust chain. From there, the scenarios are only limited to attackers imagination.

Very funny. If that's the way to think, then you should display a warning with an "uninstall Firefox to be safer and disconnect your device from the internet" button each time a user launch Firefox.

PS : Look, just after posting this comment, i checked my emails and found I received a fake "Virus Notification" from i duno which scammer. They want me to download the "Quick Virus Scanner" they attached to the mail (it's a html doc) and to press the "scan now" ASAP because they want to save me computer. How safe am I if I'm naive enough to believe them ? What if they ask me my credit card number to make me buy an fake antivirus after frightening me with a their fake virus-scan ? Why Mozilla Firefox did not disabled the functionalities that would have made the web safer and prevented these scammer to scam me using a fake email and a fake HTML virus scanner ? Where is the real weak point in that trust chain ?

andreicristianpetcu commented 4 years ago

@SuperUserNameMan do you think a webextension api is more secure, less secure or equally secure to a web api?

SuperUserNameMan commented 4 years ago

@andreicristianpetcu :

@SuperUserNameMan do you think a webextension api is more secure, less secure or equally secure to a web api?

I don't care.

I just don't want Firefox to become the Internet Explorer of the future ( ie : the navigator that slows down the internet evolution and make innovation a PITA just because the devteam don't want to follow the trend imposed by others and because of an irrational fear of the "unlimited imagination of some imaginary hackers" who already plague the web using simple emails with an html attachment).

Also, unlike Internet Explorer (and the new Microsoft Edge) that was preinstalled on almost every computers, installing Firefox is purely optional or is almost a political choice. As the Serial API is slowly becoming a must-have in some growing DIY electronics communities and in more and more schools, the refractory and aging Mozilla Firefox will slowly lose market share by becoming an very optional relic of its own glorious past. Not mentioning that Google Chrome is the perfect extension to Android devices that almost everybody on Earth have.

A web extension would certainly make Firefox "safer" for most of its user base since installing the extension would require a relatively complicated and conscientious action from the user, but will it prevent the unlimited imagination of the hackers and scammers from hacking and scamming ? No, it will just make the life of some Firefox users a little bit more complicated, and little bit more inclined to use Google Chrome (which can be installed on Linux BTW) .

mlyle commented 3 years ago

I'm just here to note that there's a whole lot of educational use cases. It's hard to get students to install extensions, Electron apps, etc.

I teach a middle school class that I've written a web-based IDE for-- it talks to embedded micropython development boards with webserial. I like Firefox but effectively I am put in the position of pulling people over to Chrome, instead.

jamesturner246 commented 3 years ago

What's wrong with adding an option to about:config? That way there's little chance of a lay user accidentally activating it, while the users that wish to are implicitly competent and aware of the risks? There's even a giant 'Proceed with Caution' warning for free.

mmiscool commented 3 years ago

It seems like a mistake to lump this in to a category of low level hardware access. Its not especially low level to access a serial port and the positive interaction from the user to select the specific serial device seems like more than enough. Why force some one to possibly install a less secure thing like an extension or other program that actually needs to run outside the browser sandbox to make the user interact with a serial device. I believe that the decision to label this harmful is a mistake and that the excuses as to why it is a security concern are week at best and disingenuous at most. Forcing a user to install some thing outside of the browser sandbox is dangerous and the positive implications of this kind of API are clearly evident for the maker community, schools and hardware developers. Serial is an ancient technology and not making it easy to work with for the development platform of the future seems like a short sighted decision.

kgiori commented 3 years ago

I'm just here to note that there's a whole lot of educational use cases. It's hard to get students to install extensions, Electron apps, etc.

I teach a middle school class that I've written a web-based IDE for-- it talks to embedded micropython development boards with webserial. I like Firefox but effectively I am put in the position of pulling people over to Chrome, instead.

The ability to run MicroBlocks in the browser -- http://microblocks.fun/mbrun -- is similarly driving learners of physical computing to Chrome, due to its web serial support. Sad to see Firefox not supporting education.

fabricedesre commented 3 years ago

The argument of "Forcing a user to install some thing outside of the browser sandbox is dangerous" just ignores that the same API in the browser would not be sandboxed either: a device chooser doesn't protect you against malicious code being served.

Exposing this kind of APIs to extensions only - since they are signed, can be revoked etc. looks like a better solution to me (disclaimer: I have no weight on Mozilla's decisions).

sbrl commented 3 years ago

I appreciate it's is potentially dangerous, but at the same time there are a lot of excellent applications here. The question I think here is how to communicate the risk effectively to users? And also how to limit the risk of malicious code being run?

What about requiring Subresource integrity and/or a content security policy or something?

The other idea of a web extension api is also interesting.

Edit: It's not a valid argument, but given that people are using Chrome to do this anyway, is there something Mozilla/Firefox can do to provide a safer experience?

Disclaimer: I don't speak for Mozilla, and I don't have any connection to Mozilla other than using Firefox

fabricedesre commented 3 years ago

SRI still needs something to bootstrap the chain of trust, to be sure the page linking to the subresource has not been tampered with.

crozone commented 2 years ago

Mozilla's stance on this is still incredibly frustrating. This is not USB access, it is not low level device access. It is a feature that allows a user to consent to a web page sending and receiving text out of a single, specific, user specified hardware port. The user chooses exactly what serial port to use, not the website. It's really a high level API in the scheme of things. In terms of risk characteristics, I still fail to see how serial access is more dangerous than microphone access, camera access, or even allowing a user to download a file.

This feature is becoming more and more important in educational settings with MicroPython microcontrollers communicating with Web IDEs. Currently users must use Edge and Chrome to accomplish this. And guess what, users will just use Chrome and Edge for this purpose, and Firefox will not be used in those settings. Users like me will have to run both.

So on the topic of security... if a malicious website asks a user for serial port access, and then the user happens to have their heartrate monitor plugged in, and the user then selects the heartrate monitor, sure, that could be bad. But newsflash: If a malicious website asks you to download a random .exe, and the user runs that, the consequences are going to be far worse.

At some point, you're going to have to respect that users need to be able to make their own decisions regarding risk, Having a consent dialogue, just like every other browser that implements this, has proven to be perfectly adequate. In addition, the overlap of Firefox users and people who need this serial feature, are more than capable of assessing that risk themselves anyway.

Just my 2c.

NuclearPhoenixx commented 2 years ago

But newsflash: If a malicious website asks you to download a random .exe, and the user runs that, the consequences are going to be far worse.

While we're at it, we should disable the download feature so that people don't keep downloading virus.exe to their heart rate monitor.

kgiori commented 2 years ago

Here's an EdTech example for programming microcontrollers -- my favorite educational programming and learning tool is MicroBlocks: https://microblocks.fun Of course it runs directly in Chrome or Edge but not in Firefox. Can Firefox at least create or enable the user to create an "allow" list of educational websites like MicroBlocks to be allowed to run WebSerial?

HenrikJoreteg commented 2 years ago

In reality, if Firefox doesn't support it, nothing changes for us.

Those of us who need these features will simply continue to tell of it customers to download Chrome or Edge if they want to use our software.

That's the ultimate impact of not supporting these features. And no, that is not a hypothetical, that is literally what we tell our customers and so far we have gotten precisely zero complaints about it.

In fact, that linked page is a good example of the ultimate impact of not supporting these APIs.

I'm not sure Mozilla ultimately protects anyone by holding this stance.

mmiscool commented 2 years ago

My position on this has changed. The right answer is just to detect if the user is using firefox and prompt the user to install a browser not controlled by paranoia.

thorrak commented 2 years ago

My position on this has changed. The right answer is just to detect if the user is using firefox and prompt the user to install a browser not controlled by paranoia.

This is what I currently do with my project that uses Web Serial.

NODeeJay commented 2 years ago

I'm not sure Mozilla ultimately protects anyone by holding this stance.

They are protecting Chrome, Edge, Opera and even the Samsung Internet browser. It's like parents which don't want to take the time to educate children but prefer to forbid something, the easy way out but not on the long run.

Maybe Mozilla, it's time to step down from the arrogant horse of authoritarian overpatronizing your users and start listening to them, as long as you have users left because you force them to use other browsers.

@fabricedesre sure, the thread is that every page can do what it wants. Driving is dangerous, that's why we have rules. Limiting a certain service to access only certain sites is a solution, NoScript effectively does it that way. Maybe the certificate can also be checked for that connection, oh wait, we do that already on any site. I am actually more concerned about your partnership with Meta, the privacy friendly company from Mark Z. But that's none of my business. Oh wait, as a user it is. And recently a new FF offers Yandex.RU as a search engine, this is most probably from my current point of view not just "problematic", but hey, WebSerial is dangerous.

@tantek the fact that users don't stop writing in this thread should show you enough about their loyalty towards this browser. Obviously it is the wrong place as usual and surely the questions is asked wrongly and OP surely has some typos in his post and most probably it's the wrong color... In fact they want to help you to keep a user base at all, they care about you. They are interested in a bright and secure web future with a good browser. It's not that WebSerial is a nice cherry on a Sunday, it's a need. As @gniezen pointed already out: if you don't fulfill it, users have to change, YOU force them to move on to a less secure browser. So in the end this position does not help, it harms your users because the options we have are knowingly way worse (Chrome, Edge, Samsung Internet, Opera). But at least you still get around $ 400 mio from google (https://www.zdnet.com/article/sources-mozilla-extends-its-google-search-deal/) yearly, I know, my 100 bucks donation last year are not in comparison.

Firefox went down from 38.1% in 2010 to under 3% today (https://www.w3counter.com/trends), please stop trying that hardly to leave all up for Chrome in the end, please, we need you Mozilla, with WebSerial and WebUSB!

fabricedesre commented 2 years ago

It's like parents which don't want to take the time to educate children but prefer to forbid something, the easy way out but not on the long run.

A more apt metaphor would be that chrome is like parents who let children do whatever they want, at the price of some of them getting hurt, while Mozilla prevents them all from being hurt until a solution is found to protect them all. The issue is that Mozilla is not trying much to find that solution imho.

the tread is that every page can do what it wants. Driving is dangerous, that's why we have rules. Limiting a certain service to access only certain sites is a solution, NoScript effectively does it that way. Maybe the certificate can also be checked for that connection, oh wait, we do that already on any site.

No, the threat is that an attacker could change the code served by goodsite.com into something problematic.

NODeeJay commented 2 years ago

It's like parents which don't want to take the time to educate children but prefer to forbid something, the easy way out but not on the long run.

A more apt metaphor would be that chrome is like parents who let children do whatever they want, at the price of some of them getting hurt, while Mozilla prevents them all from being hurt until a solution is found to protect them all. The issue is that Mozilla is not trying much to find that solution imho.

I agree, or not willing to.

the tread is that every page can do what it wants. Driving is dangerous, that's why we have rules. Limiting a certain service to access only certain sites is a solution, NoScript effectively does it that way. Maybe the certificate can also be checked for that connection, oh wait, we do that already on any site.

No, the threat is that an attacker could change the code served by goodsite.com into something problematic.

Correct. As he/she could change the code when I download the bin/hex/... file to upload to an ESP. This threat is usually prevented by adding a hash verification, which still does not prevent the attacker from creating a new hash and posting it on the site, which still does not prevent the attacker from doing:

Life itself is unfortunately the biggest threat to our lives, still we take risks. What I want to say is that there are so many risks out there that ultimately only our own death can protect us from them, still we live and take the risk everyday. When Mozilla forces its user to change to a less secure browser, than Mozilla is the harmful threat, repectively those who took the decision there - we are also responsible for the things we do not do.

But there is an easy solution:

and I am ready to write a proper documentation that scares the shit out of the user who wants to flash his ESP at home. Or the poor factory worker that gets instructions by the manufacturer to quickly FW upgrade his CNC machine that he continue his work. Or the diabetes person who has an issue with his pump and the support personnel is trying to debug the issue. Or the children in school which make the LED on the board blink through MicroBlocks. I really don't want to image what would happen if an attacker would let the LED blink red instead of green...

This is from my POV a new level of ridiculousness and arrogance.

Anyway, plenty of proper solutions were named, not just in this forum, also on hackster, reddit and other corners of the internet. Mozilla needs money to run their servers and provide the service. Mozilla gets mainly paid by Google/Alphabet for installing the search engine as default. This is surely calculated based on the amount of downloads/installs/etc. We still 2.6% loyal users warned Mozilla enough, Darwinism will resolve the issue.

Mozilla wants to be like Netflix and Kodak, though times are ahead but then it will be better - hopefully.

Edit reason: typos

NODeeJay commented 2 years ago

My position on this has changed. The right answer is just to detect if the user is using firefox and prompt the user to install a browser not controlled by paranoia.

This is what I currently do with my project that uses Web Serial.

Do you mind sharing some code. JS or whatever? This could be used as a real solution now. What I have in mind, when users go to that site and they have the right browser installed, it starts the site in the right browser that has WebSerial enabled. I saw this feature with Edge when I open pages in IE that are not supported but I did not dig into it yet.

NODeeJay commented 2 years ago

Additionally, based on https://github.com/mozilla/standards-positions/blob/main/CONTRIBUTING.md I am hereby asking Mozilla / @martinthomson to update the position on this topic.

Why: Many solutions have been provided in the meantime to fulfill this request in a secure way, and also many ways of securing the access itself. Hiding these settings for the experienced users is a better way of implementing it, than no implementation at all, for example:

Furthermore, I am pointing out your core values: Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent. Most important here is that you empower us in a safe and independent way!

I therefore kindly urge you to revise your stance on this topic.

Thank you.