Request for position on Serial API

[computersarecool]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Serial API
• Specification or proposal URL: https://wicg.github.io/serial/
• Caniuse.com URL (optional): NA
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=webserial
• Mozillians who can provide input (optional): @marcoscaceres

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.

[thorrak]

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.

Here's the code that I'm using in my project: https://github.com/thorrak/brewflasher_web/blob/e6b152c0a676845edfafc1d8248ec2078780fdbf/src/FirmwareDirect.vue#L69

[ocdtrekkie]

As a note, really glad to see Mozilla holding their ground here. I know it's rough to make the right call when so many selfish and lazy developers are demanding you put billions of users at risk to serve their thousands of niche tech users.

Positions like this continue to be why Firefox is the wise choice for enterprise and general consumers alike from a safety and security standpoint.

Web Serial remains a proprietary API with a single implementation written by a company with an active interest in harming consumer privacy and security. It isn't a standard, and we should stop acting like it ever will be.

[mlyle]

@ocdtrekkie-- I find your comment laughable.

As a note, really glad to see Mozilla holding their ground here. I know it's rough to make the right call when so many selfish and lazy developers are demanding you put billions of users at risk to serve their thousands of niche tech users.

I am a middle school teacher. I just want to stop telling students in my class to install Chrome. I have an IDE that lets them do microcontroller development from the browser.

Positions like this continue to be why Firefox is the wise choice for enterprise and general consumers alike from a safety and security standpoint.

Asking the user whether to do it is pretty damn safe.

with a single implementation

Chrome, Edge, and Opera-- all Chromium derived, sure, but all support it.

written by a company with an active interest in harming consumer privacy and security.

Yup. And it doesn't harm consumer privacy or security. On the other hand, the lack of it in Firefox makes me move students to the platform that does harm consumer privacy and security.

80%+ of my students already have Chrome. Moving the 20% of them that don't to Chrome is more tenable than installing something dodgy to do development on 100% of machines, even if I find it icky.

[ocdtrekkie]

I find your comment laughable.

Great way to start your reply.

I just want to stop telling students in my class to install Chrome.

Then stop. That's entirely your decision to harm your students.

I have an IDE that lets them do microcontroller development from the browser.

I recommend finding an IDE that doesn't require the modern equivalent of ActiveX to work. Proprietary Chrome features come and go every day.

Asking the user whether to do it is pretty damn safe.

This is kinda where you really went off the rails though: This tells me you don't know much about user interaction with technology, which like... you should if you're teaching microcontroller development in middle school. Please pay attention here, and let me help: Users will click literally anything that lets them proceed, and likely, won't even remember doing it. This is true in schools, in enterprise businesses, and in homes. It's universally the case that asking the user if they want to do it is not at all safe.

all Chromium derived

As I said, a single implementation written by Google. Edge and Opera didn't reimplement or likely even meaningfully vet this code, they're just in the business of running Chrome forks.

And it doesn't harm consumer privacy or security.

False, and both Brave and Mozilla browser security teams disagree with you. (And understand user safety more, see above.)

Moving the 20% of them that don't to Chrome is more tenable than installing something dodgy

I'm not sure what you'd refer to that could possibly be more dodgy than Chrome. To be clear: Chrome is the only browser refusing to block third party cookies going on a few years now, because they won't do it without implementing a different way to invade user privacy first. Chrome is, by any reasonable definition, adware, and should probably be blocked by your security software. It is by mine.

[mlyle]

Great way to start your reply.

Your opening salvo was to refer to us as "selfish and lazy developers". If you didn't want a flamewar, maybe you should have picked a gambit that allowed room for reasonable conversation.

I recommend finding an IDE that doesn't require the modern equivalent of ActiveX to work. Proprietary Chrome features come and go every day.

I wrote it. It's a much less user-hostile thing than anything else I found for students to install. (edit: and in general, asking students to install -anything- is problematic; asking a few to use Chrome instead [only one has had to actually install it] is yucky because I want there to be choice in the browser world, but it is likely to work and be less harmful than the alternatives.

Users will click literally anything that lets them proceed, and likely, won't even remember doing it.

Speculatively popping up a "pick a serial device" dialog on lots of peoples' machines-- in hopes that they find they correct device you want to exploit, select it, and click "permit" doesn't seem like the most likely attack scenario to work or the low hanging fruit.

Most users don't even have serial devices, today. Those that do are likely to be power users.

Chrome is, by any reasonable definition, adware, and should probably be blocked by your security software. It is by mine.

Ah, we've got Quixote here wanting to prohibit the thing with 70% market share from end-user controlled devices. That's a practical plan.

[ocdtrekkie]

@mlyle Ah. So you wrote the bad software, and want to force billions of users to have a more vulnerable platform to cater to it. That explains it much clearer, I appreciate that.

The core problem here, is that yes, users will absolutely select an enumerated device and let a random website connect to it. How do I know? I see stuff that dumb every single day. Browsers need to support people from ages 6-106 as LEGO like to put it. Your students can install a piece of local software, and I bet you can even write that too.

Also, one of the recent issues has been attacks on industrial control systems. In one example, a site offered a tool explicitly to help ICS operators, which also took malicious actions. In that case, a user would absolutely authorize it, and they'd permit malicious activity. Of course, here's the key point: It is drastically easier to monitor, secure, and block separate software and processes. Hiding this inside chrome.exe makes it very hard to secure... which is actually Google's primary motivation for injecting so many features directly into the browser. Following Google's lead here is to intentionally make other browsers as compromised as Chrome already is.

[mlyle]

Ah. So you wrote the bad software

I did my best as an engineer and teacher to find something that was low impact that would allow my students to do their work. If you want to sneer at me about that, then you are just not being very nice.

I still don't know of a better option. I wasn't super excited about writing an IDE. and I wasn't super excited about requiring Chrome. In the real world, we don't get exactly what we want.

In one example, a site offered a tool explicitly to help ICS operators, which also took malicious actions

So, the users downloaded and ran a tool and explicitly authorized it to talk to controls. Perhaps Firefox should not allow downloading programs to preclude this type of attack.

Of course, here's the key point: It is drastically easier to monitor, secure, and block separate software and processes.

It is somewhat easier. Of course, if the real intent is to prevent malware from talking to the industrial control system, perhaps the better angle is to use an explicit allow list for what can instead of giving everything on the computer permission and hoping users don't manage to run the wrong thing.

Following Google's lead here is to intentionally make other browsers as compromised as Chrome already is.

I've always thought that it's important in a conversation to presume good faith. Any argument that the engineers on Chrome are actively trying to make the web a less secure place to somehow make Chrome look better leaves no room for discussion, and doesn't seem particularly likely-- and it kinda fails on Occam's Razor.

[ocdtrekkie]

I still don't know of a better option.

I would probably either use one of the numerous cross-platform UI toolkits that lets you use HTML for the frontend, or stand up a quick web server on localhost so that it works in any browser. I think there's a lot of solutions here that don't involve proprietary browser features.

It is somewhat easier.

It is significantly easier to monitor external processes than what the dozen some-odd Chrome processes are all trying to do on a PC. In my environment I have a dozen ways to monitor, block, and restrict processes. Web traffic is far more difficult to restrict as well, especially if you don't disable all of Chrome's security-defeating protocols. Obviously, in the office we generally use policies to cripple nearly all of these antifeatures in browsers we permit, but it's a constant game of whack-a-mole because Google adds a new one every time someone wants a promotion and a cool demo for their Google I/O talk.

I've always thought that it's important in a conversation to presume good faith.

It is. However, once someone's shot you in the head, you don't have to assume they're in good faith anymore. We are several years past the point where Google had numerous opportunities to make ethical decisions that help make the web more secure, and they have chosen ad revenue every single time. It's nearly impossible to have a browser standards discussion without the understanding that Google is absolutely acting in bad faith, and that they will do anything they can to harm the open web.

[mlyle]

I would probably either use one of the numerous cross-platform UI toolkits that lets you use HTML for the frontend, or stand up a quick web server on localhost so that it works in any browser. I think there's a lot of solutions here that don't involve proprietary browser features.

One to one, and student owned devices. You're describing me running a service on 30+ student owned computers, including a few Chromebooks. I won't get parent permission for all of them. It will not work on all of them and I'll get stuck for hours doing support.

In the end, Chrome is the closest thing to universal in the student environment; everyone has it, even if a few prefer Safari or Firefox. And every thing that Firefox does like this in the name of "sek00rity" makes it harder for those preferring other browsers to keep using them.

and they have chosen ad revenue every single time.

Serial doesn't benefit their path to ad revenue-- well, only indirectly. When Firefox forces many of us to use Chrome to get the feature, they get our eyeballs.

[mlyle]

@ocdtrekkie In the end, bruh: I'm not a dummy, selfish, or lazy. I know a whole lot about security and development, and implying anyone who disagrees doesn't is an asinine way to make an argument. I'm trying to bring really deep undergraduate level curriculum to the middle school environment, and very reluctantly writing a whole lot of tooling and doing a whole lot of desktop support to make it happen. There are very few perfectly tidy solutions that work.

[ocdtrekkie]

Well, neither userspace apps with cross platform UIs nor serving web content on a high number port requires admin access...

including a few Chromebooks

And there we go, now we've come to the truth. The only solution that works on proprietary Google products is a proprietary Google API. And everyone need be compromised to support Google's netbook platform.

Again: Users will click literally anything to proceed. Chrome is a veritable soup of tracking and malware vectors, a feature like this is dangerous and poorly warranted for the relatively niche crowd of microcontroller developers. I don't think the cost of implementing this antifeature is worth the benefit of a handful of Chromebook users being able to play with a micro:bit. I hope Mozilla holds firm here.

[mlyle]

And there we go, now we've come to the truth.

Not very many Chromebooks-- even without them, we would still get pointed this way, though.

[SuperUserNameMan]

Oh ok cool ...

So basically, maybe Firefox should be advertised this way instead :

---

Because else, I wonder why dumb lazy people would bother installing Firefox (or even Google-Chrome) by themselves when they already have a default web-browser available on their Windows, MacOS or Android devices that perfectly does every dumb thing they already need to do on the web.

Willing and being able to install Firefox seems a pretty over-complicated dumb thing to do for a dumb lazy web-surfer ... why in the hell would they want to do that ? Even Microsoft Widows tries its best to prevent this behavior ...

Wouldn't it require a certain level of awareness and intelligence ?

And what does it tell about all these Linux users who ends-up with Firefox preinstalled on their favorite niche distro ? I guess they must really be this kind of dumb lazy users who would click anything that pop up on the screen just to proceed to the next page ...

[ocdtrekkie]

@SuperUserNameMan You sure put a lot of effort into flaunting your personal superiority over the security teams of every single web browser developer that isn't an ad company.

[mlyle]

@ocdtrekkie You put a lot of effort into personal attacks and selective mischaracterizations to troll on GitHub.

[NODeeJay]

Dear @ocdtrekkie, it is in my POV very sad how you jeopardized this still technical conversation. You ignore all good rules of a rational debate (https://en.wikipedia.org/wiki/Wikipedia:Rational_debate) including but not limited to:

1. "[...] why Firefox is the wise choice for enterprise and general consumers [...]" implies that all others are dumb & "[...] So you wrote the bad software [...]" just to name a few. 2. "[...] This is kinda where you really went off the rails though: This tells me you don't know much about user interaction with technology, which like... you should if you're teaching microcontroller development in middle school. Please pay attention here, and let me help: [...]" 6. "[...] I recommend finding an IDE that doesn't require the modern equivalent of ActiveX to work. [...]" 5. 7. & 9. "[...] How do I know? I see stuff that dumb every single day. [...]" This is the one point where you are right. Fully right. How often I was driving km in the evening to press a button, that 4 other people assured me to have pressed before. After 30 years in IT I am more than capable of writing a joke book about it. But, do we forbid the user now to browse the internet or use computers? Your job would be pretty boring if we would do so. We put safety belts and airbags and auto break systems into cars to help the users continue in a safer way, this is the solution. Otherwise the war on security is lost the same way as the war on drugs. Btw. drugs won. _ 10. "[...] you don't have to assume they're in good faith anymore [...]" Just the tip of the iceberg I saw.

You failed in doing your background check, even with LEGO, it's from 6 - 99, not 106 :-)

You also failed to read other suggestions and comments before, e.g. my sum up https://github.com/mozilla/standards-positions/issues/336#issuecomment-1173177328 & https://github.com/mozilla/standards-positions/issues/336#issuecomment-1173143179 which would, backed by sources, clearly shock you as Mozilla sold you to google already, the bad company you are pointing out here. Not saying that I am a friend of google, but they are there and they at least they do some job, not like Mozilla by just saying: Dangerous, we don't do. Instead you decided to let your bad mood or bad day drive your need for totally unneeded comments in a technical forum.

You also failed in providing any source for your opinions, in no comment you come up with any verification, source or further reading to proof your point.

In https://github.com/mozilla/standards-positions/issues/336#issuecomment-1200282069 you properly ignore the requirements the poster pointed out. Sure, micro controller development can be still done with an application on the computer, or even by just copying the code to the serial port - old school but works. The thing is, when we want a next generation that is not forced to purchase Nest, Tuya or closed source MCUs, then we should teach them how to DIY, thank you @mlyle for your service on our civilization. You are right, the good people at brave which sold our data (you will find the link, use the bad company to search for it) and give us points for watching ads....

While @mlyle did great in trying to keep the conversation on a discussion and technical level, you properly failed.

I don't share @SuperUserNameMan style, but I certainly share his frustration and arguments and I am also one of these dumb lazy users :-)

@ocdtrekkie I would appreciate of we stop these defamations now and get back to a technical conversation. As you seem to be a very good programmer, utterly experienced in all corners of life and explained that you understand the dumbness of people thourougly, what would be a proper solution to implement it in a way, that even the dumbest user is safe. Would be a whitelist an option or maybe limiting the feature to the internal network? What is in your POV a smart way to protect the users but still leaving the feature available?

[ocdtrekkie]

@NODeeJay Hardly, @mlyle came at the issue dismissively, with a complete lack of concern for security, and with the absolute bold arrogance to assume he knows better than Mozilla and Apple's combined security knowledge... because, well, it makes his job easier.

I understand you also disagree with me, but that's not an excuse to pretend mlyle had technical reasons and I didn't. I explained practical real world attacks, and mlyle responded by simply saying he thinks asking users permission is adequate safety, even though it's... very plainly not.

[SuperUserNameMan]

Maybe that would be easier to understand and accept if we were given actual examples of security issues related to the Serial port API.

• Does it happen often in Google Chrome ?
• What kind of actual devices are connected to the serial ports of most Firefox users ?
• Who still uses serial ports nowadays and for what purpose ?
• Who's actually at risk ?
• What kind sensitive devices would be connect to serial ports ?
• And if a highly sensitive device is connected to a serial port, who would be inclined to take the risk to use the same computer to browse insecure parts of web ?

[mlyle]

@NODeeJay Hardly, @mlyle came at the issue dismissively, with a complete lack of concern for security, and with the absolute bold arrogance to assume he knows better than Mozilla and Apple's combined security knowledge... because, well, it makes his job easier.

@ocdtrekkie Obviously different vendors disagree, and you agree more with Firefox's current choice. It's not a great way to proceed to denigrate the entire other side.

You fired the opening salvo of mockery with your post in the thread and it's something that I've tried to avoid in talking to you-- showing you respect even as you refuse to do so for the people who disagree with you. Mockingly explaining things to me does not help to advance your point -- " This tells me you don't know much about user interaction with technology, which like... you should if you're teaching microcontroller development in middle school. Please pay attention here, and let me help".

This is the kind of thing that tries to provoke an emotional reaction in the person you're talking to-- it seeks to anger me, and really-- it seeks to smack me down and shut me up, and in the practice convert me from someone who's legitimately bummed that he has to tell students to use Chrome instead of FireFox, to someone who just writes off the FireFox ecosystem. It seeks to make the annoyance of someone who reasonably disagrees with your stance go away by removing that person. It is something that no one deserves even if they are completely and objectively wrong.

I actually spent the entire beginning of my career in computer security and had some notable accomplishments (analysis of malware, development of new types of attacks, new security technologies, patents, building 8 figure business groups and selling a startup for 9 figures; being well-regarded in security circles, etc.). I don't like argument from authority, but you should keep in mind that when you're talking to people that they may actually have some domain knowledge. The one key thing that I always tried to put into practice:

• Security should be an enabling technology. It should not exist to tell people "no"-- it should work to make sure there is a reasonable, attainable path to meet the critical business or end-user need. The moment that it stops doing so, is the moment that your users actively work against the security infrastructure you are trying to build and everything is lost.

A final word, @ocdtrekkie : I used to act like you sometimes --- I hope not to the same degree. I was sorely lacking in confidence. I felt that I needed to put other people down for my point to stand. I only embarrassed myself when I did things like this, and it neither convinced other people of my viewpoint or made me feel better. It only makes the world a worse place for everyone in it.

edit: I've edited this a few times extensively for clarity. I really hope we can just get back to debating the technical merits and not denigrating each other.

[ocdtrekkie]

@mlyle Well...

when you're talking to people that they may actually have some domain knowledge.

You may, but, to be honest, you really blew credibility out the window in your opening remarks. "Asking the user whether to do it is pretty damn safe" is a comment that really, absolutely is wholly ridiculous in itself, and I don't even know where to go from there. If this was the case, UAC would've entirely eliminated all malware on Windows platforms back when Vista came out.

it should work to make sure there is a reasonable, attainable path to meet the critical business or end-user need

And indeed there is. There are two ways to do this I suggested without introducing a massive security hole into the browser ecosystem. Enabling users to accomplish their goals is absolutely a key aspect of providing a secure environment, but there's a difference between ensuring there's an attainable path, and just doing whatever the requestor wants you to do. There's an attainable path, it just doesn't involve the Serial API.

I used to act like you sometimes

This is you trying to "put other people down for my point to stand". Maybe you haven't changed as much as you think.

get back to debating the technical merits

For what it's worth, @SuperUserNameMan's last comment was excellent, and I will work on addressing it shortly! There's a lot to cover, so I need to put a fair bit together to respond adequately.

[mlyle]

@ocdtrekkie

You may, but, to be honest, you really blew credibility out the window in your opening remarks.

You still refuse to refrain from personal attacks. Address the issue, not the person.

[bgrins]

I've locked the thread for now. Many of these recent comments are well outside of the participation guidelines at https://github.com/mozilla/standards-positions/blob/main/CONTRIBUTING.md#for-the-broader-community. At this point the conversation should be focused on any changes to the spec since the position was set.