Consider implications of WebUSB standard

[alexandrosm]

Another one of my ill-defined issues :)

So there is this new standard being proposed -- https://wicg.github.io/webusb/

And I wouldn't really be concerned, except that Chrome already has experimental support for it.

So there is a chance that Etcher will be able to, at least in theory, work within a browser, maybe some subset of browsers, in the future. For an extended period of time, of course, this will be new/experimental technology. However, since Electron builds on Chromium, we may be in a unique position to have both the latest Chromium code, the ability to enable the API at build time, and have a legitimate use case for it. In other words, Etcher may be able to push or even help improve the standard itself, and gradually increment itself towards being capable of working fully in-browser.

There are a few implications I'm concerned about.

First, what would the theoretical alterations for the Etcher codebase be? Some bullet points:

• We'd need some kind of USB Mass Storage Device js "driver" or equivalent.
• We'd need to remove or shim any dependence on node.js APIs (but some shims already exist)
• Elevation would now simply mean "get permission to use the appropriate USB drive"
• Drivelist may not be as necessary, but an equivalent lib that figures out which USB port is which may.
• Unclear how this would interact with the deep image alteration LKL stuff we have in the pipeline (should write about that somewhere), and in general how this interacts with our plans for richer functionality.

The interesting thing here is that we already have a good amount of low-level code, and it's almost all in pure js. We've minimised native dependencies to attain npm-installability (in the past), and it's paying out in an unforeseen way. Proposing to run Etcher in the browser is not as insane as it may sound.

Second is what this would mean for Etcher's build/distribution approach if we went fully in-browser:

• Etcher would become a webapp/service, launched from etcher.io? We'd need to invest in discovering more about offline availability and "installability" for webapps, whatever that means.
• No more multi-platform, multi-architecture, multi-installer builds. Yay!
• No more signing requirements either, right? Yay!
• No more bitching about Etcher's installer size! Yay!
• We would, though, have to deal with multiple browser versions again, including old browsers. sigh.

Finally, what does this mean for Etcher as a project/product.

• Doubtful how this interacts with the CLI version. We'd either have to continue distributing it solo (assuming we manage to get that sorted finally), or discontinue it entirely.
• Same applies to the OS packaged versions. To the degree that people care for them we could continue to provide them, though.
• Unclear how Etcher would integrate with getting started guides, though there's exciting potential for it to be an embeddable component of sorts? Users may not even have to leave the getting started guide at all.
• Would we (resin.io) start to have to approach Etcher as more of an ongoing service to be provided rather than a binary to be distributed?

All in all, I don't see this on our super-short-term roadmap, but it may make sense to experiment with the API, especially if it's available in the Electron version we use, and see what it would take to move some functionality inside the chromium scope.

What does everyone else think?

[lurch]

I had a quick skim through the first page or so, and I wonder if https://wicg.github.io/webusb/#get-allowed-origins means that a USB device would need to explicitly allow http://etcher.io to access it? Which obviously wouldn't be the case for USB Flash drives / SD cards / etc. used with Etcher?

https://github.com/WICG/webusb/blob/gh-pages/explainer.md seems to imply the same thing - sounds like it's more targeted at USB device manufacturers, than software vendors.

[alexandrosm]

Got it. Good to know, and let's put this to sleep till new news emerges.

Alexandros Marinos

Founder & CEO, Resin.io

+1 206-637-5498

@alexandrosm

On Sun, Oct 30, 2016 at 3:18 PM, Andrew Scheller notifications@github.com wrote:

I had a quick skim through the first page or so, and I wonder if https://wicg.github.io/webusb/#get-allowed-origins means that a USB device would need to explicitly allow http://etcher.io to access it? Which obviously wouldn't be the case for USB Flash drives / SD cards / etc. used with Etcher?

https://github.com/WICG/webusb/blob/gh-pages/explainer.md seems to imply the same thing - sounds like it's more targeted at USB device manufacturers, than software vendors.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/resin-io/etcher/issues/788#issuecomment-257183765, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLUCHyXwbtnkBksoHATJufX8rEc0Wb_ks5q5Re6gaJpZM4KkYoy .

[tssva]

Keep in mind that not all card readers are USB attached. For instance the card reader in the Macbook Pro I'm typing this on is PCIe attached.

[jobukkit]

Offline availability is what Service Workers are for.

[jhermsmeier]

Just a note, WebUSB can be enabled in Electron via the experimentalFeatures option;

new BrowserWindow({
  webPreferences: {
    experimentalFeatures: true
  }
})

[gniezen]

@jhermsmeier Have you been able to get WebUSB working in Electron. I get a DOMException: No device selected after calling navigator.usb.requestDevice, as Electron doesn't bring up the USB Device Chooser menu.

[jhermsmeier]

@gniezen I have recently tried this again, and got the same as you did, and tried some workarounds, like disabling user gesture requirement, but that didn't work either.

[gniezen]

I can confirm that WebUSB won't work in Electron until the Device Chooser menu is implemented. I have requested WebUSB support in Electron here: https://github.com/electron/electron/issues/14545

[jviotti]

Let's close this issue!