
Chromium devs want the browser to talk to devices, computers directly - kiyanwang
https://www.theregister.com/2020/08/22/chromium_devs_raw_sockets/
======
jart
Could we please just fix native software development, so it doesn't suck,
rather than adding the kitchen sink to web browsers?

Web pages and JavaScript are the only universally trusted medium for sharing
information and simple software. Making it possible for news websites to touch
ethernet/usb/serial/gpu compromises that. Same goes for optimizations ilke
JIT'ing and WebAssembly which have certainly done a great job making it
possible for Gawker to reprogram the microcode in AMD K8 CPUs. Has the long
tail of browser innovations made the web go faster? No. It went faster in 2010
IMHO. Whatever performance glut the geniuses who work on Chrome end up
creating, it'll just get gobbled by more aggressive display ads and things
like wild-eyed web component frameworks.

~~~
giancarlostoro
I think WASM will eventually produce the solution (hear me out before you tune
out). I've been thinking about this for a while. So we have WASI[0], which
doesn't yet address the UI issue, but there's half a dozen at least projects
attempting to create runtimes for WASM. If most languages wind up compiling
for WASM / WASI I think eventually a good effort could be done towards a WASI-
UI or WASUI.

Imagine if major OS platforms had a common UI framework that any language can
produce a UI for, every major browser already supports WASM, why not a WASI
based common runtime that would benefit every OS that supports it. I havent
seen anyone else discussing this I've just been contemplating it for a while
and I'm not sure what it would look like short of recreating a cross-platform
X window system.

However, as crazy as I sound my reason for this is simple: the issue with a
lot of UI frameworks is that they tend to be language specific and are mostly
useful to the languages they officially or directly support. If you can build
a UI compatible stack that any language can target, you can gain a lot more
adoption. I could easily see Rust, D, Go, etc supporting a common UI runtime.

Electron sells itself rather easily cause most devs are familiar with HTML /
CSS / JS. What we need is a cross-platform cross-language solution that isn't
XML based but something a language can implement rather simply, or maybe even
a compiler / standard library could manage.

[0]: [https://wasi.dev/](https://wasi.dev/)

~~~
thwarted
_Imagine if major OS platforms had a common UI framework that any language can
produce a UI_

This has been attempted a number of times, both in the browser and without,
and it always comes down to people complaining that the widget set isn't
"native" in look and feel and operation, and the pendulum swings back the
other way.

People used to complain that browser widgets didn't confirm to the OS's UI
guidelines. Then you could style them with CSS and things really started
looking crappy, then you have web UI frameworks that forgo all that
customization (or at least discourages it in the name of ease of development).

~~~
rubber_duck
Umm - a large group of most popular productivity apps are cross platform and
look nothing like native - from dev tools like IDEA, VSCode over Slack, MS
Office, to multimedia tools like Adobe tools, almost all 3D modeling software
like maya, max, audio software like Ableton, FL. None of the apps I use on a
day to day basis look native (ie. like the apps provided by Apple)

You are confusing cross platform UI with frameworks that have programmer art
widgets and no cross platform polish - eg. GTK+, FLTK, and even to some extent
QT widgets (and many more). When people say widgets don't look native they
usually mean "the widgets suck", you can create beautiful cross platform apps
- Electron has quite a few because it allows standard designer tools from web
dev.

Flutter is another promising development, but the desktop port seems
underwhelming - it's obvious the widgets were intended for mobile apps, they
will probably need a custom widget set to cover desktop UI - but the approach
is sound.

~~~
thwarted
If MS Office was truly cross platform in look, feel, and operation, then
finance people who insist on using Excel wouldn't also insist on using Windows
just to use Excel.

All those specialized tools can get away with having completely-unlike-
anything else UI/UX because people are paying for them and they are considered
best(and only)-of-breed.

Electron apps are cross platform only in terms of them looking alike on
different platforms, because they use the same widget set. If slack was a
truly, full native app on OSX, it wouldn't look like it does.

~~~
WorldMaker
In my experience, finance people who insist on using Excel only on Windows
generally do so not because of any reliance on "native controls", but on
longstanding dependencies upon VBA macros with hard-coded dependencies on
specific legacy COM components.

------
Animats
_" Note that this capability is already available to Chrome Apps and
Extensions and in no scenario will we be handing it out like candy to any
website that asks nicely; [the API] will come with a higher barrier to use."_

Involving Google as a gatekeeper, of course.

Google is trying to establish the level of control on the Web it has on
Android.

~~~
ffpip
Google just wants browsers to become more powerful cuz then more people will
use Chromebooks. since everything can be done on a browser.

Why do you think PWA's are being pushed so hard by google? So people can build
PWA's that also run on Chromebooks. No need for native apps

~~~
dsun179
I think PWA's were pushed because the google cannot crawl native applications
for its search engine.

~~~
oakesm9
With a few tweaks to a native app, they can
[https://firebase.google.com/docs/app-
indexing](https://firebase.google.com/docs/app-indexing)

On Android they already crawl your app with various devices when you upload it
to Google play and let you know about any crashes or accessibility issues.
Nothing to stop them capturing the content too if they wanted.

------
adriancr
Local apps

\- I can install once and check signature.

\- I can store them in a backup for later forensics if they do something bad.

\- I can firewall the process only to required services.

\- I can disable outside network access for local process.

\- I can analyze what it does before and after the fact.

\- They can be scanned by a malware scanner / virus scanner.

Web apps:

\- need network access to load (and probably at runtime?),I cant firewall
off...

\- can be refreshed by app provider - targetted to a specific user.

\- Traffic is bundled together with chromium?

\- I have no clue after the fact what happened. I cant sniff https traffic
that app used to load its code...

Bad App owners should be considered as well... or well intentioned but hacked
ones...

~~~
ReactiveJelly
We could bring those advantages to web apps, but there isn't money in it, so
it won't happen yet.

~~~
adriancr
wouldn't that mean making them native apps, like something on top of electron?

seems like reinventing the wheel.

~~~
kevingadd
The web platform has lots of tech now for fully offline web apps - the
currently used term for this is a 'PWA' or Progressive Web Application. On
Android and iOS in many cases there's a little option in your browser to
install a website as a PWA, which puts it on your home screen and locally
caches the assets. IIRC Twitter and Google Maps both support this for their
website.

Of course, writing a PWA is still a huge pain in the ass, and it doesn't give
you those guarantees you mention from native apps - auditability, etc. But
maybe it could get there, who knows...

------
classichasclass
As a gopher dweeb forced to write hackarounds like an external helper to get
Firefox into Gopherspace again (either a proxy server:
[https://addons.mozilla.org/en-
US/firefox/addon/overbitewx/](https://addons.mozilla.org/en-
US/firefox/addon/overbitewx/) or an actual executable:
[https://addons.mozilla.org/en-
US/firefox/addon/overbitenx/](https://addons.mozilla.org/en-
US/firefox/addon/overbitenx/)), I'm torn. I would love to see the browser able
to speak raw TCP again like I could when XUL/XPCOM extensions were still a
thing. But this should really be restricted to browser extensions rather than
arbitrary websites because we know someone is going to abuse it, and if we go
full Windows Vista as proposed here and ask every connection to be confirmed
it will eventually annoy people enough that security will be slackened (and
then someone is going to abuse it).

~~~
dependenttypes
The next thunderbird will contain OpenPGP support build-in because they are
finally getting rid of XUL addon support and enigmail would not work with it.

~~~
floatingatoll
Context: [https://blog.thunderbird.net/2019/10/thunderbird-enigmail-
an...](https://blog.thunderbird.net/2019/10/thunderbird-enigmail-and-openpgp/)

> _" It has always been my goal to have OpenPGP support included in the core
> Thunderbird product."_

------
kevingadd
Until widespread code-signing exists on the web this seems incredibly reckless
to expose. Even if you require https and put it behind a modal, history has
shown that both of those measures are not impenetrable barriers to attackers
and raw sockets open up a whole new set of attacks.

HTTPS is basically useless for authenticating dangerous code: There are
thousands of https domains out there that you can easily put your own code
onto, and many of them have EV/DV certificates with reputable names like
GitHub attached to them so there won't be any obvious red flags other than the
text of the domain name. A prompt with a textbox in it is a barrier but it's
not hard to get users to paste random stuff into text fields (just look at the
big message that appears when you open devtools in Discord warning people not
to paste stuff in there) and I agree with the concern that eventually the text
box will be made friendlier.

Many existing Dangerous APIs have worst-case attacks that just do things like
talk to a USB device from a small list of authorized devices or talk to a MIDI
keyboard. Raw Sockets are an entire new world of attacks: Hit a router or PC
on the local network with a zero day and get persistent root on it, then use
that to spread through the network and perform a ransomware attack, etc. The
blink team needs to accept reality and catch up with where native apps have
been for over a decade: Require code signing with revocable certificates and
pair that with a mechanism to ensure the code was signed by the owner of the
domain.

~~~
lukevp
Why does discord even let users access dev tools? This is trivially easy to
disable in prod builds. Seems odd. Is there a valid use case?

~~~
akersten
> Why does discord even let users access dev tools? This is trivially easy to
> disable in prod builds.

Even if you disable the usual way to pop the dev tools open in desktop
electron mode, this is a dangerous attitude. A malicious client can _always_
edit the DOM, send arbitrary data to your server, read whatever you send back,
etc. "Disabling the dev tools" is never the correct solution to any security
problem.

~~~
lukevp
I didn’t say that they should do this for security of the execution
environment of the code, I’m not sure how you got to that interpretation. The
GP said that there is output to tell users not to compromise themselves by
blindly pasting unsafe code, which is easily prevented by disabling dev tools
altogether, and there is no reason for an end user to have access to dev tools
in an electron app. The other replies are probably what the GP meant and were
related to the web version of discord.

~~~
j-james
> there is output to tell users not to compromise themselves by blindly
> pasting unsafe code

For reference: [https://user-
images.githubusercontent.com/47160230/51995729-...](https://user-
images.githubusercontent.com/47160230/51995729-275e2680-24ab-11e9-8b1b-470c62883ec0.png)

This is also present in the Electron version of Discord.

> there is no reason for an end user to have access to dev tools in an
> electron app.

Certainly there is - there are various user-made applications that take
advantage of Discord being built on Electron to allow you to write your own
custom styles and scripts.

------
nikkwong
I don't know; I understand the cynicism here.. But can we assume an optimistic
scenario where vendors are able to properly address the security implications
and this enables web developers to build all kinds of new applications? I for
one would love to be able to write web applications that could, say, control
the lights in my house or smart devices. I hate interfacing with my phone to
control these types of actions; I don't have the same bandwidth with my phone
as I do with a full-blown computer, and therefore use my phone as little as
possible. Therefore, I am closed off from really having fine-grained control
over the devices on my LAN. Using the browser for this type of behavior would
be awesome, IMO.

~~~
nobodyandproud
The cynicism isn’t fully appreciated, if the optimistic scenario is assumed.

Security is hard, and exposing more by default (or making it defacto required)
is simply asking for trouble.

~~~
zepto
It’s funny - in the arguments about Apple and the App Store, I’ve seen plenty
of people making the opposite case - ‘it’s not scary out there’, the security
benefits of the App Store are ‘bullshit’, etc.

~~~
nobodyandproud
Using both I prefer Apple’s philosophy.

I like Google’s stock phone and features more, but I like that Apple is strict
about about something that has my personal info.

It’s worth the money.

------
tasubotadas
This is good. I guess. I have to develop relatively complex desktop-like
applications on Chromium platform and I still feel that there are quite a few
gaps until it can become a full desktop-able development platform.

What's really missing for me is Android-like permission system where website
could request permissions to access webcam, bluetooth, microphone, local
storage, notifications, audio playback etc...

At the moment, most of the access is provided by a number of different APIs,
and, in some instances, it is heuristics-based decision (looking at audio
playback).

------
wdr1
I would have loved this in 2008 for the Beijing Olympics. My team created the
point of sale, which included printing specialized tickets on specialized
printers. These were going to be deployed across 1,000+ Bank of China
locations, including many in pretty remote regions.

Instead, we created an applet to handle the IO with the printer. It was a
nightmare. All sorts of little differences between Windows XP & JRE made it
ridiculous hard to debug. While the banks were given exact specs, the culture
was such that whenever they would have a problem, they insist the machine was
the right spec, which wasn't true 90% of the time.

------
chmod775
Have they even fixed websocket portscanning, canvas/audio/font fingerprinting,
their crippled request blocking API etc. etc. before coming up with this new
privacy and security nightmare?

Can we maybe have a breather?

There must be something about the term _sandboxed environment_ that makes
people want to poke holes in it.

------
cannedslime
I am kind of against all of this, as it will inevitably lead to better
fingerprinting. I already think its a serious breach of privacy that browsers
supply hardware information such as joysticks and game controllers connected
etc. without any kind of permission dialog. This is even worse because it
allows for malicious websites to absolutely pwn the living sh*t out of the end
user. You thought that ebays port scanning through websockets was bad, then
just wait to see what they will use this for.

------
greenyoda
See also yesterday's discussion:
[https://news.ycombinator.com/item?id=24249392](https://news.ycombinator.com/item?id=24249392)

------
sayusasugi
Guys, "The Birth & Death of JavaScript" was supposed to be a joke. In all
seriousness though, I'm beginning to get tired of webdevs reading OS books and
going "oh, this would be a great addition to The Web™". Slap "in the browser"
after a feature all operating systems have supported for decades and you'll
hit the front page of HN in no time. What's old is new again and all that.

------
modernerd
The upcoming WebTransport/QuicTransport seems like it would address similar
use-cases but with some built-in security considerations:

[https://web.dev/quictransport/](https://web.dev/quictransport/)

[https://wicg.github.io/web-transport/#privacy-
security](https://wicg.github.io/web-transport/#privacy-security)

------
klyrs
Browsers in ring 0? Why not, it's 2020, anything could happen. Ditch WASM,
more languages support ASM anyhow.

------
totetsu
Would webkit ever come along with this?

~~~
millstone
Absolutely not.

------
z3t4
Would probably be better to have abstractions on the protocol level rather
then raw ip or radio.

------
api
Security concerns here are overblown, and this is IMHO more useful than
WebRTC. This is how it should have been done to begin with, as well as the
ugly hack known as web sockets.

There should be some restrictions. No ports under 1024 without asking the user
would go a long way.

Anyone saying “the web isn’t an application platform” needs to just accept
reality. That ship sailed almost 20 years ago.

~~~
xg15
> _That ship sailed almost 20 years ago._

Which would still be some time _after_ the 1024 port distinction stopped being
relevant for security.

