The latter will surely depend on your operating system and its file handling semantics. In general, in Windows if something is reading a file and you delete the file, then you're actually deleting the file and the reader will be interrupted (assuming you manage to set it up in a way such that you actually can delete the file at all). In Linux, when you delete a file, you are actually unlinking the file from the directory, so the reader maintains a reference to the actual file and can carry on as normal. The free space will be reclaimed when the reference count decreases to zero when the reader closes the file.
Minified and obfuscated so it's hard to tell what's going on in this but it looks like it uses WebRTC to do peer-to-peer transfers, with the aid of a STUN server to establish the initial connection.
Here you have a somewhat unminified/reverse-engineered source: https://pastebin.com/NzP3KMKy Some of the variables are harder to infer what they mean though, so it's incomplete.
That's it. I got the error, enabled WebRTC and it worked. A better error message would be "You need a browser with WebRTC enabled to use this service." Chances are that if the feature check for WebRTC fails the user intentionally disabled it and knows how to enable it again.
If a user knows how to disable webrtc, he or she should also know that this is the technology needed for direct data transmission, so should not wonder why nothing works.
And sure, they could add x finegrained error messages, but I doubt there are too many people who have this setup, that this is remotely a priority.
Is it a part of resistFingerPrinting? If so, users may not know that this is the issue. Also if WebRTC is the issue, then that's what the browser should report, not endorsing a Google product.
You would stand out more if you disabled webRTC. Since webRTC is disabled by only a subset of certain users, this makes them more prone to fingerprinting. Going with the setup that the average joe has would be better for blending in.
Not sure if you'd stand out more. Disabling WebRTC gives the one who is trying to fingerprint two values to one variable: "WebRTC enabled? True || False" while having WebRTC enabled makes the fingerprinter able to get your IP, and it's a lot more detailed than "True || False".
I agree with your first sentence but there are many other possible reasons. When I read the very explicit message "Your browser is not supported, consider downloading Chrome" I assume that this service works only with Chrome and not with Firefox, at least not on Android. Then I come to the comments in HN to complain about that and read that it works with Firefox if WebRTC is enabled, and I remember I disable it. I insist that it's the wrong error message because it hints to the wrong cause. I guess it's possible to disable WebRTC in Chrome too maybe with this https://chrome.google.com/webstore/detail/webrtc-control/fjk...
It surely is a wrong error message, or rather oversimplified error and solution, that should be improved.
But still, if you are deliberately deactivating parts of your browser, I think it is strange to complain, that websites missunderstand you. Especially sites that aim for the masses. Because the error is mainly on your side.
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.
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...
>the application is making GET, POST and PUT requests to send the file
Have you looked at the actual payload of the POST/GET/PUT requests? It only contains the WebRTC offers/answers. Actual file transfer is via local WebRTC.
The site also claims that it only work for "devices on the same network", so there's no need for any STUN/TURN because there's no wall to punch.
Even on the same network you might need TURN. Browsers use mDNS addresses for local connections rather than leaking internal IPs and if your network doesn’t work with it then a direct connection will fail. You can disable this but it’s not ideal.
Getting P2P connections working reliably is an effort in edge case discovery and either fixing it or falling back.
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".
> 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.
> 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.
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 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.
No, it's not a question of interpretation. You simply understood it incorrectly. Another quote from capableweb in this thread which hopefully makes this clear for you:
> 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
This isn't some ambiguous statement that is open to interpretation. They literally said the file is being sent to a /link endpoint. What part of that statement of you struggling to parse?
Originally we did, and we still do, as it's way more convenient. But the bittorrent protocol has been improved so that it doesn't need servers anymore. The Distributed Hash Network can handle peer discovery and search queries too.
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.
The only default-deny rule for incoming traffic for general-purpose, up-to-date hosts should be the one built into the OS which rejects incoming connections to ports where nothing is listening. (If you enable UPnP, as most routers do by default, this is the policy you actually have in practice… just with more steps.)
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.
Alternatively, using the same technology: https://www.sharedrop.io/ and actually multiple others. Quite convincing to transfer files between devices in LAN, instead of looking for USB cable to connect the phone or trying to establish (never working and much slower) Bluetooth connection.
I like sharedrop and was using it for quite some time; but as of late it has become unreliable, either not allowing clicking on other machines, or reporting the transfer as successful when the destination has received nothing at all.
I suspect this is primarily a UI issue, but the whole product is just a UI wrapper on a WWW protocol, so a mere UI glitch is quite devastating.
There are indeed a lot of similar options. Personally I'm partial to https://file.pizza/ because I find the toppings based URL scheme clever and fairly easy to communicate.
WebRTC only requires a secure origin for APIs like getUserMedia, I believe. Sending data back and forth doesn't seem to require a secure origin at all.
Is it? If you have the IP of the sender/receiver, it's trivial to use even something like netcat to send/receive files. Samba works as well if you want something more user-friendly and integrated with the traditional file explorers on various OSes.
Back in the early '2000s we had two home PCs with Windows (98 and 2000/XP), it was a breeze (relatively) to make the two PCs see each other in the LAN, using the legacy workgroup + shared folder/drive letters.
of course security was near nonexistent, but it was home LAN, and convenience trumped all.
Nowadays I have NO idea if I could do a similar setup with Windows 10 without resorting to the cloud
Make the PC see each other in the LAN is just a matter of ticking one box. I typically create a folder somewhere and give r/w access to everyone then I proceed to log in with the credentials of the computer then put whatever I want. After I am finished I delete the folder. I think it uses SMB under the hood.
Yes, it is really sad. I suspect it has to do with anti piracy, that there is no universal simple working solution.
(What comes to my mind, is that windows removed the option to record the audio playing directly - which means slightly advanced users can still record their songs from spotify and co, but the majority cannot)
It's even more worse in the mobile world. I would share a lot of pictures after two weeks holiday with somebody who has an Iphone. I have an Android phone. There is not way to transfer pictures direct from Android to Iphone (holiday location != flat rate). WTF 2021.
1. create a group with some one on your contact list.
2. Kick the other person out of group
3. now, attach any file you want to the group and access it via whatsapp web.
Pretty simple to setup and use. for larger files, i would use ftp client on Mobile and use it to transfer files
This seems incredibly clunky compared to Signal where you by design can message yourself without any hassle (and you're called "Note to Self" in the chat list).
Yeah I do this with files/links/notes/numbers on Signal, where I have myself pinned to the top (Signal calls yourself "Note to Self" in the chat list).
It's very slow for big files though, and requires several clicks on the 2 devices. If you are on the local network, kde-connect is still the golden standard provided you use linux (even with gnome) and android:
- click on the top bar menu to select your device
- select the file
- done
It uploads automatically in the download folder of the other device. It uses the local network speed. Doesn't require additional clicks.
But as soon as I'm on 4G, telegram saved messages is what I use too. In fact, I use it to takes vocal notes, pictures of stuff to remind me later, schedule reminders (yes, it has delayed messages!) and so on. It's my inbox basket for GTD at this point.
I've also been satisfied with Wormhole[1]. Been using it ever since Firefox Send was discontinued.
> If you like Instant.io, try Wormhole from the creator of WebTorrent and Instant.io. It's like Instant.io, but adds end-to-end encryption and links that keep working even after you close your browser.
Didnt read the link as its not https, but if you are looking for a solution to transfer files across multiple devices, try syncthing[0], its opensource and does real time sync
Oh, you mean in-browser P2P? Wait, no, all peers need to be able to resolve cend.me somehow to download the code? What problem is this solving exactly?
Why would anyone use this service when you can just transfer files by temporarely opening a TCP port and starting a netcat listener that you pipe into the file you want? It's as simple as nc -lvnp 1234 > myfile.txt
The other party then only needs to pipe the file into a netcat socket from their commandline. nc -w 3 IP < file.txt
</hacker news>
Jokes aside I'm intrigued at the "no server involvement". I'm assuming they mean the file isn't transferred through the server but directly (WebRTC?). There is probably still some server involvement to get around the firewalls / NAT. I don't think this will work if you just host your own instance of it.
> I'm assuming they mean the file isn't transferred through the server but directly (WebRTC?)
Why are you assuming so, checking how it works is trivial if you open up the Network inspector. I did so in Chrome, and as I said in https://news.ycombinator.com/item?id=29225472, 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...
And what do you mean "host your own instance"? There is no source code available from the website, so how would you host it exactly?
There is WebRTC code in the javascript source. It looks like some kind of POST/PUT code is used to exchange metadata about the files, but the files themselves don't seem to get transferred to the server.
Or maybe you're seeing different behaviour from everyone else because WebRTC is not behaving right and you're getting the fallback behaviour?
The "with no server involvement" part of the title is definitely wrong, this needs some kind of server to orchestrate the transfer itself. The server doesn't seem to receive the file contents, though.
> Or maybe you're seeing different behaviour from everyone else because WebRTC is not behaving right and you're getting the fallback behaviour?
Could be. I've tried it in both Firefox (94.0.1) and Chrome (93.0.4577.63) on Linux (5.15.2), maybe they fallback based on OS if so? Weird, as other websites have no trouble using WebRTC with either Firefox or Chrome for me.
I don't think transferring a file via netcat without any form of encryption is something i would recommend, unless you are on a network you 100% trust.
EDIT: it seems like this service doesn't even support HTTPS...
Not supporting HTTPS together with falsely claiming "no server involvement" when everything happens via the server makes me think this is a honeypot or something like that.
The web page must be served from somewhere, even if the server it came from really wasn't involved in file transfers. It would be nice to have HTTPS for the client to rule out MITM attacks or the like.
I know the context/reference, but still do not get it. It anyway assumes that Dropbox came up with something new, but it didn't - there were already such seamlessly integrated cloud storage providers with user friendly access, e.g. virtual new disk on Windows, tray icon, etc... The only thing Dropbox did differently seems like pure marketing.
Those are not a pipes though, they're redirections. This common mistake surely means your expertise on this matter is lacking and therefor your opinion is worthless.
Contrary to some misleading comments in this thread it is in fact using WebRTC. The crux is that WebRTC doesn't show up in the normal Network tab but if you go to chrome://webrtc-internals/ you will see the action.
WiFi is a half duplex shared medium that can have interference from other WiFi networks and non WiFi speaking sources. All of this makes it extremely difficult to say what is good or not. If that's between 2 clients on the same WiFi network that's actually pretty impressive. If it's WiFi on one side and hard wired on the other with no other wireless clients or interference then it's not really good but not horrendous either.
*except the server website runs on and servers your files will go through since you need somehow connect those two devices unless you are on same network
133 comments
[ 3.2 ms ] story [ 129 ms ] threadDoes the sender have to be up for the receiever to receive?
And sure, they could add x finegrained error messages, but I doubt there are too many people who have this setup, that this is remotely a priority.
There is something called setting priorities. And most do so by marketshare and not idealistic reasons.
(while I actually had great pain, to still support FF out of said idealistic reasons btw.)
https://www.expressvpn.com/webrtc-leak-test
Because without a VPN, I am naturally "leaking" my IP, as this is how the internet works?
https://i.imgur.com/b1NPYmr.png
But still, if you are deliberately deactivating parts of your browser, I think it is strange to complain, that websites missunderstand you. Especially sites that aim for the masses. Because the error is mainly on your side.
(Firefox, 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.
Hopefully it's not also using TURN servers if STUN fails...
How is this even close to being "no server involvement"? It's misleading, because the server is very much involved here.
> But I suppose that would be basically impossible on today's internet.
P2P is possible on the internet (100% without centralized servers), but it's not possible without STUN/TURN on the web.
Have you looked at the actual payload of the POST/GET/PUT requests? It only contains the WebRTC offers/answers. Actual file transfer is via local WebRTC.
The site also claims that it only work for "devices on the same network", so there's no need for any STUN/TURN because there's no wall to punch.
Getting P2P connections working reliably is an effort in edge case discovery and either fixing it or falling back.
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.
> 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.
> 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.
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.
> 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
This isn't some ambiguous statement that is open to interpretation. They literally said the file is being sent to a /link endpoint. What part of that statement of you struggling to parse?
Bittorrent works just fine here.
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.
I suspect this is primarily a UI issue, but the whole product is just a UI wrapper on a WWW protocol, so a mere UI glitch is quite devastating.
of course security was near nonexistent, but it was home LAN, and convenience trumped all.
Nowadays I have NO idea if I could do a similar setup with Windows 10 without resorting to the cloud
Make the PC see each other in the LAN is just a matter of ticking one box. I typically create a folder somewhere and give r/w access to everyone then I proceed to log in with the credentials of the computer then put whatever I want. After I am finished I delete the folder. I think it uses SMB under the hood.
(What comes to my mind, is that windows removed the option to record the audio playing directly - which means slightly advanced users can still record their songs from spotify and co, but the majority cannot)
maybe running python -m http.server in Termux is more attractive.
Nowadays I use nextcloud, mostly because it allows easier sharing with third parties and comes with calendar etc.
1. create a group with some one on your contact list. 2. Kick the other person out of group 3. now, attach any file you want to the group and access it via whatsapp web.
Pretty simple to setup and use. for larger files, i would use ftp client on Mobile and use it to transfer files
AFAIK, there is no way to do that in the mobile app, so you will need to use those Whatsapp redirectors, and redirect to your own number.
I made this phone number -> Whatsapp redirector that you can try. Zero server interactions, only JS.
https://altbdoor.github.io/whatsapp-redir/
"Whatsapp Dialer" in app store.
Or clicking on this link (replace example phone # with your phone number):
wa.me/17861234567
1 is US's country code. 786 is Miami's / Operator code 1234567 is the phone number
- click on the top bar menu to select your device
- select the file
- done
It uploads automatically in the download folder of the other device. It uses the local network speed. Doesn't require additional clicks.
But as soon as I'm on 4G, telegram saved messages is what I use too. In fact, I use it to takes vocal notes, pictures of stuff to remind me later, schedule reminders (yes, it has delayed messages!) and so on. It's my inbox basket for GTD at this point.
[0]https://docs.syncthing.net/index.html
Works great on local network (even mixed: windows/macosx/ios)
Why would anyone use this service when you can just transfer files by temporarely opening a TCP port and starting a netcat listener that you pipe into the file you want? It's as simple as nc -lvnp 1234 > myfile.txt
The other party then only needs to pipe the file into a netcat socket from their commandline. nc -w 3 IP < file.txt
</hacker news>
Jokes aside I'm intrigued at the "no server involvement". I'm assuming they mean the file isn't transferred through the server but directly (WebRTC?). There is probably still some server involvement to get around the firewalls / NAT. I don't think this will work if you just host your own instance of it.
Why are you assuming so, checking how it works is trivial if you open up the Network inspector. I did so in Chrome, and as I said in https://news.ycombinator.com/item?id=29225472, 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...
And what do you mean "host your own instance"? There is no source code available from the website, so how would you host it exactly?
Or maybe you're seeing different behaviour from everyone else because WebRTC is not behaving right and you're getting the fallback behaviour?
The "with no server involvement" part of the title is definitely wrong, this needs some kind of server to orchestrate the transfer itself. The server doesn't seem to receive the file contents, though.
Could be. I've tried it in both Firefox (94.0.1) and Chrome (93.0.4577.63) on Linux (5.15.2), maybe they fallback based on OS if so? Weird, as other websites have no trouble using WebRTC with either Firefox or Chrome for me.
EDIT: it seems like this service doesn't even support HTTPS...
Gave me a good laugh!
Those are not a pipes though, they're redirections. This common mistake surely means your expertise on this matter is lacking and therefor your opinion is worthless.
</hacker_news>
tar c /data/emulated/0 | nc ...
I can't possibly send all photos one by one manually.
(100mbps wifi = 12MBps speeds).
*except the server website runs on and servers your files will go through since you need somehow connect those two devices unless you are on same network