Mastodawn

Roderick Gadellaa Apr 15

First Web MIDI, now Web Serial! Could not be happier to see Mozilla returning to an expansive vision for the web. The idea that we should download unsafe native binaries to get things done was always naff, and an abdication of the browser's role in the lives of users:

https://fosstodon.org/@balloob/116398481380578311

/cc @firefoxwebdevs

balloob (@[email protected])

Attached: 4 images WebSerial has landed in Firefox Nightly !! 🎉 Enable it in about:config and it all just works as expected. Took a brand new ESP32 and had a new Bluetooth proxy added to Home Assistant within 2 minutes 👌

Fosstodon

Alex Russell Apr 13

@firefoxwebdevs I would be remiss if I didn't also point out the role that Blink and the Project Fugu team (particularly @reillyeon, Josh Bell, Vince Scheib, Chris Mumford, and @kennethrohde) played in leading on this feature responsibly. Everything was built in the open, with invitations to all vendors to participate in development, and in a collaborative way. There wasn't much non-developer feedback, but it didn't keep the team from building and shipping responsibly.

Alex Russell Apr 13

What does shipping responsibly mean when you're that far out ahead? A few things:

- requesting developer feedback at every stage
- making working versions available behind flags, then iterating
- asking for wide review despite disinterest by other vendors
- being honest and iterative about feedback
- shipping the "base subset", then iterating to solve follow-up problems

You can see that whole journey here:

https://chromestatus.com/features?q=web%2520serial

Chrome Platform Status

Alex Russell Apr 13

In the end, this focus on developer needs dovetailed with the Blink Launch Process's prescriptive gates for launching before consensus, including:

- a strong spec (even if not yet a standard)
- good tests
- wide review (including the TAG)

These are calculated to allow other vendors to implement cheaply, without IP risk, should they change their minds later. And once again, the Project Fugu process design is working as designed; enabling Mozilla to join us without drama.

Alex Russell Apr 13

This is how we can keep building a web worth wanting in the face of disingenuous veto players [1] and subversion of standards venues based on degraded competition [2]. The humility to admit your first idea is *probably* wrong (at least in part), combined with urgency to fix real problems for users and developers, puts a premium on responsibility in leadership. I'm proud of the team for taking that seriously.

[1]: https://infrequently.org/2025/09/apples-crimes-against-the-internet-community/
[2]: https://www.mnot.net/blog/2026/02/13/no

Apple's Assault on Standards

By subverting the voluntary nature of open standards, Apple has defanged them as tools that users can employ against the totalising power of native apps in their digital lives. This high-modernist approach is antithetical to the foundational commitments of internet standards bodies and, over time, erode them.

Alex Russell

✧✦Catherine✦✧Apr 14

@slightlyoff @firefoxwebdevs now we just need to standardize WebUSB

Alex Russell Apr 14

@whitequark @firefoxwebdevs The thing that moves things forward is always implementations, so we need Mozilla to implement; process disposition in a standards body is very much a second-order concern. That will break the logjam, both in standards and flesh out issues in the existing spec:

https://wicg.github.io/webusb/

WebUSB API

Alex Russell Apr 14

@whitequark @firefoxwebdevs (there are cases where you need standards venue process to move in lock-step with implementations for IP coverage reasons, but for nearly all of the web's surface area outside of codecs, that isn't the right order, and groups like CSSWG and TC39 that pretend otherwise are just making excuses for going waaaaay too slowly and blessing veto players' obstructionist tendencies)

✧✦Catherine✦✧Apr 14

@slightlyoff @firefoxwebdevs Mozilla has refused to do it on a basis of policy that has also been applied to WebSerial and WebMIDI

Alex Russell Apr 14

@whitequark @firefoxwebdevs Yep yep. This is why I'm celebrating; the dam is clearly breaking, and we should encourage Mozilla to learn from these examples and reconsider the EKR-era false dichotomy of safety vs. capability.

✧✦Catherine✦✧Apr 14

@slightlyoff (EKR?)

Alex Russell Apr 14

@whitequark former CTO; designer of TLS 1.3, incredible security and protocol guy...but was very against expanding the web in these directions.

Mutesplash Apr 14

@slightlyoff Kinda 🫤 on these. The plan now is to never let you download anything via "configure only over web" and then delete the website and all the software whenever the company wants to/dies. Also they're "great" for fingerprinting and authorization popup fatigue.

Alex Russell Apr 14

@Mutesplash Have you used them? They provide zero fingerprint surface area before the user selects a device from the chooser, and we have the data to back the assertion that's enough friction to keep them from being used for this.

Mutesplash Apr 15

@slightlyoff My specific problem is with a firmware updater that has no binary but is only on the web and requires webserial. No way to reflash device when corrupted if that site goes away 🤷‍♂️ Don't think I want to encourage no-artifact software for hardware

Alex Russell Apr 15

@Mutesplash Lots of software goes away or loses OS support over time. I appreciate the concern, but it seems a bit orthogonal, and surely the transparency of the web vs. native software makes it *easier* to see the flashed payloads, not harder, right?

Mutesplash Apr 15

@slightlyoff Sure it loses support but it doesn't go away if you back it up. I can still configure a Gravis Phoenix because I have the software that nobody bothered reversing.

It may be easier but web puts a timer on reversing things.