Archive for the ‘linux’ Category

DEFCON 24 updates: August 8, 2016.

Monday, August 8th, 2016

More on Blue Hydra.

Sunday, August 7th, 2016

Earlier, I wrote “It runs! It works! Mostly. Kind of.”

I’ve been banging on Blue Hydra in my spare time since Thursday, and I stand by that statement. Here’s what I’ve run into so far.

The README is pretty clear, and I didn’t have any problems installing the required packages. (I don’t have an Ubertooth, so I skipped that one. We’ll come back to the Ubertooth later.)

First problem, which was actually very tiny: I know next to nothing about Ruby, other than that cartoon foxes are somehow involved, so the phrase “With ruby installed add the bundler gem” was more like “I don’t speak your crazy moon language”. Google cleared that up pretty quickly: the magic words are gem install bundler.

Next problem: running bundle install resulted in an error stating that it couldn’t find the Ruby header files. It turns out that, while my Ubuntu installation had Ruby 2.1 installed, it didn’t have the ruby-dev package installed. sudo apt-get install ruby-dev fixed that issue.

Next problem: the SQLIte Ruby gem failed to install when I ran bundle install. It turns out that I also needed the sqlite3-dev package as well. And with that installed, the bundle built, and I could do ./bin/blue_hydra.

Which gave an error stating that it didn’t have permissions to open a handle for write. Okay, let’s try sudo ./bin/blue_hydra (because I always run code from strangers as root on my machine; everyone knows strangers have the best candy). And that actually worked: Blue Hydra launched and ran just fine. In fairness, this may be a configuration issue on my machine, and not an issue with the software itself.

In playing with it, I’ve found that it does what it claims to do. Sort of. It’s been able to detect devices in my small lab environment with Bluetooth discovery turned off, which is impressive. I also like the fact that it stores data into an SQLite database; other Bluetooth scanning tools I’ve played with didn’t do that.

However, it seems to take a while to detect my iPhone; in some instances, it doesn’t detect it at all until I go into Settings->Bluetooth. Once I’m in the Bluetooth settings, even if I don’t make a change, Blue Hydra seems to pick up the iPhone. Blue Hydra also has totally failed to detect another smart phone in my small lab environment (and I have verified that Bluetooth was both on and set to discoverable.)

Now, to be fair, there may be some other things going on:

  • I’ve also observed previously that Bluetooth under Ubuntu 15.10 didn’t work very well. At all. So at one point on Saturday, just for giggles, I upgraded Project e to Ubuntu 16.01.1 LTS. And shockingly (at least for me) Bluetooth works much much better. As in, I can actually pair my phone with Ubuntu and do other Bluetooth related stuff that didn’t work with 15.10. That seems to have mitigated the discovery issues I was seeing with Blue Hydra a little, but not as much as I would have liked. (Edited to add 8/8: Forgot to mention: after I upgraded, I did have to rerun bundle install to get Blue Hydra working again. But the second time, it ran without incident or error, and Blue Hydra worked immediately aftewards (though it still required root).)
  • I was using the Asus built-in Bluetooth adapter in my testing. Also just for giggles, I switched Blue Hydra to use an external USB adapter as well. That didn’t seem to make a difference.
  • In fairness, Blue Hydra may be designed to work best with an Ubertooth One. The temptation is great to pick one of those up. It is also tempting to pick up a BCM20702A0 based external adapter (like this one) partly to see if that works better, partly because I don’t have a Bluetooth LE compatible adapter (and this one is cheap) and partly because the Bluetooth lock stuff is based on that adapter. (Edited to add 8/8: I’m also tempted by this Sena UD100 adapter. It is a little more expensive, but also high power and has a SMA antenna connector. That could be useful.)
  • It may also be that I have an unreasonable expectation. Project e is seven years old at this point, and, while it still runs Ubuntu reasonably well, I do feel some slowness. Also, I think the battery life is slipping, and I’m not sure if replacements are available. I’ve been thinking off and on about replacing it with something gently used from Discount Electronics: something like a Core i5 or Core i7 machine with USB3 and a GPU that will work with hashcat. Maybe. We’ll see. Point is, some of my issues may just be “limits of old hardware” rather than bugs.
  • And who knows? There may very well be some bugs that get fixed after DEFCON.

tl, dr: Blue Hydra is nice, but I’m not yet convinced it is the second coming of Christ that I’ve been waiting for.

DEFCON 24 notes: Hail Hydra!

Thursday, August 4th, 2016

GitHub repository for Blue Hydra.

I’m jumping the gun a little, as the presentation is still a few hours away, but I wanted to bookmark this for personal reference as well as the enjoyment and edification of my readers.

Edited to add: quick update. Holy jumping mother o’ God in a side-car with chocolate jimmies and a lobster bib! It runs! It works! Mostly. Kind of.

If I get a chance, I’ll try to write up the steps I had to follow tomorrow. Yes, this blog is my personal Wiki: also, while the instructions in the README are actually pretty good, I ran into a few dependency issues that were not mentioned, but are documented on Stack Overflow.

New toy! New project!

Saturday, April 9th, 2016

I was out and about earlier today with my mom and my nephew: we stopped by Hobby Lobby because I was looking for something. I’ll be posting about that something later on, but while we were there, I found one of these and ended up getting a screaming deal on it with the 40% off coupon.

Which is great, but that looks like a manual control box, right? How do you control it with a PC? Lots of soldering and a custom circuit board?

Ah. Nope. They have a USB device interface for the OWI-535. Isn’t that nifty?

But wait! The included software only runs on a PC! How do you control it with a Mac, or a LINUX system?

Surprise! People have reverse-engineered the control protocol! For example, this guy! (I love that blog title, by the way.) It looks like most of the other control examples I’ve found all loop back to Vadim Zaliva’s work documenting the protocol for the OWI-535. (He’s also documented the control protocol for the OWI-007 here.)

And look! Here’s control code in Python. running on a Raspberry Pi! Isn’t that a clever cleaver!

We’ll see if I can get the arm together and working without breaking it. Bad news: I don’t have that much mechanical aptitude. Good news: they claim all you need is needle-nosed pliers, diagonal cutters, and a Phillips screwdriver. No soldering required, which is good. I could probably solder my way out of a paper bag if someone held a gun to my head, but I’ve never been what you could call “good”, or even “competent” at it…

(As a side note, I’ve been trying to get back to “Talkin’ GPS Blues“. Unfortunately, I also decided to upgrade Project e to Ubuntu 15.10…and Bluetooth apparently doesn’t work well on 15.10, at least as of when I completed the upgrade. So once I get Bluetooth working again, and have some more time, I intend to revisit GPS, this time with some skanky Perl, Python, and possibly even Java code. We’ll see.)

DEFCON 23 notes: August 7, 2015.

Friday, August 7th, 2015

I kind of skipped over yesterday, because Thursday is traditionally slow. And it is a little early for stuff to be up today, plus many of the good presentations are scheduled for tomorrow.

But! BlackHat 2015! Not everything from BlackHat gets duplicated at DEFCON, and vice versa, but there’s always some overlap. Some things that are already up:

There are a couple of other overlaps I’ve found (specifically the Josh Drake presentation on Stagefright and the Valasek/Miller car exploit) but those don’t have any slides or other material attached yet.

More links and stuff as and when I find it and am able to post.

Edited to add: Just noticed this on the DEFCON 23 site. Download the conference CD optical disc here. Woo hoo woo hoo hoo. (The .rar file is 419 MB. Good thing I work for a networking company.)

On the road again…

Monday, June 2nd, 2014

Heading home. Travel day. In the meantime:

1. Go read this post by Tam. There are echos in it of something some less smart person wrote a couple of years ago.

2. I didn’t realize until the middle of last week that this year is the 50th anniversary of the .41 Magnum. (Ask me about my Model 57.)

3. I took a fair number of photos yesterday while running around with my aunt and uncle (who graciously drove the two hours each way from Cleveland to spend part of the day with me; thanks again, guys!). I’m waiting until I get back to do the post-processing and uploading, but I thought I’d throw one up here that I played with last night.


I took this with the D40X and the 18-55 kit zoom. It was cropped and the exposure adjusted slightly using Shotwell on Project e. I’m actually pretty happy with the end product, though I may make a second pass over it once I’m in front of iPhoto.

Ubuntu blues.

Saturday, August 17th, 2013

Documenting this here for the record.

I think I have finally resolved the “the system is running in low graphics mode” error I’ve been getting on Project e (which, I will remind you, is an Asus 1005HA with an integrated Intel 950 graphics adapter) since upgrading to Ubuntu 13.04.

This particular document is comprehensive and ultimately useless. I tried every suggestion in it, with no success at all.

What finally seems to have resolved the problem was a suggestion in this thread. Specifically, brucey99’s suggestion to edit /etc/init/lightdm.conf and add

sleep 10


exec lightdm

seems to have done the trick. (I used “sleep 20” instead of “sleep 10”. What’s the harm, 10 seconds more boot time? I can always change it later.)

It also seems like the

sudo service lightdm restart

command from a terminal window works to get things back to normal if the machine does start in low graphics mode.

And I’m not sure it made any difference, but just to document: I also created a xorg.conf file (from xorg.conf.failsafe) and edited the “Device” section:

Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "UXA"

After restarting about a half-dozen times, it hasn’t come up in low graphics mode yet. I’ll see how it goes.

As David Brin once said, “Let the next guy know what killed you.” And thanks, brucey99.

Bookity bookity bookity.

Tuesday, August 6th, 2013

Two more things that I wanted to bookmark:

Peteris Krumins’ “A Unix Utility You Should Know About: Netcat“. Actually, I want to bookmark his entire site, as there’s a lot of good stuff there, including “Low Level Bit Hacks You Absolutely Must Know“.

Also: Michael Ossmann’s HackRF Kickstarter, which is fully funded and has 29 days to go. This is a project I’m really excited about and will probably end up backing. Short version: HackRF is a project to build a software defined radio that is about the size of a USB hard drive, runs off of USB bus power…and if you back the project (and if it ships, this being Kickstarter and all), the cost is around $300, which puts it into “Shut up and take my money” territory.


Monday, July 8th, 2013

I’m waiting until I get back to edit and post photos. (As a side note, geotagging photos is a PITA on Ubuntu, compared to Apple’s iPhoto.)

We (that is, my mother, aunt, uncle, and I) were trying to get a good view of the tall ships at the Port of Cleveland. Which we couldn’t do yesterday, because the good views required $10 a car for parking plus $14 a person. However, my mother and I went back downtown today and took some photos.

I’ve been thinking a lot about firefighters recently. There was the West incident, and then the Houston Fire Department lost four people fighting a fire in a crack motel. Then there was Arizona. And it isn’t clear to me if any firefighters were lost in Quebec.

We stumbled across this yesterday while we were out, and I wanted to go back and photograph it. I’m happy with the way this photo came out.


Cleveland Fallen Firefighters Memorial, Cleveland, Ohio.

Interesting thing about this memorial: it was designed by Luis Jiménez, who also started building the sculpture. Mr. Jiménez was a popular and well-regarded sculptor. While he was working on the Firefighters Memorial, he was also working on the “Blue Mustang” sculpture for the Denver International Airport. In the process of building that sculpture, part of it fell and fatally injured Mr. Jiménez, and the memorial was completed by other people.

Stuff and things.

Sunday, June 2nd, 2013

Last week was not a good week. This coming week is shaping up to be pretty hectic (though I am hoping not as personally unpleasant), so there may be a blogging slowdown.

I spent all day yesterday at the 2013 edition of the Texas LINUX Fest. I haven’t been since 2010, but that had less to do with my frustrations with the 2010 organization and more to do with personal issues. (In 2011, that just turned out to be a bad weekend, with having to get my car inspected and deal with other things. Last year, it was in San Antonio; while that may be a welcome change of pace, the schedule wasn’t compelling enough to make me drive 150 miles round trip.)

I thought about doing detailed summaries of each session I attended, but frankly I’m a little worn out and a little lazy. I’d rather mention a handful of panels I did like. (There were some others that I went to, but don’t feel I can fairly evaluate because they weren’t what I was expecting, or I was distracted by other issues (see below), or, in one case, I just think it’d be a jerk move to badmouth the presenter.)

I really enjoyed Theo Schlossnagle’s “Scaling: Lessons Learned and Their Applications to Apache Culture” keynote speech, which covered a lot of good points about complex systems. He sees commonalities between building scalable systems and building communities to support them. Many of the points he made may not be hot news flashes but are worth repeating. Among those:

  • People get so caught up in how awesome it it to build stuff that they forget what the real world looks like.
  • Code is just a tool. It isn’t a child or a family member. You don’t have loyalty to it.
  • Engineers have a tendency to focus on the technology they love instead of the actual problems they face.
  • At the core of things, your job is to tell the computer what to do.
  • Unbalanced hyperspecialization leads to poorly constructed solutions.
  • The biggest challenge is that increasing scale and increasing performance demands lead to increased complexity.
  • Technological complexity is an emergent property of complex and changing business problems. This complexity has to be understood and managed, which is difficult for specialists.
  • If you don’t provide value, your [stuff] doesn’t matter.
  • In order to survive, we need generalists. Schlossnagle didn’t quote Heinlein, but he might as well have.

David Stokes from Oracle did what I thought was an excellent talk on “The Proper Care and Feeding of a MySQL Database”. I’ve mentioned before that I’ve been dabbling in MySQL, so I got a lot out of this. Some of it may have been obvious (more RAM, more disks, good things. Use decent hardware, not something you scavenged from the admin assistant because it was too slow to run the latest Office), but the two things we learn from history are that too many people don’t learn from history, and that the obvious often isn’t.

Philip Ballew’s “Ubuntu; Where We Were, and Where We Are” presentation was…amusing, shall we say, mostly for the level of skepticism directed at Ballew from the audience, many of whom seem to be skeptical about recent Ubuntu decisions like the replacement of X. I’m becoming increasingly skeptical of Ubuntu myself; I just upgraded to 13.04, and now I’m running into the “The system is running in low-graphics mode” error, which I haven’t had time to fully debug. The worst part is that I’m getting this only intermittently; I think it may be a timing issue, possibly with some Virtual Box kernel extensions.

Owen Delong’s “IPv6 – It’s Easy on LINUX” presentation was also very good. I haven’t even started to configure my systems for IPv6 (and I’m not sure everything supports it: I’m sure about the Mac and Project e, but less sure about some older gear), so I found Delong’s talk useful. I was surprised, though, that there was even more hostility and skepticism from the crowd than there was at the Ubuntu panel. Why is IPv6 an issue in 2013? And many of the questions from the crowd seemed to boil down to “How do I emulate this particular thing I do in IPv4 using IPv6, even though the reason this is needed in IPv4 is because we have a limited number of IPv4 addresses available, where in IPv6 we could give every single atom in the universe a unique address and not run out?”

Okay, that was a long question, but you get the point.

Brad Richardson’s “GPU based password recovery on LINUX” lightning talk is worth checking out. He was able to do the talk in about five minutes, instead of the allotted ten, and the subject is interesting; using reasonably priced GPUs, you can rapidly break MD5 hashes, orders of magnitude faster than throwing a general purpose CPU at the problem. (Richardson’s slides give specific performance figures: try 16 hours 46 minutes to brute-force a “8 character password with lowercase, uppercase, and numbers”, versus an estimated 36 days for a CPU based attack.)

Anyway. Tomorrow is the start (for me) of Yet Another Perl Conference 2013. (I registered for the conference itself, but couldn’t afford any of the training going on over the weekend or after the conference. Plus the training conflicted with the LINUX Fest.) I expect to be pretty tied up Monday through Wednesday, though I will try to blog from YAPC as downtime and network connectivity permits. I may even try to blog YAPC 2013 itself, but I can’t promise that.

Edited to add: Why did I not have a “Perl” category on this blog, but did have a “Python” category, given that I use Perl more often than Python? Fixed.

Edited to add 2: Thinking some more about it, it made sense to have a “Programming Languages” category and make Perl, Python, and others sub-categories below that. I’m still thinking about whether it makes sense to put the languages category under “CompSci”, but that way lies TJIC madness.

Edited to add 3: I realized there were two other points I wanted to make.

  1. I was much more favorably impressed with the organization of TXLF this year than I was in 2010. Of course, they’ve had four of these, so you would expect them to have the bugs fixed. Still, I was impressed at how smoothly almost everything from registration onwards ran. The only problem I saw was an unexplained 20 minute delay in the start of the lightning talks, but I didn’t feel that was a major issue.
  2. The quantity of tchotchkes available at TXLF? Very high. The quality of tchotchkes available? Still evaluating that, but I’m decently impressed. Favorites: the microfiber cleaning cloths from OrangeFS, and the SavvisDirect USB/12V adapters. Special mention goes to Hostgator, who were giving away a much wider variety of tchotchkes than any other single vendor.

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.