Request for position on Serial API #336
Comments
dbaron
added
the
venue: W3C CG
|
Also cc @martinthomson. |
|
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. |
|
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. |
|
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 I'm going to recommend we mark this as |
|
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,
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. |
|
@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... :( |
|
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. |
|
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. 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? |
|
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: Me: 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: Me: 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: So you need some kind of socket connection? Me: 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: Me: 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: Me 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 I'm not saying I'm giving up here. The responsibility of privacy/security needs to be shared amongst all parties. Me 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: And I also understand what Mozilla's concern are. They are valid. Me: 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 ❤️ |
|
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 ❤️ |
|
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. |
|
Chrome team: users don't understand URLs, we need to simplify them. It's easy to trick/phish users. 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. |
|
@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. |
|
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. |
|
@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"? |
|
@fabricedesre has the existence of WebUSB proven to be devastating? |
|
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. |
|
@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. |
|
@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. |
|
@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. |
|
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/) |
|
@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. |
|
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. |
This is what I currently do with my project that uses Web Serial. |
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. @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... 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! |
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.
No, the threat is that an attacker could change the code served by goodsite.com into something problematic. |
I agree, or not willing to.
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. 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 |
Do you mind sharing some code. JS or whatever? This could be used as a real solution now. |
|
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:
Furthermore, I am pointing out your core values: I therefore kindly urge you to revise your stance on this topic. Thank you. |
Here's the code that I'm using in my project: https://github.com/thorrak/brewflasher_web/blob/e6b152c0a676845edfafc1d8248ec2078780fdbf/src/FirmwareDirect.vue#L69 |
|
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. |
|
@ocdtrekkie-- I find your comment laughable.
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.
Asking the user whether to do it is pretty damn safe.
Chrome, Edge, and Opera-- all Chromium derived, sure, but all support it.
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. |
Great way to start your reply.
Then stop. That's entirely your decision to harm your students.
I recommend finding an IDE that doesn't require the modern equivalent of ActiveX to work. Proprietary Chrome features come and go every day.
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.
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.
False, and both Brave and Mozilla browser security teams disagree with you. (And understand user safety more, see above.)
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. |
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 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.
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.
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. |
|
@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. |
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.
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.
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.
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. |
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 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.
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. |
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.
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. |
|
@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. |
|
Well, neither userspace apps with cross platform UIs nor serving web content on a high number port requires admin access...
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. |
Not very many Chromebooks-- even without them, we would still get pointed this way, though. |
|
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 ? |
|
@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. |
|
@ocdtrekkie You put a lot of effort into personal attacks and selective mischaracterizations to troll on GitHub. |
|
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. 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 #336 (comment) & #336 (comment) 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. 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 #336 (comment) 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. 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? |
|
@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. |
|
Maybe that would be easier to understand and accept if we were given actual examples of security issues related to the Serial port API.
|
@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:
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. |
|
@mlyle Well...
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.
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.
This is you trying to "put other people down for my point to stand". Maybe you haven't changed as much as you think.
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. |
You still refuse to refrain from personal attacks. Address the issue, not the person. |
|
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. |
and others
Request for Mozilla Position on an Emerging Web Specification
Other information
According to WICG/admin#108 (comment)
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.
The text was updated successfully, but these errors were encountered: