4 ms·

Modern P2P does not generally consist of hanging your whole system online with its pants down. They're specialized protocols with authentication, and Rust and G

by api 5y ago

Modern P2P does not generally consist of hanging your whole system online with its pants down. They're specialized protocols with authentication, and Rust and Go are popular in the space because they are safe languages.

xg15 5y ago
The problem is how consumer internet connections should be configured. If you're an ISP, your choices are basically just that: Expose user networks fully and trust that all users have enough expert knowledge to put up their own firewalls - or put up a common firewall for all users. Right now, the default is option #2. Unfortunately, this means that the ISP will configure the firewall to support the most common use case - which for consumer internet right now is a user without any technical knowledge who just wants to browse the web. So outgoing connections only, it is. Switching to option #1 would mean that the networks of all users are exposed, whether they want to use P2P or not. And for anyone who is not an expert, this would mean exactly that: hanging your whole system online with its pants down. What we'd really need is an ISP who lets you configure exceptions in the ISP's firewall yourself. However, this would mean significantly more effort for both the ISP and the user. I think it's unlikely, an ISP would offer such a feature without charging extra for it - and even if they were, it would mean that P2P software would still not work out of the box but would need configuration on the user's side. To sum up: Right now, I don't see how P2P software is usable for non-expert users without opening up glaring security holes. With "security holes", I mean everything else that runs on the user's network. The P2P software itself can be perfectly secure, but that doesn't matter if the cheap IoT device on the same LAN has a well-known RCE vulnerability and the vendor doesn't bother to patch it. This all assumes an ISP who is fully on your side and doesn't have business interests on its own - such as actively blocking consumers from running servers at home because they also sell dedicated servers in a separate business unit. What I can see as a pragmatic way forward is more along the lines of WebRTC and ICE: Make direct connections if possible, use a TURN relay server otherwise. It sucks that you still need a control server to coordinate matchmaking between peers. I wonder if we could have something like "(almost-)serverless WebRTC" in the future, where we can exchange the control information through other means - e.g. QR codes, bluteooth, emails, etc. I also really hope, we get back more LAN-only devices in the IoT space. Currently, it seems insane that my smart light switch has to talk to half a dozen cloud servers to activate my smart lightbulb half a meter away.
- jatone 5y ago
  the role of ISPs are not to act as your firewall. that's your routers job. NAT does nothing to increase that security realistically since most routers are closed by default to inbound connections. NAT as security is purely in the corporation realm of usefulness and afaik IP6 supports NAT just fine. it just wouldn't be a fundamental requirement for the internet to even exist.
- lapinot 5y ago
  > If you're an ISP, your choices are basically just that: Expose user networks fully and trust that all users have enough expert knowledge to put up their own firewalls - or put up a common firewall for all users. This is a false dichotomy. Given that ISPs now overwhelmingly give you some router to plug stuff into, they can very easily have an opt-out firewall configured on the box they give you. That is in fact what i have seen most ISPs do. The incentives for network filtering etc have nothing to do with "protecting the user", this is both easy to do and actually done, frequently the right way (with user-controlled fw).
- cesarb 5y ago
  There are protocols to ask the CPE (which is where the firewall usually is) to temporarily open a specific inbound port to a specific host, like UPnP, and many P2P software already know how to use it. So you can have a "deny inbound by default with state tracking" firewall, while still allowing P2P software to work without relay servers and similar tricks.

by api 5y ago

xg15 5y ago

The problem is how consumer internet connections should be configured. If you're an ISP, your choices are basically just that: Expose user networks fully and trust that all users have enough expert knowledge to put up their own firewalls - or put up a common firewall for all users. Right now, the default is option #2. Unfortunately, this means that the ISP will configure the firewall to support the most common use case - which for consumer internet right now is a user without any technical knowledge who just wants to browse the web. So outgoing connections only, it is. Switching to option #1 would mean that the networks of all users are exposed, whether they want to use P2P or not. And for anyone who is not an expert, this would mean exactly that: hanging your whole system online with its pants down. What we'd really need is an ISP who lets you configure exceptions in the ISP's firewall yourself. However, this would mean significantly more effort for both the ISP and the user. I think it's unlikely, an ISP would offer such a feature without charging extra for it - and even if they were, it would mean that P2P software would still not work out of the box but would need configuration on the user's side. To sum up: Right now, I don't see how P2P software is usable for non-expert users without opening up glaring security holes. With "security holes", I mean everything else that runs on the user's network. The P2P software itself can be perfectly secure, but that doesn't matter if the cheap IoT device on the same LAN has a well-known RCE vulnerability and the vendor doesn't bother to patch it. This all assumes an ISP who is fully on your side and doesn't have business interests on its own - such as actively blocking consumers from running servers at home because they also sell dedicated servers in a separate business unit. What I can see as a pragmatic way forward is more along the lines of WebRTC and ICE: Make direct connections if possible, use a TURN relay server otherwise. It sucks that you still need a control server to coordinate matchmaking between peers. I wonder if we could have something like "(almost-)serverless WebRTC" in the future, where we can exchange the control information through other means - e.g. QR codes, bluteooth, emails, etc. I also really hope, we get back more LAN-only devices in the IoT space. Currently, it seems insane that my smart light switch has to talk to half a dozen cloud servers to activate my smart lightbulb half a meter away.

jatone 5y ago
the role of ISPs are not to act as your firewall. that's your routers job. NAT does nothing to increase that security realistically since most routers are closed by default to inbound connections. NAT as security is purely in the corporation realm of usefulness and afaik IP6 supports NAT just fine. it just wouldn't be a fundamental requirement for the internet to even exist.
lapinot 5y ago
> If you're an ISP, your choices are basically just that: Expose user networks fully and trust that all users have enough expert knowledge to put up their own firewalls - or put up a common firewall for all users. This is a false dichotomy. Given that ISPs now overwhelmingly give you some router to plug stuff into, they can very easily have an opt-out firewall configured on the box they give you. That is in fact what i have seen most ISPs do. The incentives for network filtering etc have nothing to do with "protecting the user", this is both easy to do and actually done, frequently the right way (with user-controlled fw).
cesarb 5y ago
There are protocols to ask the CPE (which is where the firewall usually is) to temporarily open a specific inbound port to a specific host, like UPnP, and many P2P software already know how to use it. So you can have a "deny inbound by default with state tracking" firewall, while still allowing P2P software to work without relay servers and similar tricks.