Comment by dleslie | Hacker News Reader

Comment by dleslie | Hacker News Reader

Parent Full thread

They could ship with IPFS/DAP/I2P/Tor native in Firefox right now, without any requirement of running external software, but choose not to. Instead, we get limited support for IPFS from a desktop-only addon that simply interfaces with an IPFS service already running on the host machine.

Take it a step further: Firefox could allow websites to open sockets and toss arbitrary packets around, and choose not to. If that capacity were available then Javascript could be harnessed to support all sorts of protocols and services. They could even provide Javascript access to monitoring network access point availability and connectivity management.

Imagine then a single page app you could share as an attachment through $messageService and it has all the stuff built in to create ad-hoc real networks in large gatherings that provide data resiliency against the dropping of nodes. You could have the cellular network shut down, protestors arrested, their phones taken, and the data they gathered still retained so long as any node managed to exit the area or the network itself expanded beyond the area of contention.

You have it backwards, stuff like Websockets are built by design to be incompatible with existing implementations. This is because Javascript code is untrusted/untrustworthy, and we already had a plethora of attacks due to foreign JS doing nasty things with what little they had, here's a couple examples:

- SMTP/IRC spamming using Web requests (Cross-protocol scripting, 2002) - https://www.eyeonsecurity.org/papers/Extended%20HTML%20Form%...

- Webpages that detect your router and leak your SSID (or worse) - Samy Kamkar "How I met your girlfriend" (2010), excerpt: https://www.youtube.com/watch?v=tRJMIMBVqFI

Web extensions should allow you to do normal sockets, many years ago I had a Chrome app (I still miss them) as my IRC client.

It's not like Websockets prevent this completely. eBay port scanning: https://www.ghacks.net/2020/05/25/ebay-is-port-scanning-your...

That's a pretty clever attack. It's clear everything can (will?) be exploited at some point, so it's usually down to features vs. user protection.

Unless everyone is ok going back to running random .exe files from emails, I guess.

So treat sockets as one currently treats web cameras and microphones.

> Web extensions should allow you to do normal sockets

Not since 2017 or whenever it was that Firefox dropped XUL extensions and replaced them with WebExtensions. The legacy XUL extensions could do much, much more and there was correspondingly much, much more malware in browser extensions.

> Firefox could allow websites to open sockets and toss arbitrary packets around, and choose not to.

There are very good security and privacy reasons that all browsers (not just Firefox) work extremely hard to prevent this from being possible.

So treat socket access as one does Microphone and Web Cam access.

The problem with that is that regular people (not super-techies) have a much better chance of understanding the implications of agreeing to microphone and webcam use than something called "socket access" - or any other more friendly term that tries to explain what's going on, because it's such a long way away from the level of abstraction that they are likely to understand.

"Allow this Website unrestricted access to the internet?"

Seems no more or less confusing or understandable than allowing access to microphone or camera.

And your internal network.

Right - the original reason for same origin policies in browsers was to prevent scripts from stealing data from private corporate intranets.

I mean, I could honestly see a ton of confusion along the lines of “isn’t this website already on the internet? what??”

Also not knowing if disabling it will break the page, something even technically inclined people can't know ahead of time. It's not like push notifications where you would have to try hard to build pages that could break without the feature enabled. I could easily see people abusing this to serve pages over alternate protocols and making people expect to need to click "allow."

It's implied it will break or limit the page; just as denying access to microphone and video has that implication.

No it isn't? Unless you're doing something with the microphone or video there's no implication there.

Sure there is. If it needs hardware access for a function then without it that function breaks.

It's no more confusing than the warning provided for self signed certificates.

That requires people to know what "access to the internet" means.

A sizable portion of internet users think that the internet is what you get when you click the Facebook icon on your phone.

But they do at least understand what a microphone and webcam are for.

So make the default negative and appealing, and the positive option scary and diminished.

As Firefox does with self signed certificates and similar.

An acquaintance of mine worked for Mozilla on a project to add tor to Firefox. Code was done, but Google, as it’s primary funder, squashed it.

That makes sense. Google wants users to be easily identified and tracked; elsewise their primary revenue model, surveillance capitalism, would be under threat.

>They could ship with IPFS/DAP/I2P/Tor native in Firefox right now

A bit of a tangent, but I really cannot stress enough that if you're using Tor to be private/anonymous that you should never use anything other than the official Tor browser, you will stand out like a sore thumb.

Reply on news.ycombinator.com