Archive for the ‘Android’ Category

Changing the face of dining.

Friday, January 31st, 2014

We have a noodle truck at the office on Thursdays.

The Forbidden. Beef stewed for four hours in an Indonesian-style red curry. DFG Noodles, Austin, Texas.

The Forbidden. Beef stewed for four hours in an Indonesian-style red curry. DFG Noodles, Austin, Texas.

And it is pretty damn good.

And they take credit/debt cards. You’ve seen it before, haven’t you? iPad with a credit card swiper, pick your tip, sign, have your receipt emailed to you?

This observation isn’t original to me, and I’m not sure it is terribly profound, but: services like Square have revolutionized credit card processing. I remember the old days, when setting up a merchant account was hard to do, and you needed a phone line, and you needed bulky equipment, and the credit card processors charged enormous fees. Now? I’m kind of far from retail, so I’m not sure if Square has resulted in downward pressure on fees (though I suspect it has).

Someone I know who is in retail and takes credit cards reviewed an early draft of this post and provided this information: they pay 2.61% for credit card processing, but each month’s statement also contains a laundry list of “cryptic inexplicable fees” that they have to pay as well. Square claims to charge a flat 2.75% for swiped transactions (Visa, MC, AmEx, Discover) with no additional fees. (I say “claims” because I have not used Square and can’t verify that for myself.)

Square also claims to deliver your money in one to two business days, no matter what type of card it is. The retail person I know says that AmEx fees depend on how long you let AmEx keep your money: they let AmEx hold their money for 15 days, and pay between 2% and 3%.

But fees aside, anyone who has a bank account can take credit cards these days, and all you need is an iPhone or iPad (or a supported Android device, though frankly that looks a little painful). Little to no bulk, no landline, and the money goes into your linked bank account.

The big thing, as I see it, isn’t the merchant charges: it is the portability. Your credit card machine is your phone or tablet, and it fits in a trailer. Or in a pocket. And you don’t need anything else – you don’t even need a printer, you can just email receipts to your customers. (Okay, you might want a charging cable, depending on how good battery life is on your device. But other than that, nothing.)



Today’s update from the Department of Things That Make You Go “Hmmmmmmmmmmm”.

Thursday, January 16th, 2014

I found a couple of interesting little tidbits while going through the “Cisco 2014 Annual Security Report”. Before I begin, disclaimer and explainer: keep in mind that I am a contractor for Cisco. However, the 2014 Report is not a Cisco internal document, but is available to the public. You can download it here, though you do have to enter your name and an email address.

Things that I found interesting:

Ninety-nine percent of all mobile malware in 2013 targeted Android devices. Android users also have the highest encounter rate (71 percent) with all forms of web-delivered malware.

You. Don’t. Say.

Spam volume was on a downward trend worldwide in 2013. However, while the overall volume may have decreased, the proportion of maliciously intended spam remained constant.

So we’re winning? Maybe?

Of all the web-based threats that undermine security, vulnerabilities in the Java programming language continue to be the most frequently exploited target by online criminals, according to Cisco data.


Data from Sourcefire, now part of Cisco, also shows that Java exploits make up the vast majority (91 percent) of indicators of compromise (IoCs) that are monitored by Sourcefire’s FireAMP solution for advanced malware analysis and protection (Figure 12).

So should you disable Java? I think Borepatch would probably say “yes”. But this is also interesting:

90 percent of Cisco customers use a version of the Java 7 Runtime Environment, the most current version of the program. This is good from a security standpoint, since this version is likely to offer greater protection against vulnerabilities…
…However, Cisco TRAC/SIO research also shows that 76 percent of enterprises using Cisco solutions are also using the Java 6 Runtime Environment, in addition to Java 7.

JRE6 has been end-of-lifed and is no longer supported. I’m thinking the best practice here is:

A. Carefully evaluate your need for Java.
II. If you do need it, use the most current version.

At 43.8 percent, Andr/Qdplugin-A was the most frequently encountered mobile malware, according to Cisco TRAC/SIO research. Typical encounters were through repackaged copies of legitimate apps distributed through unofficial marketplaces.

“unofficial marketplaces”. You. Don’t. Say.

There’s a lot more in the report, including a brief discussion of Wireshark and Python tools for doing data analysis. I do commend it to your attention, even though my bias here is obvious.

Edited to add: left out one I intended to include.

In a recent project reviewing Domain Name Service (DNS) lookups originating from inside corporate networks, Cisco threat intelligence experts found that in every case, organizations showed evidence that their networks had been misused or compromised.
For example, 100 percent of the business networks analyzed by Cisco had traffic going to websites that host malware, while 92 percent show traffic to webpages without content, which typically host malicious activity. Ninety-six percent of the networks reviewed showed traffic to hijacked servers.

Bad Idea Jeans.

Thursday, October 31st, 2013

Scentee, a Japanese tech brand, has created a product that attaches to your smartphone and releases a scent. The plug-in accessory fits into the headphone socket of a smartphone (iPhone and Android). The device works with a companion app that tells it to spray a burst of fragrance into the air when you receive a message.

Available scents are claimed to include:

…rose, mint, curry, jasmine, cinnamon roll, lavender, apple, strawberry, ylang-ylang (a fragrant flower), coconut, and if you remember the fried corn soup fritters at KFC Japan from earlier this year, the corn soup scent should come as no surprise. There’s also a limited-edition Korean BBQ collection with two meat scents and baked potato. A bacon scent is in the works.

Yeah, I’ll believe it when I see it in action. But even if this does turn out to be real, and not a hoax, I still think it is a damn stupid idea. (Anyone remember the iSmell?)


Almost as cool as making the theme song to “The Wire” (the Season 5 version) your ringtone … almost.

Oh, bullshit. Everyone knows the Season 1 version (with the Blind Boys of Alabama) is the best version.

Edited to add: I have been challenged to provide support for the above statement.

Here’s a handy page that contains YouTube versions of the theme song from all five seasons.

TMQ Watch: August 13, 2013.

Friday, August 16th, 2013

We were trying to come up with a clever introduction to the return of Tuesday Morning Quarterback (and, thus, the TMQ Watch) but we couldn’t. On the other hand, we were also suffering from a bad case of 70s nostalgia (brought about by many things, but exacerbated by the death of Bert Lance). So we thought we’d throw some vintage music your way before cracking open this week’s TMQ after the jump. Oddly enough, it turns out to be fitting for reasons we’ll see later on…


And even more DEFCON 21 links: August 9, 2013.

Friday, August 9th, 2013

DEFCON 21 update: August 5, 2013.

Monday, August 5th, 2013

Yeah, I know, I’ve been quiet. Much of Friday’s blogging time was eaten by Bluehost instability, and Saturday and Sunday were busy.

But I do have some updates and links.

I’m going to cut things off here for right now. I’m still trying to find links to some of the other presentations I mentioned (in particular, I’d love a link of some sort to Anch’s “Pentesters Toolkit” if anyone has one) and will post updates as they come in. Depending on what I dig up, there may be a second post tomorrow. In the meantime, this should keep you busy.

DEFCON 21: -1 day notes.

Wednesday, July 31st, 2013

Just because I’m not going to DEFCON 21 doesn’t mean I can’t try to cover it. From 1,500 miles away. Sort of half-assedly.

DEFCON hasn’t even started yet, but Black Hat is going on, and some stuff is coming out. The biggest story so far has been Barnaby Jack’s death. I haven’t mentioned it previously because I’ve felt like it was well covered elsewhere (even FARK).

Another “big” (well, I think it is) story that I haven’t seen very much coverage of is the phone cracking bot. Justin Engler (@justinengler on Twitter) and Paul Vines, according to the synopsis of their talk and the linked article, built a robot for under $200 that can brute force PINs. Like the one on your phone.

Robotic Reconfigurable Button Basher (R2B2) is a ~$200 robot designed to manually brute force PINs or other passwords via manual entry. R2B2 can operate on touch screens or physical buttons. R2B2 can also handle more esoteric lockscreen types such as pattern tracing.

This is one I’ll be keeping an eye on.

Borepatch is in Vegas this year, attending both Black Hat and DEFCON. He’s got a couple of posts up: a liveblog of the NSA director’s presentation at Black Hat, and another post about the links between black hats and political candidates.

So the DEFCON schedule is up. If I was going, what would get me excited? (I’ve included the Twitter handles of the speakers from the DEFCON 21 schedule information; I figure this gives a central source for looking up someone’s feed and getting copies of their presentation.)

From Thursday’s talks: I’d probably go to “Hacker Law School“, as I’m a frustrated wanna-be lawyer anyway. Why not?

Anch’s (@boneheadsanon) “Pentesters Toolkit” talk makes my heart skip a beat:

You’ve been hired to perform a penetration test, you have one week to prepare. What goes in the bag? What is worth lugging through airport security and what do you leave home. I’ll go through my assessment bag and show you what I think is important and not, talk about tools and livecd’s, what comes in handy and what I’ve cut out of my normal pen-test rig.

Push some more of my buttons, please.

The Aaron Bayles (@AlxRogan) “Oil and Gas Infosec 101” talk kind of intrigues me, but it would depend on my mood at the time as to whether I went to that one, or skipped out for a break.

Likewise with the Beaker and Flipper talk on robot building: yeah, robot building is something I’m interested in doing, but I might just be in a mood to visit the Atomic Testing Museum instead, and read your slides later. Nothing personal: I’m sure it will be a great talk.

I’m intrigued by the ZeroChaos (@pentoo_linux) panel on the Pentoo LINUX distribution for penetration testing. I’m not sure how that differs from, say, BackTrack, but I’d probably show up just so I could find out.

The “Wireless Penetration Testing 101 & Wireless Contesting” talk by DaKahuna and Rick Mellendick (@rmellendick) hits yet another of my hot buttons. I can’t tell from the description how much of this is going to be describing contests in the Hacker Village, and how much will be practical advice, but I’d show up anyway.

That takes us into Friday. Just from a preliminary look at the schedule, it looks like the big thing this year is hacking femtocells. Doug DePerry (@dugdep) and Tom Ritter (@TomRitterVG) are doing a talk on “I Can Hear You Now: Traffic Interception and Remote Mobile Phone Cloning with a Compromised CDMA Femtocell”:

During this talk, we will demonstrate how we’ve used a femtocell for traffic interception of voice/SMS/data, active network attacks and explain how we were able to clone a mobile device without physical access.

The Charlie Miller (@0xcharlie) and Chris Valasek (@nudehaberdasher) talk, “Adventures in Automotive Networks and Control Units“, sounds interesting as well. I’m just slightly more interested in femtocells than automotive hacking, so apologies to Mr. Miller and Mr. Valasek: if the two weren’t in conflict, I’d hit your talk for sure.

And if you haven’t been to a software defined radio talk, Balint Seeber’s (@spenchdotnet) sounds promising.

The Secret Life of SIM Cards” by Karl Koscher (@supersat) and Eric Butler (@codebutler) intrigues me the most out of the 11:00 talks. And I’m kind of interested in the Ryan W. Smith (@ryanwsmith13) and Tim Strazzere “DragonLady: An Investigation of SMS Fraud Operations in Russia” presentation because, well…

This presentation will show key findings and methods of this investigation into top Android malware distributors operating in Russia and the surrounding region. The investigation includes the discovery of 10’s of thousands of bot-controlled twitter accounts spreading links to this type of SMS fraud malware, tracing distribution through thousands of domains and custom websites, and the identification of multiple “affiliate web traffic monetization” websites based in Russia which provide custom Android SMS fraud malware packaging for their “affiliates”. During this investigation we have mapped out an entire ecosystem of actors, each providing their own tool or trade to help this underground community thrive.

There’s not much that intrigues me after Benjamin Caudill’s (@RhinoSecurity) presentation on “Offensive Forensics: CSI for the Bad Guy“. If I was at DEFCON, this is the time where I’d probably be browsing the dealer’s room, though I might go to the Amir Etemadieh (@Zenofex)/Mike Baker (@gtvhacker)/CJ Heres (@cj_000)/Hans Nielsen (@n0nst1ck) Google TV panel: these are the same folks who did the Google TV talk at DEFCON 20.

I feel kind of conflicted at 4:00. The Daniel Selifonov talk, “A Password is Not Enough: Why Disk Encryption is Broken and How We Might Fix It” sounds interesting. But I’m also intrigued by the “Decapping Chips the Easy Hard Way” with Adam Laurie and Zac Franken. Decapping chips is something I’ve been fascinated by, and it looks like Adam and Zac have found methods that don’t involve things like fuming nitric acid (and thus, are suitable for an apartment).

This is also the time when we, once again, present the “Hippie, please!” award to Richard Thieme for “The Government and UFOs: A Historical Analysis“.

I’m slightly intrigued by Nicolas Oberli’s (@Baldanos) talk about the ccTalk protocol, “Please Insert Inject More Coins”:

The ccTalk protocol is widely used in the vending machine sector as well as casino gaming industry, but is actually not that much known, and very little information exists about it except the official documentation. This protocol is used to transfer money-related information between various devices and the machine mainboard like the value of the inserted bill or how many coins need to be given as change to the customer.

Saturday morning, we have the second femtocell talk, “Do-It-Yourself Cellular IDS”, by Sherri Davidoff (@sherridavidoff), Scott Fretheim, David Harrison, and Randi Price:

For less than $500, you can build your own cellular intrusion detection system to detect malicious activity through your own local femtocell. Our team will show how we leveraged root access on a femtocell, reverse engineered the activation process, and turned it into a proof-of-concept cellular network intrusion monitoring system.

Opposite that, and worth noting, are the annual Tobias/Bluzmanis lock talk, and the David Lawrence et al talk on using 3D printers to defeat the Schlage Primus.

More than likely, I’d hit the Daniel Crowley et al (@dan_crowley) talk, “Home Invasion 2.0 – Attacking Network-Controlled Consumer Devices“, and the Philip Polstra (@ppolstra) presentation “We are Legion: Pentesting with an Army of Low-power Low-cost Devices“. I’m particularly intrigued by the Polstra talk, as one of my areas of interest is how small can we make devices that can still do useful hacking? What’s the smallest feasible wardriving system, for example?

I do want to give Jaime Sanchez (@segofensiva) a shout-out for his talk on “Building an Android IDS on Network Level“. This is worth watching.

I’d have to go to the Phorkus (@PeakSec)/Evilrob “Doing Bad Things to ‘Good’ Security Appliances” talk:

The problem with security appliances is verifying that they are as good as the marketing has lead you to believe. You need to spend lots of money to buy a unit, or figure out how to obtain it another way; we chose eBay. We now have a hardened, encrypted, AES 256 tape storage unit and a mission, break it every way possible!

Because, tape! But the Wesley McGrew “Pwn The Pwn Plug: Analyzing and Counter-Attacking Attacker-Implanted Devices” talk also interests me.

The PIN cracking device talk is on Saturday, opposite Amber Baldet’s (@AmberBaldet) talk on “Suicide Risk Assessment and Intervention Tactics“. I’m glad DEFCON accepted her talk, and I am looking forward to seeing the presentation online.

Also noteworthy, I think: James Snodgrass and Josh Hoover (@wishbone1138) on “BYO-Disaster and Why Corporate Wireless Security Still Sucks“.

Todd Manning (@tmanning) and Zach Lanier (@quine) are doing a presentation on “GoPro or GTFO: A Tale of Reversing an Embedded System“. I don’t have a GoPro (yet) or much of a use for one (yet) but I think they are interesting devices, so I’ll be watching for slides from this talk. Same for the conflicting Melissa Elliott talk, “Noise Floor: Exploring the World of Unintentional Radio Emissions“.

This takes us to Sunday. There’s not a whole lot that really turns me on early, though I admit to some interest in the Jaime Filson/Rob Fuller talk on harvesting github to build word lists:

After downloading approximately 500,000 repositories, storing 6TB on multiple usb drives; this will be a story of one computer, bandwidth, basic python and how a small idea quickly got out of hand.

I like the idea behind John Ortiz’s “Fast Forensics Using Simple Statistics and Cool Tools“, and he teaches at the University of Texas – San Antonio, so I’d probably go to that.

Now is when things start heating up from my perspective. Joseph Paul Cohen is giving a talk on his new tool, “Blucat: Netcat For Bluetooth“:

TCP/IP has tools such as nmap and netcat to explore devices and create socket connections. Bluetooth has sockets but doesn’t have the same tools. Blucat fills this need for the Bluetooth realm.

Holy crap, this sounds awesome. All I ask for is code that compiles.

(Unfortunately, this is up against the Eric Robi (@ericrobi)/Michael Perklin talk on “Forensic Fails“, which sounds like fun. But Bluetooth hacking is a big area of interest for me; sorry, guys.)

Speaking of Bluetooth hacking, Ryan Holeman (@hackgnar) is doing a talk on “The Bluetooth Device Database”. Which is exactly what it sounds like:

During this presentation I will go over the current community driven, distributed, real time, client/server architecture of the project. I will show off some of analytics that can be leveraged from the projects data sets. Finally, I will be releasing various open source open source bluetooth scanning clients (Linux, iOS, OSX).

Dude lives in Austin, too! Holy crap^2!

And that takes us through to the closing ceremonies and the end of DEFCON 21. I will try to link to presentations as they go up, significant news stories, other people’s blogs, and anything else I think you guys might be interested in. If you have specific requests or tips, please either let me know in comments or by email to stainles at mac dot com, stainles at gmail dot com, or stainles at sportsfirings dot com.

I went back to Ohio, but my city was gone.

Monday, July 15th, 2013

Well, not really “gone”. I hadn’t been back to Ohio for nine years, and it amazed me somewhat both how much and how little has changed.

For example, there’s an entire grocery chain that I don’t remember from my last trip…that takes the Discover card and cash. No Visa/AmEx/MasterCard/Diner’s Club, not even debt cards with a PIN, just cash and Discover. Who came up with this idea?

On the other hand, the tractor tire store that was a landmark on the way to Grandma’s place is still there, after 40 something years. And Grandma’s place still feels remote from everything, even though there’s major strip centers at the end of her road, and even though much of the land was sold off over the past few years (and now has houses sitting on it).

And the old NASA hanger is still visible from the airport. That was another landmark for us kids. (My dad worked there, back when it was still the Lewis Research Center, before it was renamed “NASA John H. Glenn Research Center at Lewis Field“. Which is a mouthful. Not that I’m bitter or anything over the renaming; by gosh, if anyone deserved to have a NASA facility named after him, it was John Glenn.)

This is shaping up to be a long post, and sort of “stream of consciousness”, so I’m going to put the rest of it behind a jump. Before I do, here’s Grandma’s obituary, just for the record.


Here in my car, I can’t make a call, because the system doesn’t work at all…

Saturday, June 29th, 2013

The latest in-dash “infotainment” systems are turning into a giant headache for drivers. Problems with phone, entertainment and navigation functions were the biggest source of complaints in the latest J.D. Power & Associates survey of new-car quality, easily outstripping traditional issues such as fit and finish and wind noise.


But the next generation of in-car technology will get much more interesting, with embedded systems making a comeback of sorts, in more sophisticated form.
Such systems may focus on collecting data that only the car can provide — and transferring it to Web-based systems to large numbers of drivers. If cars signaled that their windshield wipers were on, for instance, that information could be fed into a navigation system that could warn other drivers of a rainstorm ahead.

Why do you need cars signaling that their windshield wipers are on to warn of a rainstorm ahead? I have a close friend who recently bought a 2013 Ford: it has weather information integrated into the navigation system. As I recall, his 2011 Ford had the same feature.

But my primary reason for blogging this is so I can link to episode 11 of the Neutral podcast, in which John Siracusa, Marco Arment, and Casey Liss discuss why car software stinks. I think all of the Neutral podcasts are worth listening to, but if you’re only going to listen to one, this is the one I’d recommend.

Another question for the huddled masses.

Friday, May 17th, 2013

Why do Android podcast clients suck?

I’ve written previously about my experience with the awful Pocket Casts application.

I dumped that and started using Google Listen. Google Listen frequently fails to completely download all of a podcast (so you end up with one in the queue that’s cut short, without any warning), frequently hangs up when trying to add a new podcast, and is no longer supported or maintained by Google. (Edited to add: Also, my phone frequently reboots while Google Listen is running, but I’m not sure if that is a Google Listen problem or a problem with some other application.)

I downloaded BeyondPod for my Kindle Fire. The free version (which I am using) has some limitations: you can’t set up automatic updates to your podcast feeds, nor can you download more than one podcast at a time. In order to activate those features, you have to pay $6.99 for an unlock code. Personally, I think that’s a bit steep for a podcast client, but if BeyondPod actually did what I wanted it to do, I’d pay that.

However, BeyondPod has a couple of what I consider to be crippling issues:

  • I find the user interface to be completely counter-intuitive. For example, if I have a podcast on my playlist, playing, and I want to switch to the player controls (to rewind, pause, or fast forward) I can’t figure out how to do that. Sometimes BeyondPod will display player controls underneath the playlist, other times it doesn’t. Sometimes you can swipe up and see the controls for the specific podcast; sometimes you can’t. There seems to me to be no rhyme or reason to what controls BeyondPod displays when and where, and how to get from one set of controls to another.
  • Then there’s my personal favorite BeyondPod “feature”. If you have a playlist, and you’re looking at the feeds for a podcast (say, you want to read the notes on a specific podcast), and you accidentally touch in the wrong place, BeyondPod starts playing the podcast you’re looking at. This makes sense. What doesn’t make sense is that BeyondPod also wipes out your existing playlist. Oh, you wanted to listen just to that podcast, or you missed the touch target and didn’t intend to play that podcast at all? Too bad, so sad, rebuild your playlist. That’s a deal breaker for me; no, I will not pay you $7 for a podcast client that erases my playlists.

All I want out of a podcast client is a few basic, simple things:

  • Maintain a feed of the podcasts I want to listen to.
  • Reliably download those podcasts. If a podcast fails to completely download, either warn me or retry until it does.
  • Let me mark podcasts as listened or not listened.
  • Let me fast forward/rewind within the currently playing podcast.
  • Let me have a playlist of podcasts that I can easily rearrange.

That’s pretty much it. There are some other features that would be nice (ability to sync across multiple platforms, for example) but not essential to me. So why is this so hard?

Android fans constantly bash Apple and iTunes. Yes, iTunes has problems, most of which involve trying to put too many functions into one piece of software. But for all the problems iTunes has, it is at least capable of doing all of the things on my minimum list. I can’t say that for any Android client I’ve tried so far.

Ring ring ring, open phone.

Monday, April 29th, 2013

Great and good friend of and valued commenter lelnet left a long comment on last night’s cellphone post. Because his comment represents a lot of work and thought (and I believe in rewarding hard work) and because I’m afraid it will get lost in the shuffle, I’m promoting it to a blog post (with his permission).

You can already buy, off the shelf at Fry’s, a “phone” that does essentially what you’re talking about, using available wi-fi networks to connect with Skype and make calls through that, without any involvement of the cell providers. (Yes, I know…Skype is a proprietary protocol and would be unacceptable to Stallman. The firmware is also closed. But since it’s provably _possible_, one could do it with open standards if one saw a market.)

The problem is that it doesn’t scale well. Getting a reliable wi-fi signal is pretty easy…in the sorts of places one is likely to have access to a _wired_ phone whenever one wants one. Building a wi-fi network that covers the places one actually needs mobile connectivity from is a massively harder problem, due to the range limitations of unlicensed spectrum.

It _might_ be possible to do it using amateur frequencies, _if_ you could get regulatory approval to open those up to use by the general public. Which, of course, would involve fighting off both the whole telco industry and at least 80% of the amateur radio community. Considering that the latter group is where you’d be trying to recruit most of your network engineers from, it seems like it’d be a bad idea to begin your plan by irrevocably pissing them off, even if you magically assume that you’ll be able to out-muscle the telcos in Washington.

The last mile is a hard problem on several different dimensions, some of them physical and some of them political. But there is something you _could_ do…

Build an Android (or, if you like, Replicant) phone, pre-configured to send all its traffic through an encrypted VPN to an anonymizing end-point. Purchase connectivity for it on an existing cell carrier’s prepaid plan. Disable the cellular voice service, and have it send and receive calls exclusively through VoIP connectivity to an Asterisk or FreeSwitch server, either run by the same entity that does your anonymizer, or run yourself on a cheap colo server stuck in a rack in some country you doubt is ever going to care enough to spy on you.

Your cell provider can easily determine that Charles Udall Farley (or whatever name you gave them when you signed up…it’s prepaid, so it’s not like the name you give has to pass a credit check) pushes a lot of data around, but they’d have no way of inspecting the content. They’d have a record of Mr. Farley’s movements around their network, but no way to associate that with you, or even with the phone number you make and receive calls on. An Open Source OS on the phone addresses the “remote bugging” fears. It doesn’t depend on you personally running any software that RMS would find objectionable. And since you can make and receive calls from anywhere that you’re able to get a data signal off a cell tower, it’s still useful if your car breaks down by the side of the road, instead of just in your home and office, like a wi-fi-only device would be.

(I came up with this plan for a team of spies in a novel my wife is writing. But although to my knowledge no such phone exists today, there’s absolutely no barrier to someone building one tomorrow. And both the technologies and the services required to support the back-end of it are already available for purchase in the real world right now, at prices comparable to or better than what people who already had cell phones in the mid-90s were paying for service then.)

The only thing I’d add to this is that I, personally, have no interest in pissing off the amateur radio operators out there; both because it is not good strategy, as lelnet notes, and because I happen to be one myself. (KF5BFL, in case anyone was wondering, but don’t look for me; I don’t have any transmitting equipment at the moment.)

We’ve got computers, we’re tapping phone lines, I know that ain’t allowed…

Sunday, April 28th, 2013

Two things collided in my head last week. After I picked up the wreckage, I thought there might be a worthy blog post in the aftermath.

(Picking up the wreckage took a while, because the week was so busy. At least nobody took part of a locomotive through the eye. Anyway, I apologize if this is old news.)

Thing one: Andrew Huang’s post on the $12 Gongkai phone (by way of LWN). It doesn’t come as any great shock to me that cellphone hardware has become cheap: at last year’s DEFCON, the Ninja Networks party invitations were fully functional cellphones. (I do not know what the Ninja Networks cost per phone was: as I recall, the Ninjas stated they got substantial financial and technical support from Qualcomm. However, the fact that the phones were cheap enough to pass out as party invites is significant in and of itself, in my ever so humble opinion.)

Thing two: Dr. Richard Stallman and his position on cell phones. I don’t want to reopen the whole debate on whether Stallman is a hypocrite for not having a cell phone but being willing to use other people’s phones. Rather, I want to ask a not-so-simple simple question: is it possible to build a phone that overcomes Stallman’s objections?

…most of them are computers with nonfree software installed. Even if they don’t allow the user to replace the software, someone else can replace it remotely. Since the software can be changed, we cannot regard it as equivalent to a circuit. A machine that allows installation of software is a computer, and computers should run free software.

Well, it looks like we can put together a cellphone computer for about $12. Maybe less. I don’t see any reason to think that someone   (more likely, a small group of someones) could put together a reference hardware spec for an open cellphone, complete with schematics, PCB layouts, and a parts list. I know I don’t have the skills or equipment to do SMD soldering, and I wouldn’t ask, say, my mother to build a phone from a kit either. But it is just as easy for me to visualize a scenario where some organization (say, the FSF) contracts with a manufacturer to build phones from the reference design, with an organizational seal of approval. They could sell the phones outright, or offer them as a premium for donations: I think I’d give at least $50 to FSF for a phone like the one Huang describes. Add WiFi, GPS, a color screen and a camera and I’d go up to $100, possibly more depending on my mood, the phase of the moon, and other factors.

But we need an operating system for our cellphone computer, right? Right. Android is open source. Note well, however, that there is a difference between “free software” and “open source software”, and that these are not equivalent concepts. But it seems pretty easy to imagine (as long as were are imagining) a fork of Android that is truly “free” by the FSF definition. As a matter of fact, we don’t even have to imagine; while I was researching this post, I stumbled across Replicant, which is exactly that.

…tracking and surveillance devices. They all enable the phone system to record where the user goes, and many (perhaps all) can be remotely converted into listening devices.

I’ll deal with the second objection first. With a truly open source and free OS, I think you can pretty much eliminate the capacity for remote bugging. As to the first objection, I don’t see a way around that. It seems pretty clear that the phone system has to know where your phone is for you to make calls and get calls. But: if the system only stores that information for the minimum necessary length of time, and discards it after the call is completed, is that good enough for Stallman?

(Even if you’re not actively engaged in a call, I think the network still has to know what cell you’re in. But could the network only store your current cell, and not the history of cells you’ve been through?)

(From this point forward, I’m going to refer to this idea as the “open” network. Calling it the “free” network carries with it the connotation that people aren’t paying for it. I’ll come back to that.)

Okay. So we expect AT&T and Sprint and Verizon and T-Mobile and the Grace L. Ferguson Cell Phone and Storm Door Company not to store this information. Right. I’ll wait for you to finish laughing.

Done? Okay. So we not only need consumer hardware, we need an entire “open” cell phone network. Is that something that could be reasonably built? Well, we need radio spectrum. It is unlikely that the carriers will give up spectrum for an “open” network. So what do we do? Could we use amateur radio frequencies, like the 2390-2450 MHz band? Is it even possible that local amateur radio groups could set up and maintain cells in their local areas? (I don’t imagine the equipment to set up a cell is cheap, but I also don’t imagine it is beyond the reach of a group of talented amateur radio operators with a GNU software radio. And if the equipment becomes widespread, the prices should go down. I hope.)

Could you even do away completely with the cell network, and just run all the communications over IP? You’d need to be associated with an access point, but aren’t most folks near one at home or at work most of the day? Would it be possible for amateur radio operators to set up networks of access points along major urban corridors? WiFi hardware is even more of a commodity item than cell hardware, and there are protocols for linking access points together or doing mesh networks.

Someone has to pay for this, right? Right. We don’t want movements and activity tracked, but I don’t see any philosophical problem with a simple lookup based on each phone’s unique identifier. All you need is one bit to indicate the customer is paid up and entitled to use the network. As for the actual cost and billing, it seems to me that can be handled by systems outside the network. If you’re giving unlimited everything for one flat fee, you don’t need to track anything except paid or unpaid. If you want to start getting into per voice minute or per KB data charges, it seems to me that you can still track usage (minutes, KB, or texts) without tracking activity and bill based on usage. The money from service fees could, in turn, be routed to the cell providers. I’m sure we could come up with a fair way of doing this; for example, X cents per call routed through an individual cell. Busier cells get more money, which they can invest in upgrading service; more remote cells probably have lower demand, and don’t need the same capacity.

(One big problem if you’re using amateur radio frequencies: FCC regulations prohibit “communications in which the operator has a pecuniary interest, including communications on behalf of an employer“. There’s a strong tradition, in addition to the FCC regulations, against using the amateur radio bands for business purposes. One could argue that this kind of network wouldn’t be a business, though; rather, it would be a maintained as a public service, and the money that comes in would go back out to local amateur organizations to cover their cost of maintaining cells. I sort of see this in the same way as I do the repeaters maintained by some amateur radio clubs for the use of their members.)

So I said this was a not-so-simple simple question. Basically, what I don’t know about cell phones and cell technology could fill books. (Indeed, it has filled books, which are located in places called “bookstores” and “libraries”. But I digress.) I think I’ve outlined a possible path to an “open” network, but I acknowledge the limits of what I know. I would welcome criticism from people who know more than I do: those who work in the industry, computer security experts, and heck, even cyberpunk writers.

I mention cyberpunk writers for a reason. Maybe I am over-romanticizing this a bit, but I have this mental image of guys in the Sprawl with “open” cellphones spread out on blankets in the street, and gangs like the Panther Moderns using those phones. A guy can dream, can’t he?

(Subject line hattip: the greatest rock song ever, by the greatest band ever. Like you needed it anyway.)

Edited to add: I knew there was something I was forgetting. How reliable would this network be? After all, AT&T spends hundreds of millions of dollars a year on their network, where what I’m talking about here is something that is, at best, a fringe network primarily used by people highly concerned with privacy, and possibly maintained by amateurs on a spare time basis. On the other hand, AT&T spends hundreds of millions of dollars a year on their network. Enough said.

My inclination is to say that you could probably build something that’s “good enough”. You might not be able to get to the same level of service as, say, Verizon, but you could probably get to a level of service where people are willing to make the tradeoff between guaranteed privacy and a small amount of inconvenience. I think this is one place where my plan is weak.

Edited to add 2: 1500 words? I haven’t written like this since I was in college. In other words, last year.