In September of 2011, Google introduced a product called Wallet. Android lovers were understandably thrilled by the idea of paying for things with their Android phones. A month later, Google introduced a product called the Galaxy Nexus, and it had Google Wallet, and Android lovers were, once again, thrilled. A few days after that, Verizon announced its own version of the Galaxy Nexus. There was yet more thrillilation.

Some of the thrill was short-lived, though, as it was discovered that Verizon's version of the Pure Google Experience™ would not include a pure Google Wallet experience. In fact, it lacked a Google Wallet experience of any kind. Thrills were dashed.

While for some time a quick APK sideload allowed it to function on the VZW Galaxy Nexus, the workaround was eventually patched up, and getting the service to work now requires significantly more tinkering.

Verizon no longer sells new Galaxy Nexuses, and did not partner with Google (at the time of this writing) on the successor handset, the Nexus 4. No Verizon device has ever officially supported Google Wallet.

This, understandably, has upset some people. Most of them are avid Google and / or Android fans, feeling they're being deprived of a valuable service Google provides, and that Verizon is basically the only party at fault (despite the fact that neither AT&T nor T-Mobile bundle Wallet with handsets, either).

The situation reached a boiling point, however, when it was discovered that there was an argument to be made that Verizon's "blocking" of Google Wallet might constitute a violation of what are known colloquially as "Block C rules," a set of openness directives Verizon agreed to when it leased a big hunk o' spectrum from the FCC back in 2008. By leasing that spectrum, which Verizon now uses as the backbone of its LTE network, Verizon agreed to the following stipulation:

Open applications: Consumers should be able to download and utilize any software applications, content, or services they desire;

This rule was actually a result of Google lobbying the FCC (you can't make this stuff up), and while I won't get too into that particular part of the story, suffice it to say this was not something Verizon was happy agreeing to. The company (and later, the CTIA) actually filed a lawsuit against the FCC over the requirements, though the suit was later dropped after Verizon was unable to use federal court fast-track rules to get the case heard quickly.

The rule in question, quoted above, requires Verizon to allow "consumers ... to download and utilize any software applications ... or services they desire." Google Wallet is a software application. It's a service, too. So, isn't Verizon required to allow you to use it?

This is the argument, in essence, being made by attorney Jay Klimek, who has filed a complaint with the FCC regarding Verizon's behavior, and its alleged violation of those Block C obligations. Recently, Klimek amended his complaint and has been seeking out attention for his pro-consumer crusade (he authored this guest post on Phandroid yesterday).

Klimek bases the rationale of his argument largely on a previous Block C enforcement victory against Verizon (the only one) regarding tethering (internet-sharing) applications on the Play Store. To summarize that case briefly: Verizon didn't like its customers using 3rd-party tethering apps because they made it difficult to enforce Verizon's paid tethering plans, and told Google to block access to those apps in the Android Market (at that time) for devices on the Verizon network. Google complied, and the apps were no longer installable on Verizon devices from the Market.

Verizon's case for doing so was undermined by two key facts. First, the Block C requirement prohibits Verizon from actively preventing users from downloading or utilizing a particular application. Second, Verizon itself already authored a tethering app for paying subscribers, and the argument that similar apps could somehow be harmful to the network or users was, indeed, a stretch for the ages.

On its surface, this sounds tantamount to the Wallet situation, and this is the argument Klimek is, in essence, making. Throw in a few paragraphs calling this all very "anti-consumer" and "anti-competitive," and you've got a very likeable cause to get behind. Unfortunately, Klimek ignores some of the very real distinctions between the two cases.

First, let's describe what happened in the tethering case. Verizon requested Google block the apps, and Google complied. This is exactly the behavior the provision is meant to discourage. Some of the apps blocked, most likely, required root access on the host phone to function. Even after unblocking those apps which required root access, they still could not be utilized by some consumers (eg, those with unrooted phones). Isn't that in violation of the rules, too, then?

I'm guessing you knew the answer to that question pretty quickly (no, obviously) - but you're not sure exactly why. You just know that every carrier actively attempts to stop you from rooting, with varying levels of success, and that's that. You may also know it's largely because of security concerns, as root exploits are actually flaws in a device's security. Preventing average users from having root-level access to a smartphone is also standard policy, and it makes sense. Even if the phone is easily unlocked and rooted, Verizon doesn't allow it to ship with those actions already taken. Verizon is especially strict on the issue of device security, and forces many of its OEM partners not only to lock device bootloaders, but encrypt them as well. It's part of Verizon's network security policy.

And guess what - those Block C rules have an exception (several exceptions, actually). Basically, these rules about open applications apply unless a particular app "would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee's network." That's basically why Verizon is allowed to lock your bootloader and prevent you from rooting your device. No other carrier in the US is subject to these restrictions, by the way, so there's no issue for them.

And This Doesn't Apply To Google Wallet

The thing is, these rules don't even apply in the case of Google Wallet, because Verizon isn't blocking anything. Why'd I bother explaining them, then? So you can see exactly how they don't apply.

Unlike the tethering app that requires root access, Verizon isn't actively preventing the Wallet app from being installed on phones. That's all Google. If Google wanted to make the Wallet app compatible for every Verizon phone in the Play Store such that you could download and install it, it could. There is absolutely nothing to stop that happening - but the app wouldn't actually work.

If you're not familiar with how Wallet functions, it's a bit odd as an application goes. The Wallet app isn't the only "piece" necessary to get the Wallet service functioning, there are two other parts of the equation. One you're already familiar with: NFC (near-field communication). It's a simple, open wireless standard that transmits data over very short distances. In Wallet's case, it transmits payment data. But there's a third wheel in play that many people aren't aware of, and it's called a "secure element." Without getting too technical (eg, into things I don't at all understand), the secure element's job is to store encrypted credentials (your payment info) and tell the Wallet app "hey, these are the credentials you need to transmit to the payment terminal."

Only one card's credentials are stored on the element at a given time (obvious security reasons), which is why you need an internet connection if you want to switch your active card in Wallet. When you sign in to Wallet or change cards, the Wallet app calls up to the Google server, pulls down your credentials for a particular card, and then writes them to the secure element.

But one does not simply write to the secure element (... or walk into Mordor), it requires special permissions. Google Wallet is doing something few apps do - asking for direct, exclusive access to a secure piece of hardware in the phone. Not only that, once Google takes over the secure element, it wants total control. Because of the security concerns (and related technical difficulties) involved in sharing a secure element, Wallet and only Wallet is able to utilize the internal secure element on a Wallet-enabled device. That means Google is directly managing every layer of the process.

And guess what: Verizon wasn't OK with this. It really has nothing at all to do with Block C rules or apps - this is a fight over who gets to control the internal secure element. This isn't about letting consumers run the software they want, it's about letting Google run the software and control the hardware it wants. I'm not saying that there's some kind of big security concern involved with Google Wallet. And I'm not saying Verizon, when it comes down to it, isn't being more than a little anti-competitive here. But they aren't "blocking" Google Wallet, and it's not like just flipping a switch would suddenly make it work. Your Galaxy S III wouldn't suddenly sprout Wallet support if this misguided FCC complaint were somehow right about the Block C rules being invoked.

So yes, Verizon probably has less than pure intentions in not cooperating with Google on Wallet compatibility. But it's also pretty squarely within the realm of "business decision" in doing so, and not "FCC violation." It's also fair to point out that Google hasn't exactly made things easy on itself in regards to getting Wallet out there, either. If Wallet didn't require access to the secure element, there'd be no issue in getting it onto Verizon phones. And hopefully something like that is coming.