News for hackers. Stuff that matters.
Re:Firefox Send: Private, Encrypted File Sharing by padenot on Wednesday October 11, 2017 @09:50AM (#15449722)
Those services are for the initial peer discovery and SDP exchange, which can be done by other means (using any other side-channel).

Ongoing work is happening, for example by the webtorrent folks, to remove this constraint.

Re:Firefox Send: Private, Encrypted File Sharing by AndrewDucker on Wednesday October 11, 2017 @10:07AM (#15449853)
Yeah, it's initial peer discovery and connection setup (if behind NAT) I'm talking about. Once you've found the other PC and got a connection set up then all is well ;-)

Do these services also act as connectors in case of double NAT?

Re:Firefox Send: Private, Encrypted File Sharing by TD-Linux on Wednesday October 11, 2017 @08:52PM (#15454842)
STUN allows all sorts of hole-punching for cases where both peers are behind NATs. For cases where the hole-punching doesn't work (a user behind two NATs might be one case), you can use TURN which is a dumb UDP or TCP relay.
Re:Firefox Send: Private, Encrypted File Sharing by padenot on Wednesday October 11, 2017 @12:16PM (#15450875)
They certainly can, I don't know if they do in practice. It always work for me, so I haven't investigated too much.
Re:Firefox Send: Private, Encrypted File Sharing by the8472 on Wednesday October 11, 2017 @01:53PM (#15451670)
Which is a step backwards compared to bittorrent, since that can also provide decentralized hole punching, bootstrapping and peer discovery and not just the bulk data transfer. Plus being implemented at the TCP/UDP level allows more fine-grained control over the data flow, making it more friendly towards the network.
Re:Firefox Send: Private, Encrypted File Sharing by rakoo on Wednesday October 11, 2017 @11:22AM (#15450482)
They're also needed for the actual javascript code that runs everything.