RReverser

Because one is annual, and the other is just total. The equivalent of GDP for corporations would be annual revenue.

JS has proper async stacktraces as well, or do you mean something else?

Hm what's the difference then?

Great work!

Strangely, I thought I remember being able to use breakpoints on https://cloudflareworkers.com/ - I thought it handled inspector messages in a nested loop until receiving debugger resume command - since the beginning but I guess I must be mistaken... Maybe that was just an idea we had back then.

> What prevents developing a wrapper or shim that runs any wasm as if it were any other native executable?

That definitely exists and is used on server-side - Wasmtime, Wasmer and others.

Thanks, be sure to check out the part 2 as well :)

Don't know about webcams - usually (unlike in OP's case) those already have good OS-level support, but I did port gphoto2 to Wasm+WebUSB for access to DSLRs & mirrorless cameras: https://github.com/GoogleChromeLabs/web-gphoto2

Browser ports can't integrate at OS level, they're intentionally separated today, but given that e.g. Node.js has WebUSB support (https://github.com/node-usb/node-usb), I guess you could make a layer that exposes such Wasm drivers as native to the OS. Could be a fun experiment.

Chromebook is probably the perfect target for those kinds of ports. Definitely worth giving a try, hopefully SANE supports it.

Thank you!

That's been already blocked by Google, with reviews deleted, so not much I guess.

> Not to mention that I have almost no clue how to debug a WASM build.

I've got you covered: https://developer.chrome.com/blog/wasm-debugging-2020/ (TL;DR use Chrome DevTools with the official DWARF integration)

Or it could apply gzip/brotli + optionally wasm-opt and cut the size ~5-6x: https://twitter.com/RReverser/status/1494435774003093515

The sad part is, it could be cut very easily cut down to ~60MB with basic optimization & compression (heck, even gzip/brotli compression alone would go a long way): https://twitter.com/RReverser/status/1494435774003093515

Impressive feat, but I'm worried this small detail ruins the first impression for way too many.

Part 2 is out: https://news.ycombinator.com/item?id=30165184

Ah, I see. That would be interesting, but removes the cross-platform compatibility from the equation, which, for me, is the most valuable piece of WebUSB and other similar APIs.

Glad to hear! If you want to give it another try, you should be able to use my linked libusb fork in any app that depends on libusb, and compile that with Emscripten.

I didn't see it but did think about it. I think it should be possible by wrapping WebUSB into something like Comlink, e.g. I know Surma experimented with allowing Comlink to be used with WebSockets: https://twitter.com/dassurma/status/1218207376899235840

Comlink takes care of the RPC part of any API, so you only need to choose and hook up a communication backend.

With guiding you're usually aiming for 5-10 minute exposures per frame. That usually results in each frame having at least several streaks. Sure, those are technically still short and can be cancelled out, but astrophotography is already challenging enough and has plenty of other noise sources without adding more fuel to the problem.

And that's now, when we're not close to the planned tens of thousands of satellites by Starlink above, and other vendors like Amazon only starting to plan their similar programs. That's why early feedback is important - otherwise the sky will be ruined in the best case for decades to come.

One is looking at it, another is polluting it and precluding others from looking at it. Surely you see the difference?

For pure visual observation you might be right, but any sort of amateur astrophotography is already significantly affected and is only going to get worse because 1) it's usually more wide-field than in professional observatories, which significantly increases the chance of Starlink streaks and 2) the ~6.5 magnitude is still a lot brighter than all the interesting deep-sky objects and is only dimmer than stars visible to the human eye.

Yeah, like every start-up clearly did before them (example: Uber). /s

> It’s possible someone could come up with something like that for WebUSB, something that constrains it to something safe.

That sounds like WebSerial and WebHID to me, which don't require similar shenanigans with Zadig on Windows or Linux permission changes, because they allow access to a limited subset of USB device functions.

But that will never cover all the use-cases for USB apps. For those the only choices are not to do anything at all and let closed native executables to continue dominate this space (which gives them unlimited access without even those simplest permission prompts), or to work on WebUSB and encourage devs who do need to interact with such devices over USB to switch to that instead. I don't see 3rd option or how it would be possible in our non-ideal world, and among those two WebUSB still seems like a better idea.

> Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous.

Same can be said about native apps. Like with other hazards, in the end it's all about balance - you can't stop users from _ever_ doing stupid things.

> and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content

I'd actually be pretty happy if browsers chose to implement those APIs with the same restriction in mind - that is, only for explicitly installed PWAs. I said this elsewhere in the past, and I still think that's a reasonable restriction that could provide a path forward.

> or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability)

I'm not very well-versed in the details, but I believe that's also the reason why WebUSB (or Chromium implementation of WebUSB?) doesn't allow certain classes of devices to be ever accessed via that API.

They mentioned below that they have their own devices they can control. As I understand it, for those kinds of IoT usecases the workflow is easier because, instead of overriding the driver defined by the OS, you can define WebUSB-compatible descriptor that will "just work" across all platforms.

Slightly tangential, but I still find it fascinating that it was Firefox OS was the first to introduce the idea of adding all sorts of hardware APIs accessible from JavaScript, or at least that was the first time I heard of that idea and played with it (and still have a ZTE phone from the time), but, after the Firefox OS was discontinued, they essentially stopped being interested in those capabilities altogether and started to even actively discourage others from exploring it.

I guess it makes sense from business perspective, but I still believe in the original idea of making more powerful apps with Web technologies, even though the companies that work on those ideas changed over time.

> because it’s such a run-away-screaming scary idea for security

I think that's the root of our disagreement. Few years ago I've been of the same mind about giving the web new powerful features, but after watching the space and seeing the existing alternatives I've come to change my mind.

As mentioned in another thread below (https://news.ycombinator.com/item?id=30013287), vendors who need this sort of functionality, already find ways to implement it via other proprietary methods like local executables that, unlike implementations of Web APIs, are not reviewed by other teams and usually expose all sorts of critical stuff over local HTTP servers or in another insecure fashion.

In the end, it's not a question of "if" we want to expose those features to the web apps, it's "how" we can do so with minimal risks to the users, and that's where web APIs with thought-out permission models, explicit requests and history of cross-origin checks can help.

Of course, you can also say that vendors can continue to implement those things insecurely anyway even when new APIs exist, but 1) in practice when they're given a simpler way to do the same thing, they tend to go for that more often instead of inventing custom hacks and 2) that's where advocacy of the new APIs comes in, and what I'm trying to do by showing what the web can be if we let it.

As for your other arguments about potential for breaking changes if/when those APIs get adopted by other browsers, I agree I might be overoptimistic and your prediction might very well turn out to be true. Those APIs map to basic USB concepts quite closely, so I can't imagine what changes would be necessary, but, of course, I don't have enough experience with WebUSB outside this project to say that it's 100% impossible :)

In the end, it's a bit of a chicken-and-egg problem - in order for browsers to see the interest or get feedback, there have to be apps trying to build something with those APIs and reporting bugs / feature requests, and for those apps to use those APIs, there has to be at least one implementation first. This problem can be chewed from either end, and I'm trying to do my part by showing developers how those APIs can be used for porting interesting apps and libraries.

I think I already made it clear in another thread why I'm not going to interact with your comments in particular. There's no need to try and post variations of the same comment throughout the tree.

At the same time, I'm perfectly happy to respond to questions and concerns of other people like the one above who can express their thoughts without resorting to personal attacks.

FWIW ~ works in PowerShell too.