Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Direct file transfer via browser with no server involvement

cend.me

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Direct file transfer via browser with no server involvement

#41

Post by hutzlibu »

toastal wrote: post #36
hutzlibu wrote: post #30

Earlier quoted context omitted.

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.

I suppose they develope on chrome and recommend what they know works.

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.)

Re: Direct file transfer via browser with no server involvement

#42

Post by gzer0 »

toastal wrote: post #36
hutzlibu wrote: post #30

Earlier quoted context omitted.

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.

Re: Direct file transfer via browser with no server involvement

#43

Post by capableweb »

apexalpha wrote: post #38

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 Jokes aside I'm intrigued at the "no server involvement". I'm assuming they mean the file isn't tran…

> 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?

Re: Direct file transfer via browser with no server involvement

#44

Post by Asdrubalini »

apexalpha wrote: post #38

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 Jokes aside I'm intrigued at the "no server involvement". I'm assuming they mean the file isn't tran…

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...

Re: Direct file transfer via browser with no server involvement

#45

Post by conradludgate »

rk06 wrote: post #37
dmje wrote: post #15

Used to use sharedrop.io but found the “saved messages” option in Telegram is just the most zero friction option for mobile desktop transfers.

I use Whatsapp for that purpose. 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

FYI you can even text yourself on WhatsApp without needing a group

Re: Direct file transfer via browser with no server involvement

#46

Post by capableweb »

gzer0 wrote: post #42
toastal wrote: post #36

Earlier quoted context omitted.

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".

Re: Direct file transfer via browser with no server involvement

#47

Post by jeroenhd »

xg15 wrote: post #12
jeroenhd wrote: post #10

Looks like a nice POC. Is there a practical reason why this website isn't using HTTPS?

Wait what? It seems to use WebRTC, how is this even possible without https?

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.

Re: Direct file transfer via browser with no server involvement

#48

Post by mnw21cam »

www_harka_com wrote: post #22
hbornfree wrote: post #3

What's happening behind the scenes? Without knowing that it's hard to take the claim of 'no server involvement' at face value. Does the sender have to be up for the receiever to receive?

Yes, sender has to up. Also the file must not be deleted. I checked both and the transfer was interrupted. Neat. :)

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.

Re: Direct file transfer via browser with no server involvement

#49

Post by jeroenhd »

capableweb wrote: post #43
apexalpha wrote: post #38

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 Jokes aside I'm intrigued at the "no server involvement". I'm assuming they mean the file isn't tran…

> 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…

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.

Re: Direct file transfer via browser with no server involvement

#50

Post by capableweb »

Asdrubalini wrote: post #44
apexalpha wrote: post #38

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 Jokes aside I'm intrigued at the "no server involvement". I'm assuming they mean the file isn't tran…

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.
Post reply on HN