Going To War With My Phone

Will Truman

Will Truman is the Editor-in-Chief of Ordinary Times. He is also on Twitter.

Related Post Roulette

15 Responses

  1. Mike Dwyer says:

    Is this something that could be accomplished by hard-wiring directly to the PC?Report

    • Will Truman in reply to Mike Dwyer says:

      Yeah. That’s pretty much the only way to move large amounts of data to the device. But it shouldn’t be necessary. Once you’re used to being able to carry the phone around with you while files are transferring, it becomes conspicuously inconvenient.Report

      • Mike Dwyer in reply to Will Truman says:

        I wonder if the bluetooth SD cards would allow you to get around this?

        http://www.eyefi.com/Report

      • scott the mediocre in reply to Will Truman says:

        yep, but still infinitely less of a pain than iOS

        if “Once you’re used to being able to carry the phone around with you” is limited to a single 802.11 ESS (otherwise what exactly do you mean?), you should be able to do what you want by transferring the files in AirDroid. At least I can with my unrooted S4 running 4.4.2, though how long that continues to be the case I don’t know.
        Report

      • @scott-the-mediocre Dude! That’s great! I like being able to do so from the device rather than from a computer, but I can work with that. In some cases, it may actually be more convenient.

        Notably, though, AirDroid comes up with a warning saying that external SD card use may be limited. Works fine for me, but I’m rooted. Works fine for you, though, so maybe they’ve got a good workaround. I’m not sure why Android would treat AirDroid tinkering with files differently than ES File Explorer doing the same. Hmmm…

        Let me know if it stops working for you. It may not be ideal, but it’s enough that if it’s still working I will worry a lot less about my next phone not having the workaround my current phone (currently) does.Report

  2. Patrick says:

    The right solution is for SD cards not to use FAT.

    That’s been the right solution for a while now. Indeed, the right solution is for Android to ship future phones which just format SD cards as ext3 (or, even better, eCryptfs). In order to get data off your phone, you’d have to have the phone on (so it could run some sort of SMB service to export the file system to something windows/mac could read).

    Actually, the right-right solution is for Windows and Mac to be able to read and write to file systems other than their own.

    The only drawback would be you couldn’t share SD cards with cameras, until cameras started using a similar file system. That’s not a killer, there isn’t a patent of ext3, problem solved.Report

    • Lyle in reply to Patrick says:

      Note that there do exist ext3/4 readers and file systems for windows, just not built in.Report

    • David Parsons in reply to Patrick says:

      I think the right solution is to let everyone talk to the SD card. There’s no reason to have uid/gid on a SD device unless you’re running freebsd/linux off it. If the OS mounts the SD card noexec (which should be a sensible default) it shuts off the popular route for exploits and leaves the thing useful as a transport media.Report

      • Patrick in reply to David Parsons says:

        Except it isn’t, because FAT is a grossly inefficient file system, by Microsoft’s own estimations.

        It’s a terrible, horrible, icky, gross alternative for transport media **except** for the fact that everything reads it.

        Well, there is an obvious solution to that: produce operating systems that read and write to multiple types of file systems. Which isn’t really a problem for anybody anywhere except folks who want you using only their proprietary file system **because** they are trying to limit interoperability.Report

      • dragonfrog in reply to David Parsons says:

        Depends what you mean by “exploits”. It would prevent executables on the SD card launching.

        The attack model that this is meant to prevent is rogue apps that claim to do one thing, but end up doing something else, whether maliciously or through programmer incompetence – interfering with the config or data of other apps, or deleting data the user wanted to keep.

        It’s an interesting take on the “user” concept, to me – on single user devices, a multi-user OS essentially lets you trust each software vendor as a different “user”. Which in a way they are, as you’re trusting each of them separately to run their code on your device – so why not apply separations to protect them from one another, in case it turns out one of those trust decisions was misplaced?

        noexec also would not prevent scripts on the SD card running, as long as the script interpreter or shell that’s actually executing is on other media – which basically gets the attacker almost everything that execution would.Report

  3. Michael Cain says:

    Do file management apps recognize external storage connected using an OTG USB adapter? More care required than an SD slot tucked safely away, but better than nothing?

    I seem to be putting more and more stuff in my Dropbox folder(s) so that it’s available to all of my desktop Mac, my Linux laptop, and my Android tablet. Moving really big stuff (eg, a movie) on or off the tablet can take a while, but at least it works. I’ve been thinking about trying Google Drive again — it seemed to be erratic on my Mac — because I’m outgrowing the free Dropbox space and Google’s pricing is much better.Report

  4. James Hanley says:

    They have their reasons, of course.

    What’s their gain?Report

    • The more they control how their devices are used, the more resources they can devote to perfecting that part. So Apple, for example, limits you to iTunes. That way, they can design everything media-related knowing that people are going to be watching videos using iTunes.

      Google wants people using Android with files that are supposed to be in particular places. People using third-party software may put the files in other places. That would prevent Google from being able to design a system around people putting the files in a particular place. They can then release protocols to app developers saying “Users will put the files here.” They can then index them and so on.

      Ideally, they can set everything up so that most of the time users will put files where they’re supposed to put them, but that others can do as they please. Which is where we are right now. The problem arises when they do something that impedes users’ ability to do something “off the grid”… which is what happened here. In a nutshell.

      I would have no objection to putting the files where they want me to put the files. If by doing so I could do what I want to do. The same way I don’t object to the limitations that Apple puts on its users if there was sufficient overlap between how they want me to use an iPhone and how I want to use one. Unfortunately, that’s rarely the case. But basically, my point of view is that if they want me to do things there way, they should make their way so superior that I wouldn’t want to do them my way. Their view, I guess, is that they can’t completely devote their energies towards making it so superior as long as they have have a bunch of people doing things their own way.Report