121–130 of 134 posts
Earlier quoted context omitted.
How does WebRTC reveal my IP address in a way that regular browsing does not? Can you point me to a site to see what is being leaked?
Here is a link from ExpressVPN that displays whether your local IP address is being leaked. https://www.expressvpn.com/webrtc-leak-test
Earlier quoted context omitted.
Here is a link from ExpressVPN that displays whether your local IP address is being leaked. https://www.expressvpn.com/webrtc-leak-test
I am not sure, if I understand correctly, but it seems it is only an issue, if I am using a VPN? Because without a VPN, I am naturally "leaking" my IP, as this is how the internet works?
Earlier quoted context omitted.
If those POST/GET requests are coordinating the transfer and exchanging metadata, "no server involvement" is still wrong. It's like saying you can connect to a domain name like google.com with no DNS involvement, because you only get the address and then the connection is over HTTP.
No-one said anything about the "no server involvement" claim here. What's disputed is capableweb's comment that the app is sending the file itself to the server and not even using WebRTC, which is incorrect. They even say "checking how it works is trivial if you open up the Network inspector" but WebRTC traffic does not show up in there. So much for it being "trivial".
> So not really "no server involvement".
and capableweb said (3 posts up):
> How is this even close to being "no server involvement"? It's misleading, because the server is very much involved here.
No one said the file was being sent through the server, that's your own reading of it. You are entitled to your opinion but don't tell people off about "no one said this" or "what's being discussed", it's just rude.
Seems to be using WebRTC, so presumably it's using STUN servers to do the NAT hole-punching. So not really "no server involvement". But I suppose that would be basically impossible on today's internet. Hopefully it's not also using TURN servers if STUN fails...
Even in the land of IPv6 there would have to be something to punch a hole in the end user's firewall rules. Any good end-user router will default deny incoming IP traffic. Assigning public IPv6 addresses to every device in your home just pushes the "deny" rule to a slightly different part of the network stack. We will still require something similar to STUN to get around firewall rules.
If you can get around the firewall rules with something like STUN then those rules aren't really doing you much good, are they? By all means, put random IoT devices on a separate VLAN and block all incoming connections directed there (without UPnP). And be sure to block all the obvious workarounds like STUN for that VLAN or there's no point in having the firewall. But for PCs, smartphones, and the like it should be possible to connect to their open ports from outside the network using their public IP addresses without any tweaks at the router. These devices are perfectly capable of securing their own listening ports.
Earlier quoted context omitted.
This comment would be more useful if you said what browser you were on when you received that error.
You will get this status message if R = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection || window.msRTCPeerConnection; U = window.RTCSessionDescription || window.mozRTCSessionDescription || window.webkitRTCSessionDescription || ["window.msRTCSessionDescription"]; R && U || (w.style.display = "none", This is misleading, You can be using Mozilla/Chrome with WebRTC disabled.
I'm betting browsers (or at least FF) make it deliberately hard to tell if the browser is in a "has WebRTC capability but it's disabled" state (to avoid fingerprinting), so I don't really place the blame on the author.
Disabling WebRTC is something that was deliberately done, so that's on you to remember that you turned it off. Sure, the message could be more helpful and say "this website requires WebRTC to function", but a browser with WebRTC turned off is in fact not supported by this service.
Earlier quoted context omitted.
No-one said anything about the "no server involvement" claim here. What's disputed is capableweb's comment that the app is sending the file itself to the server and not even using WebRTC, which is incorrect. They even say "checking how it works is trivial if you open up the Network inspector" but WebRTC traffic does not show up in there. So much for it being "trivial".
Yes, they did. kelnos said (4 posts up): > So not really "no server involvement". and capableweb said (3 posts up): > How is this even close to being "no server involvement"? It's misleading, because the server is very much involved here. No one said the file was being sent through the server, that's your own reading of it. You are entitled to your opinion but don't tell people off about "no one said this" or "what's…
> Not even, the application is making GET, POST and PUT requests to send the file to a /link endpoint
Capableweb definitely said the file is being sent to the server. Not sure how much more literally that could be said, in fact. You somehow managed to quote the second line of that comment (some might say "cherry pick") while completely missing the first line where they explicitly said what it was claimed they said. Genuinely not sure if you're being deliberately misleading or have some of the worst reading comprehension I've seen on the internet.
As an alternative, you could use: https://wormhole.app/
Earlier quoted context omitted.
Yes, they did. kelnos said (4 posts up): > So not really "no server involvement". and capableweb said (3 posts up): > How is this even close to being "no server involvement"? It's misleading, because the server is very much involved here. No one said the file was being sent through the server, that's your own reading of it. You are entitled to your opinion but don't tell people off about "no one said this" or "what's…
This thread is devolving rapidly but: > Not even, the application is making GET, POST and PUT requests to send the file to a /link endpoint Capableweb definitely said the file is being sent to the server. Not sure how much more literally that could be said, in fact. You somehow managed to quote the second line of that comment (some might say "cherry pick") while completely missing the first line where they explicitly…
If you and Kiro could just recognize that different people can understand that sentence in different ways, we wouldn't be there, but instead you like to proclaim that "no one is saying anything about" and "what's being disputed is" and other "that other person definitely said"
I can see how I'm expecting too much of you. You have a nice day now, though I'm sure it will be full of people not understanding things exactly as you do.
As an alternative, you could use: https://wormhole.app/
Earlier quoted context omitted.
This thread is devolving rapidly but: > Not even, the application is making GET, POST and PUT requests to send the file to a /link endpoint Capableweb definitely said the file is being sent to the server. Not sure how much more literally that could be said, in fact. You somehow managed to quote the second line of that comment (some might say "cherry pick") while completely missing the first line where they explicitly…
Yes, in order to send the file, the application is making GET, POST, and PUT requests. He didn't say the file was sent over the requests. We obviously understood this differently. If you and Kiro could just recognize that different people can understand that sentence in different ways, we wouldn't be there, but instead you like to proclaim that "no one is saying anything about" and "what's being disputed is" and othe…
> uploading happens by doing a POST request to the server, and fetching happens by doing a PUT request, not sure why people keep re-iterating that it's probably WebRTC when it's really not, this is just a very basic, centralized server that does the receiving/sending of the file
