121–130 of 161 posts
Earlier quoted context omitted.
Consumer PCs are not the real issue by and large, IoT crap that can't even be updated is way more problematic. Having NAT by default helps screen out attacks to those devices.
Not NAT. Firewalls. You don't need NAT to have a firewall.
WebRTC is problematic if you're using a VPN service, with the VPN client running on the local machine. Quoting BrowserLeaks:[0] > IP address detection using JavaScript. Starting work on WebRTC API, the web browser communicates with the STUN server and shares information about local and public IP addresses even if you are behind NAT and use a VPN or Proxy. This tool will show if your real public IP is leaking out. How…
For 'Public IP' that sounds like a VPN configuration issue. Your WebRTC Agent should be routing the STUN requests through the VPN (and getting that public IP). But this effects all software/protocols, so don't think it is fair to ding WebRTC for this!
[0] https://bloggeek.me/psa-mdns-and-local-ice-candidates-are-co...
WebRTC is problematic if you're using a VPN service, with the VPN client running on the local machine. Quoting BrowserLeaks:[0] > IP address detection using JavaScript. Starting work on WebRTC API, the web browser communicates with the STUN server and shares information about local and public IP addresses even if you are behind NAT and use a VPN or Proxy. This tool will show if your real public IP is leaking out. How…
Chrome (and maybe other browsers, too) no longer share local IP address. They share the mDNS address instead, which is often generated and registered locally by the browser. It's used only if the peers are on the same network. Else, it's useless but it used to be provided to all peers and malicious websites and they stopped doing that (speaking for those browsers that support mDNS)
Public IP Leak in VPN SOLVED:
In Chromium version 48+, you can set webRTCIPHandlingPolicy to default_public_interface_only which means that any VPN proxy will carry WebRTC media (over UPD if it supports UDP or else over TCP, which impacts quality of transmission)
Your VPN provider just has to provide a Chrome extension to do the above or advise you to do that yourself. That way, the VPN's proxy IP address is what's visible to STUN, not the user's public IP address.
There is also a more elaborate way around it, but the above should work.
WebRTC is problematic if you're using a VPN service, with the VPN client running on the local machine. Quoting BrowserLeaks:[0] > IP address detection using JavaScript. Starting work on WebRTC API, the web browser communicates with the STUN server and shares information about local and public IP addresses even if you are behind NAT and use a VPN or Proxy. This tool will show if your real public IP is leaking out. How…
Local IP leakage has been fixed! WebRTC uses mDNS candidates now, so there is nothing that shows your 'local IP' anymore. For 'Public IP' that sounds like a VPN configuration issue. Your WebRTC Agent should be routing the STUN requests through the VPN (and getting that public IP). But this effects all software/protocols, so don't think it is fair to ding WebRTC for this! [0] https://bloggeek.me/psa-mdns-and-local-ice…
WebRTC is problematic if you're using a VPN service, with the VPN client running on the local machine. Quoting BrowserLeaks:[0] > IP address detection using JavaScript. Starting work on WebRTC API, the web browser communicates with the STUN server and shares information about local and public IP addresses even if you are behind NAT and use a VPN or Proxy. This tool will show if your real public IP is leaking out. How…
Local IP leakage has been fixed! WebRTC uses mDNS candidates now, so there is nothing that shows your 'local IP' anymore. For 'Public IP' that sounds like a VPN configuration issue. Your WebRTC Agent should be routing the STUN requests through the VPN (and getting that public IP). But this effects all software/protocols, so don't think it is fair to ding WebRTC for this! [0] https://bloggeek.me/psa-mdns-and-local-ice…
What makes this really interesting to me is that it uses a golang implementation of WebRTC on the server side. When I was playing with multiplayer networking in the browser ~1.5yr ago, there really didn't seem to be a lot of options for WebRTC servers. Great to see some progress here. Also, it sounds like it's using streaming rather than loading the entire file, which would give it an advantage over https://file.pizz…
I stumbled upon patchbay the other day and I thought it was really cool, now I just need to find a good excuse to toy with it. Just a heads up: the homepage still references the old index.html which you say in your blog article might have the wrong paths. Indeed looking at the docs all paths require a mode
Earlier quoted context omitted.
Things have changed (alot!) the last two years have seen a couple implementations come around. * https://github.com/pion/webrtc * https://github.com/aiortc/aiortc * https://gstreamer.freedesktop.org/documentation/webrtc/index... * https://github.com/rawrtc/rawrtc
Ooh, these are very cool. Do you know what sorts of things people are building with them?
Interesting note that this guy's choice of PAKE, Cpace, was chosen about a week ago by the CFRG for use in IETF protocols. Cpace is new, but that's a big vote of confidence for it.
There are some implementation notes in the README: https://github.com/FiloSottile/go-cpace-ristretto255