Is Verizon even allowed to discriminate against NFC apps like Google Wallet?
Verizon Wireless has been careful to point out that it is not technically blocking the Google Wallet app/service from the new Galaxy Nexus phone, and that it is still negotiating with Google.
Google, too, has not used the “blocked” word in its statements, as far as I’ve seen.
Google is telling people that Verizon asked it not to include the app. And so far, Google has complied with that request. So far, it hasn’t been blasting Verizon — its most important Android carrier partner — for playing foul.
But the reason this is particularly interesting and potentially controversial is that Verizon is not allowed to block applications on the airwaves that its 4G LTE network uses, per special “open access” rules set by the FCC (which Google, of all companies, had aggressively lobbied for). That’s probably one reason why Verizon has been defending itself and saying that it is not “blocking” any applications — it can’t.
However, the reality is that even if Verizon technically isn’t blocking the app from being installed, it is using its commercial leverage over Google to prevent Google from distributing it. I’d be willing to bet that Google would rather distribute its new flagship “Nexus” phone with Google Wallet preinstalled than without it. So, in effect, Verizon is using its influence over Google to prevent the app from being distributed. Call it “blocking without blocking”.
Verizon’s public argument for thwarting Google seems to be that Google Wallet isn’t just another app — it’s a special app, because it uses the newish NFC (“near field communication”) chip in the Galaxy Nexus phone. Here’s the relevant part from Verizon’s statement yesterday:
“Google Wallet is different from other widely-available m-commerce services. Google Wallet does not simply access the operating system and basic hardware of our phones like thousands of other applications. Instead, in order to work as architected by Google, Google Wallet needs to be integrated into a new, secure and proprietary hardware element in our phones.”
I’m all for security, especially when it comes to supporting mobile payments. But isn’t the NFC chip just another part of the phone? In the past, Verizon was notorious for “crippling” Bluetooth on some of its early smartphones, but it seems to have stopped doing that. I’m not sure why it would go back to that sort of behavior again.
One potential explanation is that, for whatever reason, Verizon just isn’t ready for its devices to support NFC payments yet — but the Galaxy Nexus had an NFC chip already built in, so Verizon is using its influence over Google to stall the Google Wallet rollout.
Another potential reason is that Verizon wants a piece of the action, especially if Google Wallet is going to be preinstalled. Or it wants to make sure that its own mobile payments service, Isis, gets equal or preferential promotion. Or something else involving money and business stuff. Thus, Verizon’s statement: “We are continuing our commercial discussions with Google on this issue.”
But unless I’m missing something crazy about how Google Wallet works, it seems disingenuous and overreaching to suggest that NFC-based payments apps are really any different than normal apps, “proprietary hardware element” or not. And therefore, they shouldn’t be exempt from the open access rules.
Meanwhile, I found the Word doc containing what appear to be the FCC’s actual “open access” rules, which govern Verizon’s LTE airwaves. (If you ever want to play a trick on someone, ask them to find a document from 2007 on the FCC’s website. Fun stuff.) I’ve included them below.
There does seem to be some leeway for Verizon (“licensee” in the legal-speak) to slow down Google Wallet: Perhaps it doesn’t comply with Verizon’s NFC technical standards, or perhaps Verizon’s NFC payment standards haven’t been released yet, or perhaps there’s some sort of government regulation that no one is talking about.
But there doesn’t seem to be anything in the rules protecting specific hardware components of Verizon’s phones, such as NFC.
So once again, I’ve concluded that Google is willingly capitulating to Verizon and that this is a business problem, not a technical problem. And if Google needed to, it could probably eventually use the FCC to pressure Verizon to open up to Google Wallet — assuming it’s meeting all of Verizon’s technical standards. But Google doesn’t seem to be at that point yet.
I’ve reached out to Verizon, the FCC, and Google for more information, and will update if I hear back. Meanwhile, here are those open access rules governing Verizon’s 4G spectrum.
27.16 Network access requirements for Block C in the 746-757 and 776-787 MHz bands.
(a) Applicability. This section shall apply only to the authorizations for Block C in the 746-757 and 776-787 MHz bands assigned and only if the results of the first auction in which licenses for such authorizations are offered satisfied the applicable reserve price.
(b) Use of devices and applications. Licensees offering service on spectrum subject to this section shall not deny, limit, or restrict the ability of their customers to use the devices and applications of their choice on the licensee’s C Block network, except:
(1) Insofar as such use would not be compliant with published technical standards reasonably necessary for the management or protection of the licensee’s network, or
(2) As required to comply with statute or applicable government regulation.
(c) Technical standards. For purposes of subsection (b)(1):
(1) Standards shall include technical requirements reasonably necessary for third parties to access a licensee’s network via devices or applications without causing objectionable interference to other spectrum users or jeopardizing network security. The potential for excessive bandwidth demand alone shall not constitute grounds for denying, limiting or restricting access to the network.
(2) To the extent a licensee relies on standards established by an independent standards-setting body which is open to participation by representatives of service providers, equipment manufacturers, application developers, consumer organizations, and other interested parties, the standards will carry a presumption of reasonableness.
(3) A licensee shall publish its technical standards, which shall be non-proprietary, no later than the time at which it makes such standards available to any preferred vendors, so that the standards are readily available to customers, equipment manufacturers, application developers, and other parties interested in using or developing products for use on a licensee’s networks.
(d) Access requests.
(1) Licensees shall establish and publish clear and reasonable procedures for parties to seek approval to use devices or applications on the licensees’ networks. A licensee must also provide to potential customers notice of the customers’ rights to request the attachment of a device or application to the licensee’s network, and notice of the licensee’s process for customers to make such requests, including the relevant network criteria.
(2) If a licensee determines that a request for access would violate its technical standards or regulatory requirements, the licensee shall expeditiously provide a written response to the requester specifying the basis for denying access and providing an opportunity for the requester to modify its request to satisfy the licensee’s concerns.
(e) Handset locking prohibited. No licensee may disable features on handsets it provides to customers, to the extent such features are compliant with the licensee’s standards pursuant to §27.16(b), nor configure handsets it provides to prohibit use of such handsets on other providers’ networks.
(f) Burden of proof. Once a complainant sets forth a prima facie case that the C Block licensee has refused to attach a device or application in violation of the requirements adopted in this section, the licensee shall have the burden of proof to demonstrate that it has adopted reasonable network standards and reasonably applied those standards in the complainant’s case. Where the licensee bases its network restrictions on industry-wide consensus standards, such restrictions would be presumed reasonable.