Chromium devs want the browser to talk to devices, computers directly
1–10 of 89 posts
Re: Chromium devs want the browser to talk to devices, computers directly
#2As 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/ or an actual executable: 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).
Re: Chromium devs want the browser to talk to devices, computers directly
#3Until 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.
Re: Chromium devs want the browser to talk to devices, computers directly
#4Until 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 you…
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?
Re: Chromium devs want the browser to talk to devices, computers directly
#5Until 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 you…
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?
I assume the parent is referring to the web version, where a big warning is output on the console of the browser’s built-in dev tools. I don’t know of any way for a website to disable the browser’s dev tools.
Re: Chromium devs want the browser to talk to devices, computers directly
#6As 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/ or an actual executable: 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 shou…
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.
Re: Chromium devs want the browser to talk to devices, computers directly
#7Until 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 you…
> Until widespread code-signing exists on the web this seems
incredibly reckless to expose. [...] 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
How would code-signing be any better than HTTPS-certificates? That sounds like just another instance you would have to pay fees to.
Re: Chromium devs want the browser to talk to devices, computers directly
#8Until 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 you…
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?
Many products show this warning e.g. Google Photos, Facebook.
Re: Chromium devs want the browser to talk to devices, computers directly
#9Security 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.
Re: Chromium devs want the browser to talk to devices, computers directly
#10Until 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 you…
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?
> 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.