Mark Murphy’s Techdirt Profile

commonsguy

About Mark Murphy

Mark Murphy is the founder of CommonsWare and the author of the Busy Coder's Guide to Android Development. A three-time entrepreneur, his experience ranges from consulting on open source and collaborative development for the Fortune 500 to application development on just about anything smaller than a mainframe. He has been a software developer for over 25 years, from the TRS-80 to the latest crop of mobile devices. A polished speaker, Mr. Murphy has delivered conference presentations and training sessions on a wide array of topics internationally.

Outside of CommonsWare, Mr. Murphy has an avid interest in how the Internet will play a role in citizen involvement with politics and government. He is a contributor to the Rebooting America essay collection, and his personal blog features many posts discussing "cooperative democracy".



Mark Murphy’s Comments comment rss

  • Nov 29th, 2017 @ 4:17pm

    Re: Question

    Presumably, that is already a crime.

    For example, suppose that you are riding your bicycle and a pedestrian is walking with their head up and no headphones through an intersection when you have the right of way. If you have the right of way, the pedestrian is committing whatever the pedestrian equivalent is of a moving violation.

    The fact that, in your scenario, the pedestrian is "heads down, headphones on" would not change that. So, whatever laws are against walking without the right of way would cover walking without the right of way with headphones on.

    If there is no law against walking without the right of way, fix that, and it will neatly cover both the with-headphones and sans-headphones scenarios.

  • May 27th, 2017 @ 9:06am

    Re: Technical question about phone security

    There is no "encryption at rest" on phones, right?

    Yes, there is.

    Android devices have offered full-disk encryption since Android 4.2 or thereabouts, though the implementation prior to Android 5.0 sucked. Full-disk encryption is opt-out starting with Android 7.0, meaning that Android devices are encrypted unless the user takes steps to disable that.

    I forget the state of iOS, as that's not my area of expertise, but I am under the impression that full-disk encryption is the norm on newer versions of iOS.

  • Mar 17th, 2017 @ 9:27am

    Who Will Make These Devices?

    Speaking from an Android standpoint, what they want is not even practical in terms of product distribution. It would require manufacturers to:

    • Create a custom Android build that has this filtering built in

    • Distribute models with that custom Android build to Georgia retailers

    • Realize that this sort of mandatory filtering runs counter to enterprise security, and so the sale of Georgia-specific devices will be limited to consumers (and enterprises run by idiots)

    Few manufacturers will bother, given the resulting projected sales numbers.

    Retailers cannot add the filtering themselves in general, because part of the "on-boarding" experience for an Android device frequently involves accepting a EULA. Retailers cannot accept a EULA on the consumer's behalf. Plus, any retailer-installed filters could be bypassed readily by people with the technical skills of your average American teenager, either on their own or via anti-filtering tools that will proliferate rapidly.

  • May 26th, 2016 @ 2:19pm

    CAFC Appeal

    > there's still a decent chance they'll end up siding with Oracle on appeal

    Really? I thought the CAFC was the court that rejected the original trial result, but bounced it back to the lower court specifically to examine the fair use case. If they weren't willing to entertain a jury deciding that it's fair use, they would not have left open that possibility. Right?

    Then again, IANALNDIPOOTV (I am not a lawyer, nor do I play one on TV).

  • May 12th, 2016 @ 10:10am

    Re:

    > That's because we can create the API but we cannot create the ABI.

    Everybody on the planet can create the ABI, given training. It's not out of the question that I could teach Naruto (of monkey selfie fame) to create an ABI, given sufficient bananas. And assuming that Naruto likes bananas, as I have not had an opportunity to inquire with Naruto's agents on that subject.

    Hand-entering machine code is a pain, which is why we created programming languages, from assembler on up, to ease that pain. This does not make hand-entering machine code impossible, any more than the existence of a shovel makes digging a hole with bare hands impossible.

    > No amount of code written in Java works without the compiler

    Nonsense. Just because you have not seen a pure-interpreter Java environment does not mean that they do not exist or cannot be created.

    > Has anyone actually read them?

    Yes. Have you?

    > here's what a typical GNU/GPL licenses says:
    "You can use our software and do what you want with it, but you can't sell it and you need to keep it open".

    Please point out a version of any software license written in human history that contains your quoted phrase. Since a Google search on that quoted phrase turns up only one page -- this one -- you may have some difficulty. IOW, citation, please.

    Also, your approach towards the copyleft philosophy would seem to run counter to published statements by those who created that philosophy in the first place. For example, nobody is being prevented from selling GPL-licensed software, as the Free Software Foundation itself points out.

    > if there's a license to open the use, this means there's a license on APIs

    You are welcome to interpret it that way. Others will disagree with you, myself among them.

  • Nov 11th, 2015 @ 2:34pm

    Horse Racing

    In the DA's defense, I'll argue that fantasy sports is fairly closely analogous to horse racing, with respect to whether or not it is gambling.

    In both cases, there can be a measure of skill involved, such as researching past performance, particularly with respect to key factors like surface conditions (wet track/wet playing field). However, with that skill comes a large dose of luck to determine exactly who winds up winning and losing, both in the real-world performance (for the horses and the athletes) and in the betting performance.

    I don't think it is unreasonable to say that these sorts of fantasy sports should fall under the same regulatory umbrella as betting on horse racing. Whether that means that it is banned (only some states allow betting on horse racing AFAIK), regulated (for those states that allow it), or free-for-all (dumping all such regulation, anyone can bet on anything) is a separate debate.

  • Sep 16th, 2015 @ 8:38am

    Re: Re:

    > Having a picture of him with the much darker-skinned cop who was involved in all this totally undermines that whole narrative

    No, it doesn't.

    First, there are more than two races in this world.

    Second, bigotry is not limited to racism.

  • Aug 18th, 2015 @ 3:38pm

    Re: YOU "non-programmer" don't grasp what an API is! It's INTRINSIC AND INSEPARABLE FROM OTHER CODE.

    > It's INTRINSIC AND INSEPARABLE FROM OTHER CODE

    That depends.

    For example, presumably you are reading this in a Web browser. Your Web browser has an address bar, and in that address bar, you will see something like https://www.techdirt.com/articles/.... That is a URL. It is interpreted by the Web browser and used to retrieve the HTML for this Web page (which in turn contains other URLs for things like images).

    The interface used for the communication between the Web browser and the Web server is the Hypertext Transfer Protocol (HTTP) and related protocols. These are defined via specifications and are independent from any particular implementation. A copyright on the specification would not extend to an implementation, any more than the copyright on the specification for a bolt would extend to an actual bolt.

    Similarly, many programming languages (e.g., C, C++) have clear separation between interface and implementation.

    Now, what harms Google here is that Java is not one of those languages. Interface is much more tightly intertwingled with implementation in Java.

    > It's not just arbitrary inputs that anyone could come up with in a couple seconds.

    That depends entirely on how fast you type. I certainly have defined APIs "in a couple seconds".

  • Aug 3rd, 2015 @ 1:24pm

    A Sense of Strategy

    Few of these sites seem particularly concerned about the fact that shuttering comments makes it very clear they don't really value truly local community, and lack the willpower to nurture and protect on-site (or in app) participation.


    Yes, but you seem to be taking this from the attitude that every Web site should have comments.

    Having a participatory community needs to be a strategic decision. It requires investment, and therefore it needs to make sense to make that investment.

    The problem is that too many sites added comments because "it's what all the cool kids are doing", without any strategic sense for why they have the comments. It was a checkbox on the VC funding form, for example.

    So, for many of these sites, I would argue that their decision is simply a reversion to what they should have done from the outset, given their organizational priorities. And, in many cases, it will be better that they do drop the comments, as if they are not going to make the necessary investments in engagement, those comments can easily turn into a cesspool, which reflects poorly on the organization. IOW, do it right or don't do it at all.

    The highfalutin' PR fodder for why they are taking down the comments is tripe, but PR fodder is generally tripe. It may be worthy of ridicule, but it is hardly newsworthy.

  • Feb 23rd, 2015 @ 1:17pm

    Re:

    "A right is a legally enforceable claim against another that he should do some act or refrain from doing some act"

    Feel free to provide a citation to a dictionary that has that definition. Feel free to link to it, if the dictionary is online.

  • Feb 23rd, 2015 @ 10:18am

    App Platform Neutrality vs. App Market Neutrality

    Reading Mark Cuban's post, and contrasting it with John Chen's post, shows that they are not describing the same thing.

    Mr. Chen is focused on what I'll call "app platform neutrality", somehow requiring developers to write apps for platforms other than iOS and Android. This would be akin to requiring developers to write apps for OS X and Linux instead of just Windows, in terms of desktop operating systems.

    Mr. Cuban is focused on what I'll call "app market neutrality". His concern seems less about the platform and more about the gatekeeper role that Apple plays with iOS and, to a somewhat lesser extent, Google plays with Android. He wants there to be other possible gatekeepers, in the form of having other app distribution channels be able to be peers of the App Store and Play Store. Right now, short of jailbreaking, AFAIK it is impossible to have a peer of the App Store. While peers of the Play Store exist (e.g., Amazon AppStore for Android), on Google Play-centered devices, those peers are second-class citizens. I'll be happy to go into details on the Android side, as deep as anyone wants to go.

    Of course, these pale in comparison to net neutrality, for the reasons posed in this TechDirt post and beyond. Of the two, app market neutrality comes closer to net neutrality IMHO, insofar as both are focused on the prospects of oligopolies to control content distribution.

  • Sep 28th, 2014 @ 5:02am

    Re: The funny part is...

    none of what Apple or Google is doing is any change to mobile data traffic


    Correct. That's mostly up to app developers. Use of SSL and other encrypted communication protocols appear to be on the rise post-Snowden. I and others are working to help app developers do a better job here.

    But if you guess the 4-digit numeric passcode that 90%+ of users use to "secure" their phone? Wide open, encryption irrelevant.


    The encryption isn't "irrelevant", but it is easily bypassed. This is not significantly different than anything else in encryption: your security is only as good as your key. More stuff could be done here, at the device level (e.g., separate keys for the full-disk encryption from what users use to unlock their powered-on phones) and at the app level (e.g., separate encrypted containers for highly-sensitive data).

    Though I'd be curious if anyone knows of a study that would back up the "90%+" claim. I suspect that a lot of users do use weak PINs, but a survey might be illuminating.

    So the phone still isn't really encrypted


    Yes, it is. Your statement is akin to claiming that a locked door is not really locked, given the existence of lock picks and battering rams. Just because a security mechanism is ineffective against talented, determined attackers does not mean that it does not exist.

    it has a lock you can retry infinite times


    That too is something that could be improved, at least at the lockscreen level, whereby delays are introduced with every failure. If, for example, you added one second per PIN failure (no delay on first try, 1 second delay on second try, 2 second delay on third try, etc.), there would be a 50% of getting a 4-digit PIN right in several months of continuous attempts, but it could take as long as a couple of years if the attacker is extremely unlucky. I haven't been trying to brute-force devices, so I don't know how much of this is in place now (though Android historically lacked it). Which is why we have $5 wrenches and more sophisticated attacks (e.g., brute-forcing the disk encryption directly rather than trying to manually guess it at the lockscreen).

    I do agree with your overall assessment that this is a lot of sturm und drang over an incremental improvement in security.

  • Jan 21st, 2014 @ 12:55pm

    Re: Re:

    FWIW, and while I hate to cite Business Insider, AMC has confirmed the MPAA's and DHS's involvement in a statement to them:

    http://www.businessinsider.com/man-interrogated-by-fbi-for-wearing-prescription-google-glass-at -the-movies-2014-1?op=1

  • Sep 7th, 2013 @ 9:47am

    Re: These flailing and misguided email systems

    It seems like a week doesn't go by that someone doesn't launch yet another feeble over-hyped attempt to "fix email".

    And your proof of this is... what, exactly?

    Invariably these projects fail to take into account decades of real-world experience

    And your proof of this is... what, exactly?

    invariably, they prove to be insecure even before they're launched

    And your proof of this is... what, exactly?

    a choice which nicely maximizes the attack surface available to adversaries

    And your proof of this is... what, exactly? In particular, please feel free to explain how a well-designed single-page application, backed by a well-designed Web service protocol, is intrinsically less secure than a desktop email program and existing standard email protocols.

    Nearly all of them fail to ban HTML markup, an error which isn't merely enormous, but catastrophic.

    And your proof of the catastrophic nature is... what, exactly? Now, if they don't sanitize the HTML (e.g., strip out JavaScript, , etc.), I will agree with your assessment. But that's a reasonably well-understood problem, employed in all sorts of Web apps, beyond Web-based email clients.

    A substantial number fail to comply with BCP 38.

    This would be relevant only for those projects that are offering hosted services, rather than software. Ingress filtering is incumbent upon the host, not the email software itself.

    I think your second paragraph is reasonable (if a bit hyperbolic), and I think your general attitude (email is hard) is spot-on, but your first paragraph suffers from a surplus of hand-waving.

  • Aug 13th, 2013 @ 2:24pm

    Re: Re:

    Ridiculous. Clearly the one-star reviews were written by ill-tempered mutated sea bass.

    With frickin' laser beams attached to their heads.

    Pretending to be telco astroturfers.

    .
    .
    .

    Oh, sorry. My bad. I just assumed that Dr. Evil had one of those razor things everyone's talking about. Y'know, given his head, and all.

  • Jul 23rd, 2013 @ 4:58pm

    Digital vs. Physical

    One of the key arguments made with the NSA "hoovering" the metadata is that they are "third-party records" and there is no right to privacy.

    However, if law enforcement tried to claim that a rented apartment was a "third-party domicile" -- arguing that since you don't own it, you have no right to privacy, and they can toss any apartment at will -- that would get thrown out without a warrant.

    Similarly, if law enforcement tried to claim that a rented post office box was a "third-party communications service", and that they could rifle through those whenever they want, that too would get tossed without a warrant.

    Ditto for rented storage units.

    We need case law that establishes that "rented" email accounts, "rented" file manager accounts, "rented" social network accounts, "rented" phone numbers, and the like are no different than rented apartments, PO boxes, and storage units. While we are "renting" from third parties, the privacy expectation is not lost just because third parties are involved.

  • Jul 15th, 2013 @ 3:25pm

    Re: Oh, let's name "tech companies", starting with Google.

    As I wrote previously:

    The code in question is SE for Android, an Android-specific derivation of SELinux. SELinux has been part of mainstream Linux distros for a decade. While the NSA did contribute code to SELinux, SELinux is a standalone open source project with many contributors, and, more importantly, reviewers. Ditto for SE for Android.

  • Jul 12th, 2013 @ 8:53am

    Re:

    The code in question is SE for Android, an Android-specific derivation of SELinux. SELinux has been part of mainstream Linux distros for a decade. While the NSA did contribute code to SELinux, SELinux is a standalone open source project with many contributors, and, more importantly, reviewers. Ditto for SE for Android.

    So, which is more likely? That SELinux (with independent review) has a "sooper-sekrit" NSA back door, or that closed-source unreviewable OSes have them?

  • Jun 21st, 2013 @ 6:54am

    Re: Re: "Integrity" not necessarily compromised

    "which would mean the author would be forced into providing quite a few modifications that would not corrupt the original sense of the title"

    As noted in another reply, 128 to 256 distinct word flips would be more than sufficient.

    "What you are proposing here is some sort of human input from the author to avoid the errors that could arise from such system"

    Bingo.

    "As far as I can understand there is no such thing other than some modifications made by the system being shown to the authors so they can evaluate if it works well."

    Or the authors coming up with the 128 to 256 occurrences themselves. That's not especially hard, and I say that as self-published author.

  • Jun 21st, 2013 @ 6:51am

    Re: Re: "Integrity" not necessarily compromised

    "But to come up with thousands or hundreds of thousands of variations that can uniquely identify a leak"

    128 to 256 synonym pairs would be more than sufficient. Each represents an individual bit and can be flipped in combination.

    "That's a shitload of wasted time, money and effort"

    Speaking as an author, coming up with 128 to 256 synonym pairs would take me a couple of hours, tops. Remember that the algorithm involves not only the word flip, but the *specific* word flip. So, you come up with a pair of synonyms ("foo" and "bar"). Do a global search on the book to confirm which occurrences of "foo" can safely be switched to "bar" or vice-versa.

    "Surely that's better spent working out how to make customers more willing to buy?"

    Oh, I'm not saying that authors/publishers should be ignoring this. But you make it sound like this algorithm is rocket science, and it's not.

    "the risk of false positives"

    With 128 to 256 bits for the identity, a false positive (of the form where somebody tinkered with a copy to change the synonyms) is vanishingly unlikely. Tinkering with the book and toggling a synonym will make the book untraceable, but the odds of such a toggle happening to identify some other buyer is really tiny.

    "the ease with which it can often be removed or obfuscated"

    Somebody with two copies of the book could readily create a third copy that is untraceable. Few book readers would bother. Any DRM solution is toast in the face of a determined attack, and I'm not arguing otherwise.

More comments from Mark Murphy >>