Beaker: Feature Suggestion:Add proxy setting

[monkey000]

For users who live in countries where the network is under review, we need browser support to set up the proxy, such as socks5.

[pfrazee]

We'll put this on the roadmap

[HughIsaacs2]

This probably should go under a separate issue but this just made me realize if we add websocket replication to Beaker for loading Dats (as in the kind offered by dat-gateway), we could put that behind a proxy for proxied Dat support.

It could also open the doors for experimentation on the network side of things, localhost proxies for loading Dats over CJDNS, yggdrasil, i2p, tor, WebRTC, HTTP, and so on.

[da2x]

Configuring a proxy isn’t enough to make Beaker and Dat protect your IP address or really do anything to protect your device’s identity. If you live in a country where you need a strong guarantee for anonymity, then don’t trust it to the web browser or really the application layer at all.

You can install Beaker in Tails OS which will provide much more reliable anonymity than anything Beaker can offer on its own. You’re less susceptible to bugs and possible leaks from Beaker, Dat, or anything in the dependency stack. Beaker really can’t leak your IP address from inside Tails as it has no idea what your IP address is.

Here are four actionable things Beaker can do to help improve user anonymity for users behind Tor, I2P, etc.:

• [ ] Option to disable UDP entirely and only use TCP. UDP is great for performance but doesn’t work over I2P, Tor, proxies, VPNs, etc. Reduces futile connection attempts.
• [ ] Customizable announcement address; allowing users to set their own IP or domain name (e.g. an .onion address.) and port (see also #1256). Hard requirement for I2P support, highly desirable for Tor. Tor has enormous relay capacity but limited exit capacity. Staying within the .onion network improves performance and improves anonymity for all parties.
• [ ] Operate a discovery server on an .onion address that will only accept and respond with .onion addresses.
• [ ] Operate a discovery server on an .i2p address that will only accept and respond with .i2p addresses. Hard requirement for I2P support.

The special-purpose discovery services shouldn’t ever respond with IP addresses to prevent leaks. Tor users can still use the primary discovery servers through exit relays as a fallback, I2P users can’t access anything from outside the network anyway so … they’re just screwed.

Tor support definitely should be the priority given they’ve got millions of daily users.

[almereyda]

This setting will also be helpful for cases in which the ISP NATs the external IP of the WAN/LAN router behind another edge network that provides the exit points for the clients, while prohibiting port forwarding or any public service on the interfaces.

An alternative seems to be using a VPN that provides a public IP address.