_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Build Adafruit projects right from Firefox
hulitu wrote 13 hours 55 min ago:
Why not from a firefox running in a virtual machine inside firefox ?
RAM is cheap now. /s
psychoslave wrote 18 hours 29 min ago:
So, what's adafruit? Related to Adam programming language?
TopHatHipster wrote 18 hours 20 min ago:
Open source hardware company from NY, focused on making Arduino-based
boards, displays etc.
(HTM) [1]: https://en.wikipedia.org/wiki/Adafruit_Industries
froyooh wrote 1 day ago:
Old shit is shit
nathanmills wrote 1 day ago:
WebUSB next? I would like to be able to configure my keyboard but it
can only be done via their website which requires WebUSB.
maxlin wrote 1 day ago:
Feels a bit out of place that the website tries to aggressively make me
download Firefox, with multiple links on the site for it. Like it's the
2000's again and I'd need ActiveX or something. But it's to use a
standard.
Sure, the standard is cool, have used it to flash Meshtastic to some
LoRa boards, before advancing to use VS Code + ESP-IDF to flash in my
own LoRa code.
kotaKat wrote 18 hours 4 min ago:
it feels more out of place that it's a specific company getting to
shove their name up as priority billing for the feature when this
entire page should be focusing more on WebSerial support being in
Firefox as a whole and not one dude's little devboard company.
iolo wrote 18 hours 22 min ago:
> Feels a bit out of place that the website tries to aggressively
make me download Firefox
It's firefox.com, feels like the perfect place to encourage people to
download Firefox. That would be like going to a car dealership and
being put off by people trying to sell you a car
nathanmills wrote 1 day ago:
What makes it aggressive?
nathanmills wrote 1 day ago:
Downdooters, what about my question did you dislike? Is it just you
don't want any resistence to anything you say?
csande17 wrote 1 day ago:
> [...] the website tries to aggressively make me download
Firefox, with multiple links on the site for it.
> What makes it aggressive?
The parent comment already contained the answer to your question
(the multiple links are what makes it aggressive, in GP's
opinion). Your comment might have been seen as more constructive
if it engaged with that directly.
nathanmills wrote 1 day ago:
I don't remember that being there, maybe it was edited. But 2
buttons are not "aggressive". C'mon. Really dude? You believe
that shit?
maxlin wrote 12 hours 13 min ago:
Wasn't edited. 2 large download buttons on a page that barely
scrolls is as aggressive as it gets. What, you'd only
consider 5 buttons aggressive?
nathanmills wrote 11 hours 35 min ago:
They are medium-sized at best, and 2 of them is not
hostile. I doubt they chose them by choice, its just a page
template where it makes since to have one at both the top
and bottom for longer pages. TWO DUMBASS, TWO FUCKING
BUTTONS, THATS IT.
eipi10_hn wrote 1 day ago:
I dislike everything you said.
greyface- wrote 1 day ago:
Mozilla's response to "Request for Mozilla Position on an Emerging Web
Specification", June 2020:
> For raw device access as envisioned in a number of APIs (Web USB, Web
Bluetooth, Web NFC, and Web MIDI), the risks of exposing those APIs to
users cannot be reasonably conveyed. This is pretty much an intractable
flaw of allowing raw, non-semantic access to devices regardless of the
protocol used to do so.
> The specific issue is: it's not intuitive that allowing
malicious-site.com to access your Bluetooth keyboard might give that
site access to your stored passwords, give them the ability to hijack
your DNS settings, or allow them to encrypt your hard drive and hold it
ransom. And if it's not immediately obvious how those things are
possible, that only serves to demonstrate how completely non-intuitive
the risks are and how intractable trying to explain them in a
permission prompt would be.
(HTM) [1]: https://github.com/mozilla/standards-positions/issues/95#issue...
m3047 wrote 10 hours 33 min ago:
I get (ab|l)users will do stupid. I appreciate the argument that
WebSerial is not those other things; until it isn't and it's a victim
of its own success. Now the driver maintainer at the OS level has to
consider that their driver is exposed to the Internet every time an
ad is served.
Maybe there should be a WebDevice which you can buy which plugs into
a USB port and does all the things (for the things plugged into it)
and exposes a "webdev(ice)" to the browser? There's an overengineered
solution. Nonetheless in an industrial situation the things are
exposed to the controller, not to the machines on the floor. [Edit:
Not strictly true, they may be published as visible "tags" through
various mechanisms.]
How about wifi?
There's a nasty shear layer / fault here. Don't build a house right
on top of it.
bryan_w wrote 10 hours 59 min ago:
> it's not intuitive that allowing malicious-site.com to access your
Bluetooth keyboard might give that site access to your stored
passwords, give them the ability to hijack your DNS settings, or
allow them to encrypt your hard drive and hold it ransom. And if it's
not immediately obvious how those things are possible, that only
serves to demonstrate how completely non-intuitive the risks are and
how intractable trying to explain them in a permission prompt would
be.
Which is odd because the very next thing a user will do (Which you've
allowed for years) is download and execute a .exe or .dmg/.app from
that same malicious-site.com which will do the same thing
jwr wrote 17 hours 59 min ago:
I think that response increasingly makes no sense (as time passes).
Mozilla prevents people from building apps that access their devices
because it might be possible to do something malicious.
I am so tired of being treated like a drooling idiot "for my own
good".
mort96 wrote 17 hours 50 min ago:
The worry is real: there has historically not been a meaningful
security barrier between a USB device and software running on the
machine it's connected to. Firmware hasn't been developed with the
assumption that the machine is malicious, there's probably lots of
firmware which you can get RCE on by sending a weirdly formatted
USB packet. Lots of devices have pretty unrestricted firmware
update via USB functionality. And security is often fairly lax the
other direction too; at least Linux implicitly assumes that
hardware you connect is trusted, and there are lots of old,
insecure drivers for USB devices out there.
Do users understand that by clicking "allow" on a website, an
attacker can re-flash their mouse with firmware which causes the
mouse to present itself as some obscure USB device which activates
a vulnerable driver? That by clicking "allow" on a pop-up from a
website, the website can abuse their keyboard to install a key
logger or botnet? Should a user be expected to understand this?
I don't know how valid this fear is in practice. Has anyone done a
study?
mort96 wrote 19 hours 1 min ago:
I like that your comment, which is at the very top of this comment
section, quotes a statement concerning Web USB, Web Bluetooth, Web
NFC and Web MIDI.
The linked post is about WebSerial. The concerns about Web USB, Web
Bluetooth, Web NFC and Web MIDI mostly don't apply. Most users have
USB and Bluetooth devices connected, many have MIDI devices. Pretty
much nobody who isn't in the specific target audience for WebSerial
is going to have a serial device connected. And even if the concerns
did apply, you should probably quote a statement which talks about
WebSerial.
nl wrote 1 day ago:
I understand and previously agreed with Mozilla's hard line privacy
and security stance.
Recently I've changed my mind. I've been building a thing using
everything in the web platform, even if it is Chrome only and it is
great. You can build apps the blend local and remote systems together
in ways that make new things possible - and it is on an open-standard
runtime.
But as a long time Firefox user I hate that I have to warn people at
some critical features won't work.
I think from a platform point of view having features in the web
platform that let it compete with other platforms is worth the trade
off.
hommelix wrote 20 hours 12 min ago:
Now with Webxxx, the user needs to make sure that it is the right
URL, not a fake teanns instead of teams, so he is unsure every time
he has to use it. Some random download, once it works, can be
reused and you have more trust that it works after the trial was
positive.
And if it is open source, you can review the code before compiling.
I can't review the code of some random server, as my browser only
receives a random wasm binary for example.
nl wrote 19 hours 31 min ago:
But the alternative is binary flashing software AND a binary blob
to flash.
This doesn't preclude it being open source in anyway. Infact with
a WASM toolchain you could even compile in the browser.
usrnm wrote 1 day ago:
So, what you're saying is that you agree with the security concerns
regarding these API, but your convenience as a developer outweighs
them?
nl wrote 23 hours 55 min ago:
No that's a mischaracterization.
I'm saying I think it is important for free and open systems to
be competitive with closed ecosystems, and to take advantage of
the power of local systems.
I believe in a world where we - as developers - can build systems
that have both maximum safety and maximum utility for users.
Currently there are two ways of distributing software that takes
full advantage of the hardware users have:
1. AppStores, with centralized, permission based certification of
developers in an attempt to make apps safe.
2. Binary downloads, relying on the operating system to make them
safe for users.
I believe there should be a third way - a platform that sandboxes
users from the worse things that are possible and breaks reliance
on cloud platforms.
I think the web platform is the closest to achieving this. I
think the security and privacy concerns are valid and
well-founded, but I think the trade-offs in pushing
permission-based systems are worthwhile.
Take this project as an example. The alternative to web-serial is
to download a random executable binary and firmware written by
who knows to your computer, with full read/write permissions. I
think that is a riskier outcome for users than enabling this API.
usrnm wrote 19 hours 2 min ago:
The web is not a software distribution platform, it's a
platform for distributing thin clients to propriatory walled
gardens that will break your use cases or just ban you at will.
Users have absolutely no control over the web, so no I don't
see it as a superior alternative
nl wrote 16 hours 50 min ago:
I completely disagree.
I've been using the web since 1994, and it's always
distributed applications. I mean what were WAIS and Veronica
except attempts to build applications - and they were (vastly
inferior) predecessors to the web.
The web is the most ugly, horrible, messy, fantastic and
beautiful Commons in human history and I love it.
Yes, people will block it and Balkenize it and make it ugly
and make terrible apps that run horribly.
But it is better than anything else we've built, so there is
that.
Fnoord wrote 15 hours 32 min ago:
I think you're both right. What I dislike about it, is how
we went from walled gardens to ads, tracking, and guilt
tripping adblock users (while IMO whatever you see or don't
want to see is up to the client). It is a huge cat and
mouse game.
(That guilt tripping is what worries me in relation to
WebUSB and webserial.)
In a TUI, it is still completely unacceptable that the
client would spam the user with ads. And if it would, due
to FOSS nature it is easy to circumvent.
If web devs are clever they produce an API instead of pure
HTML + JS + the whole bloated crap around them. It'd save
them costs, and heavy API users could subscribe.
rfrey wrote 1 day ago:
I think it is uncharitable to say "your convenience". It's more
like "your vision as a creator". We're talking about developer
intent that isn't possible otherwise. You can say "good, it
shouldn't be", but don't characterize it as convenience.
jononor wrote 1 day ago:
WebSerial in Firefox?! Finally! One of the very few things I use chrome
for.
gblargg wrote 1 day ago:
As long as you can download the environment for offline use.
monegator wrote 1 day ago:
what the fuck since when they are allowing webserial / webusb?
I've always agreed with the reservations about browsers being able to
control peripherals. I'd rather download a python script i can inspect.
wildzzz wrote 1 day ago:
It's handy for situations where you have inexperienced people needing
to flash microcontrollers. Meshtastic is a great example, it's meant
for a wide variety of users from people that can actually write code
to people that have only maybe heard of a raspberry pi in passing.
You buy a transceiver on Amazon, go to the meshtastic website, plug
in the transceiver, and hit "flash". Also, I don't want to have to
download yet another custom Arduino IDE. I don't need to actually
modify the running code, I just want the binary on the device so I
can move on with playing with it.
monegator wrote 21 hours 10 min ago:
I'm aware it's handy. Lots of handy things have been used to
distribute malware. Now we just need someone to intercept ESPHOME's
flasher so that it sends a modified payload
rebelwebmaster wrote 1 day ago:
It uses add-on gating similar to what they do for Web MIDI, so it's
not exposed to users unless they specifically opt into it.
(HTM) [1]: https://hacks.mozilla.org/2026/05/web-serial-support-in-fire...
fabrice_d wrote 1 day ago:
I don't believe this is a good solution: users will obviously click
on that add-on install dialog box without being better informed and
protected against malicious / buggy / attacker controlled web
sites.
Hopefully they will move to a better solution that offers some
integrity guarantees instead, like [1] that they have an early
implementation of in nightly builds.
(HTM) [1]: https://rwc26.waict.dev/
Rohansi wrote 1 day ago:
You could always just not allow any websites to use these features.
They require your permission first.
Insimwytim wrote 1 day ago:
The design of this webpage is horrendous.
lxe wrote 1 day ago:
Woah this is a MASSIVE deviation from FF's previous philosophy on
allowing WebSerial. This is a GOOD thing!
codys wrote 1 day ago:
I hope this signals a departure from us being stuck without web usb
in firefox too. It's a shame that I've been stuck using chrome for
it.
And maybe we'll get web bluetooth too.
lxe wrote 1 day ago:
They were crazy overzealous about not allowing these technologies
for a long time. I'm pretty sure I had many posts about this
complaining over the years.
alibarber wrote 20 hours 22 min ago:
I'm delighted about this and also really hated the debate that
had surrounded it.
Bring up WebSerial and WebUSB and oh no, all of a sudden, my
'document browser should not be accessing hardware' - yes we get
it, you think the web is a collection of documents and are
technically - in the most strictest sense possible correct. Hyper
TEXT Transfer Protocol and all that.
Of course I've been watching Netflix and YouTube on my Firefox
'document browser' for years, because if I couldn't then there
would literally no hope of anyone using Firefox in the real
world, but WebUSB and WebSerial people are nerds who we can argue
the toss about document browsers with and prove wrong.
le-mark wrote 1 day ago:
Using serial comms from the browser is really important in educational
robotics programs. Both First and Vex platforms support it. Kids can
access the web based coding environment on their chromebooks, and send
code to the robots with a usb cable.
We recently restarted our middle school robotics club. The school had a
lot of old Vex EDR equipment for which the coding software is windows
only so that really limited what we could do related to coding. Glad to
see Firefox getting up to speed on this.
skybrian wrote 1 day ago:
Great to see Firefox getting on board. I wrote an alternative to
Arduino's serial plotter that works in Chrome. Hopefully it's not too
hard to get Firefox working too? Patches welcome:
(HTM) [1]: https://github.com/skybrian/serialviz
gregstoll wrote 1 day ago:
Hopefully it will just work, if not please file a bug! I tested with
a variety of hardware and sites but of course I couldn't try
everything...
tech234a wrote 1 day ago:
On iOS the page promotes the App Store version of Firefox, which is
based on WebKit and doesnât support Web Serial.
darkwater wrote 1 day ago:
Blame Apple for that.
2Gkashmiri wrote 23 hours 46 min ago:
Not a full time apple user but how does third party orion browser
supports Firefox addons on apple but Firefox itself doesn't support
their own addons?
cxr wrote 1 day ago:
That's a start at improving something. But it won't rid itself of the
Playskool/Fisher-Price gimmick factor or have any lasting effect until
we can convince JS developers to write their own tools in a
standards-compliant dialect and use standardized APIs so that
contributors can use the runtime they already have installed instead of
being cajoled and browbeaten into installing NodeJS or Bun or Deno or
whatever to do what the browser runtime is perfectly capable of:
opening a project directory, executing the code comprising the build
script, and outputting the build artifacts when it's done.
nl wrote 1 day ago:
> do what the browser runtime is perfectly capable of: opening a
project directory, executing the code comprising the build script,
and outputting the build artifacts when it's done
Unfortunately Firefox doesn't support the FileSystem API so to do
this you need to resort to uploading the entire source code directory
each time you change a source file.
I understand Firefox's privacy and security first thinking on this,
but I think it is misguided. It's led to the webplatform being
eclipsed by other, propriety options, or people forced to ship
"Chrome-based only" features.
cxr wrote 1 day ago:
> Unfortunately Firefox doesn't support the FileSystem API so to do
this you need to resort to uploading the entire source code
directory each time you change a source file.
Right, it's so much less onerous to have people download and set up
an entirely separate fickle toolchainâand needing to trust that
the install triggers in the package.json of some transitive
dependency won't exfiltrate your personal data or install some
nefarious ineradicable background service onto your system, versus
the two extra clicks you'd have to subject yourself to if you
wanted to re-run the build.*
Wait, no.
> people [are] forced to ship "Chrome-based only" features
No they're not. By your own admission they could make their build
scripts work with the standardized HTML5 APIs that are
well-supported in all major browsers. They choose not to.
And you're not really responding to the substance, anywayâwhich
is that JS programmers (frequently writing for browser runtimes,
even) require that you install NodeJS, Bun, or Deno (because they
hardcode the build scripts internals against one of those runtime's
APIs). If programmers really were writing build scripts that you
could run in Chrome but unfortunately not Firefox, then even that
would be an improvement over the status quo. But that's not what
we're talking about, because that's not happening.
* most of which are destined to be one-shot executions, anyway
nl wrote 23 hours 46 min ago:
You seem very angry and I clearly don't understand what you are
talking about.
> And you're not really responding to the substance of the
comment anyway, which is that JS programmersâfrequently writing
for browser runtimes, evenâare demanding that you install
NodeJS, Bun, or Deno (because they hardcode the build scripts
against those runtimes' APIs).
Do you mean things like the Typescript + Webpack/whatever
toolchain? Because broadly speaking that seems orthogonal to the
target browser.
Using tools outside the browser to build something for the
browser is mostly an optimization, for both the developer and the
end user.
If someone has a web app with maybe 100 NPM packages, doing
things like tree-shaking offline before shipping to a browser is
important.
> And you're not really responding to the substance of the
comment anyway, which is that JS programmersâfrequently writing
for browser runtimes, evenâare demanding that you install
NodeJS, Bun, or Deno (because they hardcode the build scripts
against those runtimes' APIs).
If they are targeting Web APIs and using runtimes to build for
those APIs what is the problem?
There are plenty of tools that need version X.XX+ of GCC to build
and won't build using MSVC or something. It's a bit annoying but
hardly outrageous.
arikrahman wrote 1 day ago:
This is why I use Clojure/ClojureScript to sidestep the issue
entirely, while still being able to use the ecosystem if I have to.
geekuillaume wrote 1 day ago:
WebSerial was just introduced in Firefox 151. It was already available
for 5 years in Chromium based browser. It's so new in Firefox that even
caniuse is not up-to-date: [1] .
(HTM) [1]: https://caniuse.com/web-serial
tzs wrote 1 day ago:
That makes me curious.
It would not be quite as seamless as having serial support included
out of the box in the browser, but couldn't you get most of the way
there by writing a native application that provides provides a
network interface to the serial ports and then a JavaScript library
for use in the browser than talks to that application over the
network (maybe even making the JavaScript library API match the Web
Serial API so code written for Chromium's actual Web Serial requires
little of no porting)?
The native apps for Linux, Windows, and MacOS would be pretty simple,
and would be independent of browser vendor or version.
This might even allow some flexibility that serial implemented in the
browser doesn't have, such as allowing control of serial ports on a
different host.
I'd have expected that when people saw that Web Serial in Chromium
opened up some great possibilities for things like browser based
Arduino development but other browser makers were not on board
someone would had thoughts similar to what I've described.
Does this exist and I just missed it? Is there some major difficulty
I've overlooked?
NeutralWanted wrote 1 day ago:
Workflow for what you described:
1. I go to your site
2. I download your service for my platform (that now has to be
developed and shipped for N platforms your site wants to support
3. I install said service and make sure it's running
4. I go back to site and it's connected (or it's not and now you
have to support a whole host of troubleshooting docs based on
platform.
Web serial version that's now in Firefox and has been in chromium:
1. I go to your site. It works
What you described is something that has been done for awhile. Most
recent thing I've used I can think of is Lenovos Driver install
utility (you install their connector app, go to their support page,
it connects to your app and then shows what drivers you need)
sowbug wrote 1 day ago:
You could do that, but then either you're asking users to install a
native app, which isn't very "webby," or you're shipping something
with Firefox that isn't based on web standards*, which absolutely
isn't webby.
*Unless you're thinking of something I'm not, the API couldn't
exactly match the Web Serial API because of same-origin policy, and
if you made an exception to that policy to make the polyfill work,
you'd punch a giant security hole in the browser.
gregstoll wrote 1 day ago:
(I submitted a PR for caniuse a few days ago :-) [1] )
(HTM) [1]: https://github.com/Fyrd/caniuse/pull/7523
aetherspawn wrote 20 hours 26 min ago:
Is Web USB also supported?
gregstoll wrote 14 hours 53 min ago:
Nope, our standards position on that is still negative, for one
thing.
dazhbog wrote 13 hours 43 min ago:
Im sure its also negative for WebBLE but we are hoping that one
day we can have it on Firefox too.. We use WebBLE for talking
and programming NRF52 chips and it works great compared to
plugging a wire every time.
firesteelrain wrote 1 day ago:
Edge has had it for a while too.
wasting_time wrote 1 day ago:
In case you don't know, Edge is a "Chromium-based browser" like GP
mentioned.
pjmlp wrote 23 hours 44 min ago:
Which is why for a while Microsoft had Edge and EdgeChrome in
parallel, until finally replacing one with the other.
peesem wrote 1 day ago:
interestingly, MDN web docs claims at the top of the Web Serial page
( [1] ) that Chrome does not support it, even though the support
table at the bottom shows that it supports all of the features
(Firefox doesn't) and has for longer than Firefox
(HTM) [1]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_...
atopal wrote 1 day ago:
That's because Chrome on Android has a partial implementation of
Web Serial. The banner on top is to get information at a glance vs
the detailed breakdown of the compatibility table.
trainyperson wrote 1 day ago:
I used WebSerial + WebSockets during hardware to prototype some
connected hardware (on boards that didnât have WiFi).
Plug in to USB, fire up the web app, and then press a button in NY to
light up LEDs in SF â it was exciting stuff!
I never tried actually programming the boards over WebSerial; that
obviously opens up many more use cases. Iâm thinking about the
success that p5.js has had in the creative coding community, largely
driven (I think) by a low barrier to entry since it just requires a web
browser to get started.
singiamtel wrote 1 day ago:
Amazing feature for beginners. Is it possible to do this using Arduino?
gregstoll wrote 1 day ago:
Yup! Arduino is one of the things I tested with. (I worked on this
for Mozilla)
mathgeek wrote 1 day ago:
I donât see why not.
(HTM) [1]: https://docs.arduino.cc/libraries/webserial/
(DIR) <- back to front page