Hacker News Reader

> What (...) happened to easily sending data, over the Internet

And for mobile phones - without internet is similar, unnecessarily hard. The other day I was hiking with friends, and wanted to share a .gpx file with the route, at some spot with no cell coverage. I thought: "I 'member, bluetooth can send files". Well, we spent good 15 minutes trying and miserably failed, that's no longer possible in the name of "security". So I had to wait for cell signal to come back and send the file via whatsapp. To someone standing right in front of me.

Huh, I wonder what the problem was. I semi-regularly send files between my Windows laptop and my Android phone. I do recall never being able to get that functionality working properly with a Mac though.

That was between two Android phones, with receiving phone being "oppo" or some such, with stock firmware. Receiving phone would see incoming file request, ask user to accept, then error out with "unknown file", and no way to actually save it. I've sent files via bluetooth from lineageos to lineageos, no problem.

I could totally see it being something stupid in how Android manages file associations or something. The default file managers tend to be fairly crippled and only actually show a subset of files present.

Perfect irony would be if the receiving Android attempts to check the incoming file against some kind of Internet service.

It also possible it just dropped it silently in the Downloads directory.

Otherwise ironical that all of this behaves like the 90s PalmOS which could not store a file unless a program would accept it.

Pretty easy with iPhone+AirDrop. Just bring your iPhones together - it asks if you want to airdrop something, select file, done.

On Android builtin as Share -> Quick Share/Nearby share

Available since Android 6 (c.2015)

Have you tried it? It's horribly slow.

I use it all the time. I guess I'm just patient :-)

I've tried it.

I've had it be horribly slow, wickedly fast, and also absolutely fail to work at all.

The wickedly fast method seems to involve the two devices forming an ad-hoc WiFi network -- just for themselves. 802.11ac/ax is pretty darned fast when there's no competition, on a network with exactly two nodes, and when those two nodes are separated by only a couple of feet.

IIRC, this is not the default mode of operation.

Sometimes, I work with bi-directional amplifiers and distributed antenna systems that are intended to improve cellular coverage inside of a building where there may be little or none of that.

I have a fairly expensive meter at my disposal to use for planning things like this, which analyzes different cellular carriers by frequency, and can output (messy, and with unescaped commas for notes, but eventually-fucking-usable) CSV files of the results -- with GPS coordinates of the measurement location.

This sounds amazing for a person like me in this line of work. But it is not amazing for a person like me in this line of work.

(As a preface for the rest of this, remember: This meter is a tool that is meant to be used in areas of limited or zero cellular coverage -- places where outside RF is problematic for whatever reason.)

1. The meter has a Bluetooth interface that connects to an app on a pocket computer. (This part works fine, usually, except the app often doesn't background properly and silently dies if the user uses their pocket computer to do some other task, which might be fine if the problem was ever reported. [Haha!])

2. The meter expects the pocket computer to have an Internet connection, so it can use that to upload its findings to The Clown. (This part often cannot work, because the whole fucking reason any of this is happening is because cellular coverage is shit inside of a random building.)

3. The meter expects that the pocket computer will provide GPS coordinates, even though it is intended to be able to be used indoors -- without network connectivity, or perhaps even in a Faraday cage. And while modern pocket computers are very good at providing some location data by various means as long as there is internet connectivity or GPS-esque data, all of them fail at this when there is neither Internet nor GPS available. It produces an error [Haha!] when there is no location information available.

4. It does not provide useful errors. It provides errors, but they aren't specific at all and do not promote productive troubleshooting or workflow. ("Oh, there was a problem with your measurement! [Haha!]" is the singular error.)

5. Sometimes, it will even produce an error [Haha!] but record the measurement anyway -- and without recording the error.

6. It stores nothing locally. When an error happens [Haha! Good luck!], it is impossible to quickly see if anything was stored at all, so the only clear path is to repeat measurements that result in an error [Haha!]. This often results in redundant measurements being actually-recorded, but who would know that at the time of measurement. (These measurements often take about 4 minutes each, so these errors [Haha!] and repeated measurements can consume significant portions of an expensive workday.)

7. (Your main point): Exporting a CSV file of [whatever-the-hell was collected] is possible, as long as I want to send it to Google Drive or some other Clown-based service. The CSV is only a few tiny kilobytes at very most, but it won't let me copy the CSV to my pocket-computer's clipboard, or send it in an email, or save it locally on the pocket computer, or send it with Bluetooth to my laptop. It has to be exported to a Clown-based service, and then it can be read from that Clown-based service by some other device. There are no other options presented, unlike in so many other apps in my pocket computer.

8. Continued: While the maker of this meter device has their own Clown, and this Clown is clearly extent on the Internet, this Clown is completely inaccessible outside of their pocket-computer app. I cannot bypass Step 7 by any official means no matter how deep my desktop computing prowess may be.

It is completely shit, and it appears to be the best thing available on the market in this space. (And it isn't even Chinese shit: The company that produces this meter is in Utah.)

There are many ways of sending files between phones, none of them good.

Bluetooth can work, but it is slow as hell, and Apple doesn't support it.

Cloud services are convenient, but you not only you need some signal, but you also uses up your data plan.

If you have USB OTG support, you can simply use a thumb drive, like with your PC, but it is cumbersome and you need the hardware.

There are some somewhat proprietary systems like QuickShare and AirDrop, which are supposed are great when you have support which is not always the case.

Other options include having one phone act as a WiFi AP and host a local HTTP server, there are apps for that (ex: MiXplorer). A bit uncommon, but the advantage is that only one phone needs to do weird stuff, for the other, it is just downloading from a URL.

There are also apps like SyncThing based on P2P networks.

Generally, phones are pretty terrible at dealing with files. Their OS is designed around apps controlling their data rather than around interchangeable files like traditional desktop OSes. The way they want you to work is not by exchanging .gpx files but instead by using some built-in "share" feature of your hiking app. It may be .gpx under the hood, but they don't want the end user to see a file.

I agree and get your point.

But localsend has worked well for me. Yes, it requires an app but if we could get vendors to bundle that rather than a boatload of bloatware.

I know that it would be to optimistic to hope for Google.

See https://localsend.org/

Spread the word.

Localsend looks neat, but they're absolutely pissing into the wind by saying that it is "Open-source Airdrop" in the title in the Play store.

That's a clearcut case of absolutely willful trademark infringement, and it will not go well for the authors when (not if) Apple happens to cast their gaze in that direction.

>Bluetooth can work, but it is slow as hell, and Apple doesn't support it.

Wait, seriously? iPhones still don't support Bluetooth file transfers? I knew this was the case with the first iPhone but I just accepted that's a limitation from the OS being still an early release of a brand new product with limited functionality, I wouldn't have expect this to be the case after 15 years.

Anyway, I'm still baffled we never got a standardized Wi-Fi file transfer protocol, like with Bluetooth but at wi-fi speeds.

Oh right, nevermind, Apple wouldn't have supported anyway versus their own proprietary one that only works on Apple devices.

You first have to get a file from your iOS app. Good luck with that.

Hit the share button and select "Save to Files". Dead easy.

Airdrop? I'm pretty sure it's works without wifi or cellular.

(If you're talking iphone to Android, nvm)

Yeah, I meant cross platform file sharing, since that's what Bluetooth enabled originally, you could send files between whatever brand of phone and whatever brand of PC.

I use https://github.com/marcosdiez/shareviahttp all the time, to share with other phones or with my ereader or PC.

I recently had to have a non-technical person send me a very large file, and encountered this. There really is no good universal way to do this, even here in 2024! File is too big for E-mail, ftp is too big a technical hurdle for the guy. Dropbox requires accounts and sharing and all sorts of access shit for him to figure out. I ended up enabling WebDAV on an existing web server I have admin access to, and luckily he's on MacOS which makes it relatively straightforward to write a file to WebDAV. If he were on Windows I have no idea what I'd ask him to do, since I tried for 20 minutes to figure out how to actually connect to a WebDAV folder in read-write mode and Microsoft thwarted me at every turn.

It's pretty shocking that we don't have a dead-simple cross-platform "send a file to someone over the Internet" solution that doesn't involve cloud servers and accounts and downloading apps.

>File is too big for E-mail,

Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces.

>ftp is too big a technical hurdle for the guy

Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. I'm not sure what happened between then and now, but these days people just say "I'm non-technical" and refuse to learn anything that doesn't involve a GUI. FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use:

1. ftp [ip address] 2. type username 3. type password 4. cd dir-to-drop-files 5. put filename 6. quit

These days, we'd use sftp anyway, but you could also use scp in a single command line which they could simply copy-and-paste from an email, after you have their temporary account set up.

> Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces.

Back then there were far fewer non-technical people using email anyway. In my experience people like office admins wouldn't do anything with split archives they would get the local computer person to do it for them (and the same would happen at the receiving end). They were generally aware of zip files, but might get a local tech to compress things for them even if a split archive wasn't needed.

Or they would just send a floppy in the post if the file would fit on there but the email limit at one end or both was less than 1440K. On one occasion because no one was free to help otherwise I remember a secretary driving a floppy between campusesses to deliver updated slides for a talk because she couldn't get it pushed through email (I forget if the biggest blocker was at the sending or receiving end).

Things changed quite a lot when decent GUI zip tools became common, and again when shell-integrated ones arrived in the Win95 era.

Flipping back through time to now, there are two problems that we didn't have back then:

1. Phones don't have particularly good+friendly archivers, and even if one is found security protections might mean said archiver can't access the data it needs from the app that generated it. As well as talking someone through the archiving process you might need to try work out how to open the relevant permissions and describe that to the remote non-technical user too.

2. Often desktop environments are locked down too, and Windows for instance doesn't come out of the box with an archiver, neither CLI nor GUI, that supports multi-volume archives or encryption worth bothering with.

> Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done.

Some would do that, but I wouldn't say they were the majority by quite a margin in my experience. And not just secretaries: higher paid managers & such too. In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech).

> FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use:

The issue with that was (still is) that they will need telling each time. It isn't their job to do these technical things so if they don't have an active interest they aren't going to spend time learning it, so they can work out the exact sequence for next time unless it happens often enough that they learn by repetition. It isn't hard, but it isn't natural or familiar to many. It is only natural to you and I because we do that sort of thing regularly (or have done it enough in the past that it has become wired in).

>And not just secretaries: higher paid managers & such too.

No, the managers were lazy and insisted on having secretaries print everything out for them, and refused to touch a keyboard.

>In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech).

In my experience in a college, the secretaries could handle their computer-based duties by themselves just fine. They only called for help when they ran into a problem they hadn't encountered yet. But doing basic file management at the MS-DOS command line (this was before Windows) was within their ability.

>The issue with that was (still is) that they will need telling each time.

Yeah, so what? ryandrake above said "I recently had to have a non-technical person send me a very large file, and encountered this", so that's why I countered with this in response to his claim that "ftp is too big a technical hurdle for the guy". It doesn't matter if it isn't natural or familiar; all you have to do is cut-and-paste some simple commands. If you can't do that, you're hopelessly stupid I think. You don't even have to understand the commands! That's my whole point with the utility of a command-line interface in situations like this: you can give someone some explicit commands, and they should be able to follow them exactly, simply by cutting-and-pasting or typing them in. It's not like a GUI interface where you have to try to tell them (perhaps over the phone) exactly where to click, which isn't reliable since you may not be able to exactly duplicate their environment or they might be using a different program or even OS. If you're somehow smart enough to use a computer with a GUI for years (and likely multiple computers: smartphone + PC), but you're too stupid to open a terminal window and cut-and-paste a one-line command, this sounds to me like "willful ignorance".

Anyway, the point is that this is fine for a rare occurrence like this. It doesn't sound like ryandrake has to deal with this problem with this same person on a daily basis.

Briar can send files over Bluetooth.

To me, this seems like a feature the app you're using with the GPX should add to its social settings with a Share With Friend(s) button. Specifically knowing that being in an environment where cell coverage might not be available, it can form adhoc wifi, and push across. Of course, they will want you to allow access to Contacts to know who your friends are. But you've probably already been requested for any of the permissions needed for this feature, because $REASONS

Phones are able to capture MiBs per frame via their cameras, so I wonder if you could make an app that has both playback and recording of data, like displaying an animated QR-like code on one phone and recording it on another.

3.5 floppies were the peak of media for me. Built in case, small enough to fit in a pocket, small and light enough to carry a handful around all the time, cheap enough to share freely, tactile. Nostalgia alert, I recall this from my school days, jacket pocket with all my discs in, we would roam around the school looking for empty rooms with computers, then bang; in goes the floppy and I have all my files. Share something with someone? No issue, copy it on a spare and hand it over... CDs didn't fit in a pocket and had an annoying case, though you needed much fewer of them.

Fellow pocket disk pirate here, loved reading this. We used to spray paint our discs with makeshift stencils to get a camo look (a bit like that one laptop prep scene in Hackers ‘95). Mostly used to collect / trade our .BAS files and the odd bit of saucy content from BBS.

Note to self - add "drop off once to friend" feature to my p2p program. (I.e. it makes sure a copy exists locally until your friend has downloaded the entire transfer, then it can be deleted from your local.)

I think I like you.

But is your program actually P2P? (If it were, then: The sender would know when the recipient has completed the download, because the sender was finished sending it and the recipient has stated that they are done receiving it. And there would be no need for gymnastics.)

Exactly like that. My program is half-way there to doing NAT hole-punching, a bunch of other stuff is missing and I'm deep into yak-shaving right now the likes of you wouldn't even believe, but I have had good progress the last few months. (Been tinkering for years, finally decided to do a serious effort. The commit log goes back years but for long periods very silent.)

Yes, not having physical media sucks. Physical objects just work better on a human scale, we know where we put them (well..) and how to trade them.

> I can't simply copy off some data and actually hand that data to anyone else like I did do with a CD-R. There's always a third party involved

The only thing is writing to a CD/DVD can be a PITA. To me diskettes were very easy when it came to read and write to physical media.

>Sure, I can attempt to lend another person a thumb drive, but that's a much more complicated thing than giving them a throwaway DVD-R was

This I agree with, I have a tough time giving flash drives away for some reason. If one could buy a pack of 10 1gig flash drives for the same price as a box of Diskettes, it would be easier. Right now you can only buy flash drives 1 at a time.

Not only that, but it's hard to buy small flash drives. The smallest I can find in retail stores around me are in the 16-32GB range, which feels like a total waste when all I need is a few hundred MB (i.e. just beyond the email attachment limit).

Smaller flash drives are available online, in bulk, of course, but they're not much cheaper. I guess the cost of flash becomes a negligible part of the total price at the single-digit GB range these days.

At some point small memory sticks were used for like ads and brochures at conferances. They were quite neat and I guess they were bought in bulk.

But I can't seem to find any big packs of cheap small sticks either...

You can get packs of very very cheap microSD cards. Just good enough to put data on once to give to someone and then forget about. No performance or whatever. Trash tier.

> cheap enough to not care about

You can get a ten pack of 16gb drives for $25, which after inflation is in the ballpark of what I remember floppies costing 30 years ago.

Have you tried this?

https://github.com/magic-wormhole/magic-wormhole

There's also various webapps that work similarly: set up the connection then have you transfer data directly to the peer.

With Telegram, you can send ulimited amount of data. Transfer is not always gast, and file size is limited to 2gb, but it works. Including to yourself, so you can use as a free cloud storage. Don't how they pull that off, costwise.

The way it generally works IME is that if I want someone's data I better have my own thumb drive to get it, and if somebody wants mine they better have their own.

You've got to be kidding. There's no way I'm going to plug someone else's thumb drive into my computer. Who knows what kind of malware it could be carrying, like having unprotected sex with a random stranger.

Is it any different when you receive a zip file by email? It could very well have been crafted to exploit a backdoor in your compression program.

It is different.

A USB key can be anything, or even complex combinations of things. It can be a storage device and an HID keyboard input and an optical drive that autoruns software on the PC it is connected to, with all of this being intentionally supported by the host operating system.

No back door is required: This can happen right at the front door, as the operating system does what it is intended to do when it detects new hardware.

And as a parting shot: It can even deliberately physically destroy the host computer's hardware. (Try that with a crafty ZIP file.)

The USB drive I keep on my keychain is named STUXNET, so...

It's easier to exploit somebody's computer using a USB drive, because it can do things like pretend to be a keyboard and spoof your inputs, and because the attack surface is "every USB driver", but we have to assume a skilled attacker can do just as much damage with a DVD+R. AFAIK, no kernel filesystem driver is designed to be robust against maliciously crafted filesystems, and FUSE is not designed to be a security boundary. If you're taking security seriously you have to take the same precautions with each, e.g. disabling automount, and only mounting them in a disposable VM and accessing the files over the network.

And even this might not be enough. Is your OS's partition table code robust against malicious input? I don't think there's any way to disable reading the partition table in Linux when a new block device is detected. In this case even copying a single file to/from the raw device with dd might not be secure.

>But BD-R never really caught on for a lot of reasons: So even if it is cheap-enough, it isn't universal-enough.

I beg to differ. In the 2000s and part of 2010s everyone had optical media readers at home or in the office. In my EU country, radiology offices still use DVDs to share or hand you over your X-ray/CT/MRI images that you can then share with your dentist/GP/specialist for diagnosis.

Yeah, a national cloud system for radiology image storing and sharing part of the national healthcare system the would be much better, but computers and on-line services are still a new confusing thing to the government, so this is what we got now. So every medical practice still has functioning optical readers.

They said BD-R. Blu-ray. Not many computers have Blu-ray drives compared to DVD.

Oh right, my bad. Though around the 2010s IIRC many laptops even on the budget end were being sold with BD reader combo drives.

I held a portable USB3 Blu-Ray reader in my hand once.

I could have used it, too, but I could not think of anything I wanted to do with it by that time in 2017 -- seven years ago -- despite my proclivity for making backups of films.

BD on a PC has never been common in my world of computing, and by 2017 optical drives in general were becoming very uncommon in everyone's world.

It never broadly caught on.

Just at the time Blu-ray would have made sense for computers everything went to downloads. I bought many games that came on CD or DVD but the only ones that ever came on Blu-ray were for console.

And even those are mostly download now.

The GP was on about writable Blu-ray Discs specifically. Writable CDs and DVDs were common place.