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.

I just bought a HTC One and was upset to learn that there is no Wallet support. I loved Wallet on my Galaxy S3, which I had to use a work around to install. Question though, why cant Google just make Wallet easier to install then? I dont know all the details involved, but who cares really? There is NO other competition in the US anyways. ISIS keeps getting spoken of but I couldnt even use it even if I wanted to.

stevethepirate

google should block ISIS as a big FU.

squiddy20

And be cited for the same crap Verizon is being called out on doing? Riiiiight...

didibus

Pretty sure the reason there is no other way to do this is security concerns. If your payment credentials would be stored in the phone, they could get stolen more easily So instead, they are storing them somewhere that is more secure. And I would say it's probably the banks, and credit card companies who set the minimum amount of security they require.

Wilfredo Alarcon

So. Verizon is being a jerk about not handing the necessary control to Google, but Google is still their best customer/provider?

I hate Verizon.

Jonathan Warden

Everything you said about whathisface using Block C being misguided is completely wrong. The guy is 100% right. Verizon is using what we call a 'loophole'. Let's be clear, shall we?

gsm carriers are required to accept any phone that complies with gsm standards. so google does not need permission from any gsm carrier to have access to the secure element on a phone that it controls the firmware for. verizon being a cdma carrier has final say on firmware compliance. google isn't allowed to officially release a firware update that would allow access to the secure element on the vzw nexus. i don't have the history of why cdma has these rules. so it's not really that att and tmobile allow it, it is that they have no control over the firmware on the nexus 4 since it complies with gsm standards. however if google made wallet downloadable then other gsm phones with nfc and a secure element would not magically work unless the oem who ships the firmware allows the wallet apk to have access to the secure element. now as soon as you put root into the equation all bets are off. which is why i don't mention root in this situation.

UniBroW

Yes, I understand all of that. I was merely pointing out that it's unlikely that Google is restricting wallet on Verizon phones as much as it is Verizon blocking Google wallet. Verizon blocking google wallet should be viewed as being noncompetitive and monopolistic. Google wallet doesn't even NEED Verizon's network in order to function. Verizon is placing a restriction on devices that consumers purchase from them.

It's pretty clear cut, Verizon is being Verizon.

And as far as blocking apps because they require root argument, do they block any other root requiring apps because of that limitation? Does Verizon actively block Titanium backup? How about Superuser? No? didn't think so...

this article didn't state that verizon wasn't being anticompetitive, it was saying that what verizon did was most likely legal. in fact this article says that. I thought your question was a technical question of the distinction not a verizon complaint.

You used the root argument about how tethering works. VZW blocked ALL tethering apps, root or not, they blocked them. By using the root case about tethering that even if they allowed them, the user has to go above and beyond to root to use them.......is the reason people keep jumping on it. But VZW blocked FoxFi (PDAnet) and that DOES NOT require root. Blocking Tethering apps from being installed against the C block, and thus they had to reverse course. It was basically nickel and diming to consumer to pay for something they could get elsewhere and that is exactly what ISIS is. Google wallet my work better or worse, but if your on VZW you will never know, because you don't get a choice. If VZW was in the clear about this, they would offer some way for wallet to use the SE on the SIM, but they don't so that is why they will lose. If it's TRULY a security concern, the simple solution is the SE on the SIM, and they hold that pretty tight don't they?

John Kiser

Sadly some of the new sims are actually starting to block NFC payments being possible outside of the ISIS stuff (in test regions atm) when switched on. It's on the Sim card and not on now for most areas but... When they do even the Nexus 4 may end up blocked it's terrible...

Nathan Stoltenberg

I'd like to make the point that I can still install Google Wallet on my VZW Galaxy Nexus, through a fun little trick. I use Titanium Backup to zip up a copy of Wallet from my Nexus 7. I then restore the app using this zip on my "Galazy" Nexus. Works like a charm.

Hi David: I'm going to have to completely disagree with your analysis. As per my complaint to the FCC and my numerous articles on the subject (the latest one can be found on Phandroid as of yesterday) Verizon ASKED Google to block Google Wallet from its users which is a violation of C Block regulations. The FCC has stated this in it's decree from July 31, 2012. Please do not spread the idea (as VZW likes to do) actually blocking an app is not the same as asking for an app to be blocked. The FCC has said it's the same, so it's the same, end of story. Please feel free to read my articles on Phandroid or visit my website jasonklimek dot webs dot com and learn the truth of what is actually happening with Google Wallet.

Charles Azmit

Thanks for taking the time to reply here, I read your article yesterday, and this article seems to miss the point entirely. No where in this article is ISIS mentioned, which seemed like the main point in your article, and amended complaint: if ISIS can access the secure element, verizon has no grounds to say that an app accessing the secure element could be dangerous, which means they have no grounds to prevent Wallet from accessing it. Right??

Is David Ruddock a lawyer, or does he just like to play one on the internet?

moore00

I think he's a law student, which shows here. I was once one and turned out I didn't know jack shit, but I thought I knew everything then. Even as a lawyer it feels like I don't know anything, but at least I realize that now.

I am not a lawyer, I attended law school. Challenging someone's credentials is always a great way to make your case. Right??

flosserelli

I'm not a lawyer, but I play one on tv.

didibus

I'm still a bit confused, are you or not a lawyer? Not that you don't have the right to write an article about this, but stating your expertise and competency on the subject matter does help the reader decide what to make of the article.

EDNYLaw

That is PRECISELY my point. It's kind of like telling someone the speed limit is 55 then getting pulled over by a cop and say "well I didn't know the speed limit is 55." It pretty much vitiates the argument. Which is exactly what VZW has done. They've said (and I have the quotes) "we're unsure about the secure element, we don't know how it interacts with the hardware..." then they turn around and explicitly state ISIS uses the secure element and this is how it works. Google has been up front about everything. In fact, in my complaint, I reference many times Google's commerce site where they explain EXACTLY how Google Wallet (and the secure element) works. They leave nothing to the imagination. Further, there is just NO WAY IN HELL the use of Google Wallet can negatively affect VZW's network or it's customers. In fact, the only thing that can negatively affect a customer's device is bricking the secure element because you're trying to get it to work when VZW has blocked Google Wallet, and what's the way to avoid that situation (for those inclined to use Google Wallet)? Allow VZW customers to legitimately use Google Wallet.

chris

BAM! Lawyered!

Alex Carlson

"then they turn around and explicitly state ISIS uses the secure element and this is how it works."

You've just lost all ground from which to argue since it's been pointed out to you multiple times that ISIS does not use the OEM signed SE, and instead uses a Verizon signed SE on the SIM card. Saying ISIS and Wallet both use the SE is not only disingenuous at this point, but blatantly lying.

EDNYLaw

Actually it's not blatantly lying. In fact the ISIS app only says "The Secured Element is a dedicated hardware component in your phone..." and mentions nothing of a SIM card secured element or whether or not it uses the HARDWARE secure element. However, since VZW ISIS App specifically states dedicated HARDWARE component, I'm inclined to believe, you're wrong or at the very least, VZW is not providing accurate information.

I'll thank you not to defame me by affirmatively stating I am lying, and I would suggest that you choose your words a little more carefully when speaking to an attorney. Cheers.

Charles Azmit

The Verizon support page for ISIS does say that the card information is stored on the NFC-SIM Secure Element. If that is in fact the case, and it does not use the same SE as Wallet, is your argument now invalid?

cphilano

The secure element just refers to the secure hardware part that secures your sensitive data whether it be integrated on the device itself or an NFC SIM. The NFC SIM has a secure element that would only be utilized by Verizon's investment ISIS, so basically it creates the same environment as to which it's arguing against Google Wallet.

ISIS does access the secure element whether on the dedicated hardware chips or NFC SIM. The NFC SIM will most likely be for phones that do not have NFC integrated chips. The secure element is not limited to integrated hardware. NFC SIMs have secure elements also.

What is a secure element and what are the form factors?

A secure element (SE) is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g. key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities.

There are three different form factors of SE: Universal Integrated Circuit Card (UICC), embedded SE and microSD. Both the UICC and microSD are removable. Each form factor links to a different business implementation and satisfies a different market need.

Alex Carlson

I thought you've done hundreds of hours of research on this topic? Why are you relying on a screenshot from the ISIS app instead of actually researching the ISIS FAQ?

"Your payment card information is encrypted and stored on The NFC-SIM’s
Secure Element, which is a dedicated hardware component that operates
independently from the rest of your phone and limits access to certain
apps, like the Isis Mobile Wallet."

Either you somehow missed this very visible information in your research (or after it had been pointed out to you), meaning you're negligent or incompetent, or you knew this information prior to posting and are deceptively making a claim you know to be untrue. Which is it?

EDNYLaw

After speaking to the patent holder for NFC technology, your assessment is completely INCORRECT. It doesn't matter if VZW uses NFC SIM or hardware SIM. By denying access to the Hardware SIM, VZW IS VIOLATING C BLOCK REGULATIONS. There is no proprietary right to the SE. Google/VZW, whomever holds the keys to the SE, have locked it down so no other developer/application and access it. Their claims that "they don't know how it access the hardware" are patently false.

So, now that your assessment is 100% incorrect, you've proven Verizon has lied to its customers and presented false information, and based on the FCC regs, there is no difference between NFC SIM and NFC SE as denial of downloading apps violates C Block, is there anything else you'd like to add to your argument?

I'd like to ask a question. Do you work for Verizon? Your arguments sound exactly like the ones they use (that is to say, poor) and you seem to want to screw consumers, flaunt government regs, and support monopolistic behavior from a corporation that rakes in over several billion dollars a year in profits. Am I missing something?

Why would anyone take their position when they are blatantly violating FCC regulations. Numerous legal scholars and mobile experts have address this situation and come to the same conclusion I have, in addition to the PATENT HOLDER OF THIS TECHNOLOGY, who agrees with me. Would you care to provide ONE SOURCE as to why you think this falls outside of the FCC regulations, or would you just like me to take you at your word that you have any idea what you're talking about?

EDNYLaw

To respond to your other point about the secure element and carrier involvement. I can tell you did not read my complaint as this is specifically covered. The use of the secure element in no way involves the carriers other than the actual data transmission. However, this is just using a data connection not unlike every single other application that requires a data connection (facebook, twitter, G+, Chrome....) so if VZW's argument is they don't know how the data connection will affect their network, then they can make that argument for every single app the don't like. Obviously, you can see how that argument MUST fail.

And that's precisely why Verizon doesn't want to use Wallet - they have no idea what's happening in the transaction, it's a black box. They hand over the secure element - a piece of hardware - Google gets to use it (and only Google) in the way Google wants, and Verizon has no role, no ability to ensure security. ISIS provides them much more oversight. Whether Verizon truly needs this oversight as a matter of securing its network and the transactions of its customers is something I am far from being an expert on, but they seem pretty adamant about it, and they've already signaled that they're getting on board with the SIM-based SE for mobile transactions.

I think you're playing down what is a very large gray area here in what constitutes a reasonable network security decision. Verizon doesn't like the way Google Wallet works with hardware. They've made that pretty clear. They've also made it clear they're actively discussing the situation with Google.

I'm playing devil's advocate here, but you seem very willing to ignore what are legitimate questions about the applicability of Block C rules, and the fact that ISIS and Wallet are far from identical from Verizon's network management / security point of view.

Is this all a big veil designed to keep Google Wallet off Verizon phones as long as possible? I won't deny that, knowing Verizon, it certainly could be. But I also don't think your case is nearly as strong as you suggest. This simply isn't like the tethering decision from 2012.

Chris

This is a bunch of horse shit... You David are leaving out a very big part of the argument... Customer choice. If your argument were to stand then it would mean that Verizon could deny an app based on anything they deem to be a security concern. But Verizon has stated AND EDNYLaw has stated that Verizon is not blocking any apps! This is not a concern where Verizon is looking out for the "security of the network" this is all about money. This is a huge cash cow and Google beat them to the punch. This is about being a middle man of all monetary transactions performed using NFC. Something Verizon wants to be in the middle of. But again, it should be about consumer choice. I should be allowed to pick who I want to be my provider of payments and I can't do that if Verizon is blocking me and I am under contract.

cphilano

I have to agree with Chris here. Your argument is implying that Verizon has exclusive rights over the consumers device. The argument being made here is that it's the consumers device, and the secure element is not Verizon's to hand over or guard. The transactions have nothing to do with Verizon's network security.

Hi Jay: That's not what I'm saying at all, actually. I'm not sure where you're finding that I'm confusing that distinction, because that distinction is never once at issue in this piece. Where, exactly, is your evidence that Verizon blocks Wallet from being downloaded to devices? The only example that is even inferentially supported is the Galaxy Nexus, and unless you've obtained a discovery order against Verizon to determine that's what actually happened - or documentation from Google indicating this occurred - I'm guessing even that isn't something you can concretely prove.

There is certainly a difference between Verizon declining to be a Wallet partner and actively telling Google that it must not make the service available for download on Verizon devices, and I've yet to see any evidence that the former isn't what's happening. You are, by everything I've seen, just as much an outsider looking in on the Google / Verizon relationship as anyone else.

You also continue to avoid the issue of how Block C regulations apply at all in the case of a feature such as Wallet, as you did in the Reddit thread, because of the implications of the issue of the SE hardware involvement.

EDNYLaw

Actually if you read my complaint, I contacted by Google and Verizon, where Google basically (I don't have the quote handy) places the blame squarely on Verizon. Also, the inference can be drawn that since Google Wallet is available on Sprint, AT&T, US Cellular, and T-Mobile (I think), Google's not the one blocking it.

I will concede, I'm working off an assumption (but a well researched and supported assumption) that Verizon asked Google to block the application. The prima facie evidence for this would be: GW is available to non-VZW customers, Google's response to me basically blamed Verizon specifically (they did not state carriers the named Verizon), VZW's response to me was a semantic argument that did not address the point of my question, why they are blocking GW, not if. Now, that's more than enough evidence to establish a prima facie case for violation of C Block. According to the C Block regs, upon prima facie VZW MUST rebut the evidence to show they ARE NOT violating C Block.

Legally, I can tell you I've presented easily enough evidence to establish a prima facie case of violation of C Block.

Now, the FCC, in their 7/31/12 decree, stated (and I've referenced this numerous times in my articles and complaints) requesting Google to block an app IS THE SAME AS VZW actually blocking the app. This is fact, this is now FCC precedent.

Therefore, upon establishing prima facie evidence (which I have), pursuant to 47 CFR 27.16, VZW is REQUIRED to show how they are not violating C Block. They have not, nor has the FCC pursued this. Now, a non-lawyer may say "they said they're not blocking the app." This is not rebutting in the legal sense. They must come up with sufficient evidence that upon a preponderance of the evidence they are not violating the C Block regs. That's how the law works.

So, in your article, you're making a conclusory statement that VZW is not violating C Block, in terms of their approach with Google Wallet, because they're not doing anything to offend C Block. I, on the other hand, am alleging (different than concluding) that they ARE violating C Block, because of the evidence I've mounted against them. Now, following C Block requirements, they need to rebut that, which again, they have not.

There's the case. This is how issues of federal law are handled. I've worked for 4 different federal judges, drafting well over 100 judicial opinions. I am well versed in how the law operates, both from a procedural and substantive standpoint. The ball is now in VZW's court, assuming the FCC actually does something. But in any case, the evidence is there and I invite you to read my complaint to see all the details. It can be found on my webpage.

Well, that confirms my suspicion about the issue of the VZW / Google relationship - no one actually knows what's going on.

Once again, please present the argument that Wallet even falls within the Block C requirements. There have now been numerous people that have questioned if Wallet, as an app, is even eligible to be considered under the requirements because of its close relation to a specific hardware element that Verizon purports to control on the devices it sells.

As far as I can tell, your only point is "they allow ISIS, so they must allow Wallet," which isn't really a complete argument - you never make the case that ISIS clearly falls within the definition of the kind of software the Block C rule is meant to prevent the blocking of. You're also well aware at this point that ISIS and Google Wallet are *not* identical.

ISIS functions via the SIM secure element. Verizon handles much of the traffic involved in authenticating and processing an ISIS transaction. Google handles the entire stack of every Wallet transaction, aside from the carrier's internet connection acting as a dump pipe. Verizon has made it pretty clear, even to you, that Wallet is doing something it doesn't allow any other app to do (take over exclusive control of the internal secure element) on its network. The one comparable service, ISIS, operates through a method Verizon has approved for its network (via SIM secure element, which Verizon has publicly stated to have security advantages over the internal SE), on a service Verizon has helped develop, and a service that Verizon assists in operating.

I am well aware that your basic argument here is that this is anti-competitive and that Verizon is "hiding" a slightly sinister purpose. I don't necessarily disagree with you. But this feels more and more to be a round hole and a square peg issue. Verizon has a standard it considers secure for its network, and I'm sure Google and Verizon are talking about the possibility of working out a solution using that standard. If Google feels Verizon's being anti-competitive, they're big boys - they can file their own lawsuit.

EDNYLaw

Both Google Wallet and ISIS fall exactly within C Block, as it applies to any application on a phone operating on the C Block spectrum. Specifically the FCC states that anything that competes with a carrier's service cannot be blocked unless it falls within an enumerated exception. The way statute works (such as the US Constitution, technically not statute but same effect) is that if the statute says "applications" but doesn't specifically exclude "applications that specifically interact with hardware elements above and beyond those that are general (screen, keyboard, speakers...)" then that means all apps fall within the provision. The statute must specifically enumerate exceptions to the blanket statements, as they've done where the exceptions are laid out.
However, VZW is still required to justify it's position to the FCC beyond (we don't block Google Wallet, which they clearly asked Google to do). It's part of the C Block regs, 47 CFR 27.16(f) to be exact. In fact here it is "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." Now, in my complaint I address every one of Verizon's potential arguments and counter them with actual fact.
So, the apps absolutely do fall within the regs, in fact here's the language from subsection (b) " 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."
There's no hardware specific limitations, and without copying and pasting from my complaint, I address subsections (1) and (2) and how they're inapplicable.

Yes, I understand the procedural points. I disagree on the logic - your case still rests on a total unknown about whether Verizon is blocking anything, and I would think fails the prima facie requirements.

You are quite literally guessing. You have no direct (or really, indirect) information showing that Verizon has blocked Wallet, or told Google to, but continue to assert that "they clearly asked Google" to do so. And I can only assume this argument is based on the tethering complaint last year, and that because it appears to be a similar strategy, it must be the same strategy.

Google saying Verizon is the cause of Wallet being unavailable on Verizon devices is not that same as Google saying Verizon has told Google not to make Wallet available on its devices. There's a big difference between "Verizon didn't want to partner with us, so Wallet isn't on Verizon" and "Verizon told us not to distribute the app on its network."

Chris

Jeez you are so dense... He already stated that he is guessing. He wants Verizon to prove that they are not blocking the app. That is the whole point! Have you even read anything he has [email protected]?! :

"VZW is still required to justify it's position to the FCC beyond (we don't block Google Wallet, which they clearly asked Google to do). It's part of the C Block regs, 47 CFR 27.16(f) to be exact."

Alex Carlson

Another point to bring up is that Google Wallet itself fails to work on Verizon's network, which means Google added code to specifically exclude Verizon users from using Google Wallet, even if they manage to sideload the APK.

"All of the people claiming Wallet works on their Verizon phones installed a patched version of the APK."

I have installed Wallet on my VZW GS3 many times (have to do it every time I flash), so I can tell you that is just not true. The whole point of changing the Build.Prop is so you can trick the Play Store into believing you're allowed to have access to the official Wallet - not a patched version.

I will admit that I have never tried to use my phone for a POS transaction, but based on other GS3 owners' comments, I have no reason to believe that would be a problem.

Alex Carlson

Derp, you're right. I meant they patched build.prop to get around the check Wallet does to kick out anyone on Verizon.

Just to be clear, though, you can change your Build.Prop back after Wallet's been installed, and it works just fine on VZW's network. So the check is only done at the time of installation.

Alex Carlson

Right, I was mainly pointing out that it isn't simply the case of Verizon blocking the app from being downloaded, but rather Google added code that blocks the app from working as well (in the form of that build.prop check).

Snake

Yep. My GS4 has it running. After you run it for the first time, you actually have to change the build.prop back for it to work correctly. Hate VZW for this crap. Nickel and dime the consumer from Day 1

Chris

Hey Derp face. I don't even know what a Build.prop is and it works on my GNex perfectly. My phone is not rooted. I first installed it when Verizon made a mistake and was allowing it to install, it has worked on my phone ever since with no modifications. DERP!

EDNYLaw

Actually, prima facie means: a complaint has addressed each and every element of a claim. As a complainant, under C Block regs, I don't have to prove any allegation as true. See, what happens is, the burden then shifts to Verizon to prove that they're not violating C Block. I have alleged more than enough to establish a prima facie case. It is now Verizon's burden (assuming the FCC does it's job) to rebut the presumption they are violation C Block. That is how the law works, in fact, that is how ALL law works.
I'm also not entirely sure you understand direct and indirect evidence. I, arguably, have direct evidence by way of Google stating specifically Verizon doesn't want the app on their network right now. All other evidence is indirect (but in law, direct and indirect evidence are given the same weight). Indirect evidence merely means an inference has to be made. I've laid out the case that a reasonable person can make the inference that Google Wallet works on every other carrier (on GNex) but not on VXW, VXW has ISIS, they have a history of blocking apps that compete with their services, therefore I can allege they are blocking (or causing to be blocked) Google Wallet. That is the very definition of indirect evidence.

didibus

If I understand your argument is that the Secure Element on Verizon's phone was not put into the phone by the OEM manufacturer of the phone, but it is instead bundled inside the Verizon SIM card. Thus, Google Wallet can not operate on Verizon phones, because the phones simply lack the presence of a Secure Element? Which ISIS manages to make due of, by bundling the Secure Element within it's SIM card. So effectively, Verizon is not blocking Google Wallet from being downloaded and utilized. It's simply that Verizon phones do not meet the hardware requirements for Google Wallet. And it would be a stretch to force the Verizon Secure Element, which it bundles into it's SIM, to work with Google Wallet, because in doing so, Verizon would maybe make it's own services, which it provides through the SIM, that of ISIS, less secure?

Am I understanding this correctly?

ProductFRED

Verizon most likely blocked Wallet because they wanted ISIS to be used exclusively on their network for mobile payments:

1. As a few others have pointed out, there are now (and were when it was still the "Android Market") tether apps that do/did NOT require root. Just like how there are backup apps that do NOT require root.
2. "There is absolutely nothing to stop that happening - but the app wouldn't actually work." And yet there's at least a hundred people (I'm definitely lowballing that) who have rooted Verizon Galaxy Nexuses (since that's the only way TO get it to work, a simple sideload won't do), installed Google Wallet, and use it on a daily basis. Argument = invalid.
3. You're forgetting that the ISIS app ALSO requires access to the secure element, which I'm pretty sure Verizon stated was the main reason for not allowing Google Wallet in the first place. Again, argument = invalid.

2.) Again, the app is made specifically for that device. That's a horrible argument.

3.) The ISIS app uses a SIM secure element and Verizon controls a large part of the "chain" involved in transactions, while Google Wallet uses the internal element and Google controls the entire "chain," as I pointed out.

Sorry to be the bearer of bad news, but you are acting like a 12 year old who didn't get your way. You are a "professional" journalist, but right now it's hard to consider you a professional in any form.

The "facts" that you do present are largely untrue. "There is absolutely nothing to stop that happening - but the app wouldn't actually work."

Not true. As you stated, the app DOES work on a Galaxy Nexus, and I saw a comment from someone who was using it on the S3. That's just one of the many false pieces of information presented here. I'm not going to continue proving your mistakes, because I don't feel that I have to.

My biggest problem right now is not the article itself anymore, the bigger problem is your juvenile responses to the people who don't have the same opinion as you do.

NexusKoolaid

"the bigger problem is your juvenile responses"

...says the pot to the kettle....

Jonathan Figueroa

All I know is Google needs to find a better way to get Wallet to work. My Secure Element chip got fried on my VZ Galaxy Nexus during a Rom change up and now I'm out of luck forever on this phone of ever using that feature. It doesn't help that the 32gb model is basically nonexistent now at Verizon also so a warranty swap is pointless. There has to be better ways Google, figure it out.

Moral of the story, screw VZW. Google Wallet is pretty awesome. I love the multi-card management.

takabanana

"Only one card's credentials are stored on the element at a given time" - this is only true in the way Google Wallet (as of 1.5) is doing it. Since Google took over TxVia, they went from "Storing all/multiple credentials" (pre-Wallet 1.5) on the Secure Element to "Store a single virtual/proxy credential" on the SE - so that the POS payment terminal sees that one card, which Google passes through to whatever "real" credentials you have selected under Google Wallet in the cloud. Google eats the "Card Not Present" transaction fees right now while the proxied transaction gets transferred to whatever card/Issuer the user has selected in the cloud. Technically, the SE is just a secure memory on the device (CDMA) or on the USIM card (GSM) and has enough memory to store multiple credentials. Problem with pre-1.5 is it required Google to have relationships with each Card Issuing banks (i.e. Chase, BoA, etc) to have the ability to manage/store (OTA) credentials on the SE. So with 1.5, the user is able to define in the cloud, what the single "Google proxy card" can act as - which bypassed the annoying time-consuming process of trying to get Issuers on-board.

The biggest problem with all of this is like you said - the carriers (MNOs) want "in" on the transaction fees - another way to make money. Verizon/AT&T/Tmo didn't like Google owning the SE (therefore owning the keys to encrypt/decrypt the data on it). - that's why there's Isis. But they will hit the same exact problem(s) as Google Wallet pre-1.5 - need to get Issuers on board, without creating a proxy card on the SE - as well as Merchant adoption of NFC/Contactless Payments (which should happen by Oct 2015 with the EMV mandates - and liability shift - that Merchants upgrade their POS systems to support PIN-and-Chip, which will also most likely include contactless/NFC technology)

Just remember - to access the Secure Element - you need agreements with the MNO networks - they own the Secure Element and the primary keys - Sprint is the only one that allowed Google to work with them. Look up "Trusted Service Manager" (TSM) - it's the middle-man technology that allows a Service Provider (i.e. banks/issuers) to manage (install/remove/update) credentials in the Secure Element OTA (Over-the-Air) through the MNO network. Think of the SE as a hotel. The MNO TSM owns the "hotel" (SE) and manages "rooms" (allocates and "rents" sub-sections of the SE - called a Secure Domain - with a fee - i.e. monthly or transaction-based fees) to each "customer" (Service Provider) who wants to store info (i.e. credentials). The SP works with a SP TSM to handle managing the actual data (stuff that gets stored in each "room" or Secure Domain within the Secure Element - helps with the encryption over the air). The SP TSM works with a MNO TSM (for each network) - standards provided by GlobalPlatform. If the MNO refuses to give you a relationship - guess what? You can't access the Secure Element. They have the "master key" to get into the "hotel". Everyone wants a piece of the pie... this is why it's taking so long in the US to get this stuff rolling...

(I work for CorFire, or SK C&C USA - we provide the TSM for Google Wallet)

Very interesting. Thanks for the added info on how SE works in terms of the relationship with the carrier - that's not something I was aware of. Definitely goes to show just how deep the MNO has its hands in the SE.

takabanana

And the SE owner also gets to determine which apps has access to their own "room" in the SE too - so multiple apps can technically have access to separate parts of the SE to store its own encrypted data.

OEMs (device manufacturers) own (the encryption keys to) the SE - but GSM carriers (AT&T/Tmobile) own the SE because it's in the SIM card (and in Verizon's case, the 4G LTE SIM card as far as I know). They are the "master" hotel owners...

It's a lot of info and I'm still learning as well - but I dumped what I do know :-)

It will take a few more years to settle down (main bottlenecks being relationships - on who makes what money between MNOs and Service Providers - and also the merchants not adopting contactless/NFC POS terminals because they have no incentive to - until the EMV mandate in Oct 2015 where they become liable for fraud without it, versus the card-Issuing banks currently being responsible). It's an exciting nascent industry - but so many people fighting and disagreeing (at least in the USA) makes it frustrating from my perspective - this is why the US is so far behind Asia and even Europe and Canada when it comes to this - they are moving much faster than us with Mobile Payments based on NFC.

MCX (led by Walmart) is another thing to watch - they are competing against NFC solutions (Isis and Google Wallet). As well as other "intermediate" mobile payment solutions based on Barcode (Starbucks app and Dunkin' Donuts app - CorFire did the Dunkin app). Many merchants and Financial Institutions in the US are doing a "wait-and-see" approach.

Steve Green

The Secure Element owner should be the owner of the phone.
Someone else retaining ownership to a device I paid for is should be a crime.

Chris

Then how do you explain the fact that I have Wallet working on a Non-Verizon branded rom loaded on my Gnex? Without root? The network has nothing to do with the SE... Sorry...

takabanana

Whew - ok - this is what I get for being crazy high-level, generic, simplified, and not writing a book on it. :-)

I should re-word a few things: 1. When I say "own" - I mean owning the keys needed to access the Secure Element. 2. I was concentrating on the (more common) SE model where the SE is on the GSM USIM - in those cases, the MNO network owns the SE (owns the key to access them). In devices that have an embedded SE (eSE - the chip soldered on the phone's main board, not on a SIM card), the owner can technically be anyone - OEM or even the OS.... 3. I was concentrating on the (more common) TSM model where there is a MNO TSM and SP TSM (Google Wallet's case is not - they use a "Simple" Mode TSM that has both functions combined, provided by CorFire through First Data; the split-TSM model is, and will be, more common in the future). In the split-TSM model, the Issuer's SP TSM must connect to the MNO's own MNO TSM to be able to talk to the SE and manage it. 4. Technically, if you already have the SE "hotel rooms" divided up and keys given to the SPs to manage the data/credentials within their own "rooms" (Secure Domains) - the MNO doesn't matter - the MNO only handles management of the "rooms of the hotel" (although they can completely "wipe/delete" your room) and not the content stored in it. There is sooooo much more to this - I was just trying to simplify in the most common cases.

In YOUR case - you most likely have a device (like a Galaxy Nexus) with an embedded SE (eSE soldered on the phone's main board). In which case, Google most likely has the Master Key (the MNO TSM has the Master key to manage the chip "room" partitioning and access) - Google creates a relationship with SE Chip Manufacturers (i.e. NXP) and get the Master Key from them for a specific series/model chips to allow the (MNO) TSM to access them OTA. If your phone had an embedded SE that is not owned by Google (i.e. a chipset that Google has not gotten the Master key to from the manufacturer), then the (MNO) TSM cannot access it. Now, here's the OTHER unique thing about Google Wallet - their (CorFire/First Data) TSM uses Google's own GCM (was C2DM) to communicate to the device to initiate a secure channel between the SE on the device and the TSM. MNO TSMs can also use the network-specific protocols - like SMS-PP - but that's specific to that MNO. GCM/C2DM works over any network (network-agnostic). WHEW.

So - in general - Why does Google Wallet work in your device on Verizon?

1. You rooted it to allow side-install of Google Wallet (because, you know, Verizon wants you to use ISIS so they can make money from transactions themselves!)

2. You have a CDMA phone (therefore - Verizon or Sprint - because AT&T/Tmobile/GSM would already have a Secure Element on the SIM) with an embedded Secure Element that is specifically supported by Google and Google Wallet (they created a relationship with the SE manufacturer of that specific SE chip in that device, and got the Master Key) - you're NOT using the Secure Element on a 4G LTE SIM because that would be owned by your network - Verizon. (I do wonder here - why Verizon couldn't have the OEMs remove the eSEs on these devices - but that's a separate business discussion)

3. Google Wallet's TSM (by CorFire through First Data) is a "Simple Mode" TSM which combines the SP (Google's Service) and MNO (SE Lifecycle Management) functionalities. The MNO component of this TSM uses GCM/C2DM to communicate to the device - which does not require the network - unlike the more common (especially from now on) split-TSM that works in "Delegated" or "Authorized" Mode - where the MNO TSM is specific to a Network - and in the GSM/USIM case - the MNO has all the Master Keys to them to access the SE on the USIM.

Hope that makes sense?

Alex Carlson

This is probably the most information I've ever seen describing how the mobile payment system works. Thanks a lot for sharing!

takabanana

Thanks Alex! I've been in the industry for just 1 year and there is still SO much I am learning - it's quite complex (all the different players trying to set a standard) - unfortunately, we're probably still 5 years away from declaring a "winner" or two or three; the EMV mandate for POS terminals in 2015 will be the biggest influencer I think... we'll see.. :-) PayPal is also in an awesome position (as a cloud payments provider fighting against NFC and barcode solutions)....

Oh Boy! You've come a long way in one year. I've spent quite a few months on this as well, and the information out there on this topic is frustratingly inaccurate. Awesome job, posting these detailed comments.

takabanana

CORRECTION(*sigh* my brain is so old) - #1 - NOT rooted, but enabled "Allow Unknown Sources"... brain fart! Dunno why I said rooted... just need to be able to sideload the APK for Google Wallet... Sorry... Getting OLD...

Bryant

I called Walley support yesterday to have them reset my secure element on my Verizon galaxy Nexus. It's up and working great again.

Marcellus1

"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".

You're wrong about this. The Galaxy SIII, as an example, DOES support Wallet and Wallet can work fine on it, provided you jump through the hoops to install it.

I have personally submitted a complaint to the FCC and received a response from Verizon stating that Wallet is not allowed because it requires access to the secure element, even though Isis also requires access to the secure element.

Altogether, I think it's a poor argument and it's really just a smokescreen to help prop up their investment in Isis by preventing Google from being able to compete.

The big question for me is, if it's really all about the phone's secure element vs. the SIM card secure element, why does Google not just update Wallet to work with these special SIM cards? From my understanding, the SIM cards add NFC support even to phones that do not have it built in. With a tweak to Wallet, Google could suddenly get on nearly every phone, not just the newer NFC-enabled phones....

"jumping through the hoops" does not = "suddenly sprouts Wallet support." You have to tell the phone it's a Galaxy Nexus, meaning no, the Verizon Galaxy S III does not support Google Wallet officially.

There is a significant difference between "basically works" and "officially supported." I'm not arguing it can't be made to work, I'm saying there's more to it than just letting people download the app on the Play Store.

Marcellus1

Of course there is no official support for Wallet on the S3--that's the whole point of your post. All a lack of official support means in this case is that installation is not as simple as downloading from the Play Store. However, whether the device supports (i.e., is capable of running Wallet) is an entirely different matter. The S3 has everything necessary to run Wallet and lacks nothing. Your comment about telling your phone it's a Nexus relates to installation because the installer is programmed to disallow installation if the device name does not match Galaxy Nexus. However, once installed, the device name can be changed back and the program continues to operate without a hitch. Even the installer finds no problems with the phone itself as long as the check for the "galaxy nexus" name passes.

Chris

But that's not what you said... You said "There is absolutely nothing to stop that happening - but the app wouldn't actually work." The app does work. Back in the early days of Wallet when Verizon slipped up and allowed it to be installed, it worked perfectly. And today, if they allowed it on NFC based phones... IT WILL work... It has been proven it will work. You are incorrect.

Russell Walker

I think what's happening is that people are interpreting this article as saying that the Wallet issue isn't really Verizon's fault, but that's not the case. Verizon's still being an anti-competitive jerk, but whether or not it's an FCC violation is still kinda murky, because we don't really know the exact exchange between Google and Verizon that led to Wallet being blocked. Wallet's need for control over the secure element makes it not so black-and-white, and different from the tethering apps issue.

The only thing I'm confused about in the article is why the app wouldn't work if Google unblocked it for the Verizon Galaxy Nexus, and why sideloading it still works.

tyguy829

I have a verizon gnex and I'm pretty sure all i did was sideload the apk and wallet works fine for me. I am rooted, but i don't think that affects anything

Utter bullshit, this is about VZW making money from ISIS and that is it. There really is no need for the other rationalization about security or google wanting access to the secure element. David you should be ashamed of yourself, you have swallowed VZW's story hook line and sinker.

You assert that Google could make a Wallet app for a Verizon phone (for example a Galaxy SIII) but that it would not function because of the secure element? Specifically: "There is absolutely nothing to stop that happening - but the app wouldn't actually work"

What do you base that assertion on? Because if that were the case people would not be able to make minor hacks (simply to fool the installer) and then sideload the app.

I've seen nothing at all indicating that Google doesn't have the technical capability to:

1. Modify the Wallet APK to allow installation on the Verizon Galaxy SIII

2. Modify the Play store to allow download of Wallet for Verizon users with a Galaxy SIII

And have working Wallet for every Galaxy SIII user on Verizon who wanted it _today_.

The question is why doesn't Google do this? Again every piece of information we have on that indicates that it's because Verizon has asked (told) them not to.

Still don't see how this doesn't violate the C Block regulations.

codemonkey85

Is there a Secure Element present on the GSIII? I know there isn't on the GSII, which is why my fiance was able to install Wallet by sideloading but unable to actually use it in any way.

Utter crap from the well known village idiot, David Ruddock. Don't choke on the Verizon payola, you dope.

FrillArtist

The payola from Verizon must have been big. David Ruddock usually writes crap but this is another level.

Transflux

Wouldn't the following be possible?
1. Google allows Wallet to be installed on Verizon devices
2. Wallet is blocked from actually working on said devices
3. Verizon is prohibiting users from using this service
4. Verizon is now violating the rules

"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."
Wait, why not? Wallet works fine on my VZN Galaxy Nexus. What am i missing?

Bariman43

Regardless of what really is going on here, Verizon and all of the other piece of shit industry strangling monopolies can guzzle the fetid excrement from a large male bovine. As far as I'm concerned (and unwaveringly convinced) this is 100% Verizon fault. Give me Google Wallet!!

cphilano

The writer fails to recognize one simple fact when making an argument whether this is about consumers wanting to run the software they want as opposed to Google running the software and controlling the hardware. He should recognize that the consumer chooses whether Google Wallet controls the secure element or not. Google Wallet can be uninstalled and or disabled. This shouldn't be a fight over who gets to control the secure element because the consumer should be making that decision, and Verizon is clearly against consumers making that decision when it comes to applications that Verizon would like to make money off of itself taking for example, navigation/maps/gps, tethering, and now mobile wallet.

This is the same scenario as tethering. Verizon is saying that it is not blocking Google Wallet, but it has admitted to asking Google not to preinstall or include Wallet in the Playstore. Google has stated that it has done this at the request of Verizon. Also, Verizon, in a partnership with other carriers, is releasing a competing mobile wallet app that accesses its own nfc SIM card secure element or the secure element that resides integrated nfc chips. It's app would be doing the same thing that Verizon is arguing against. And as mentioned in this article, Verizon requested that this app not be made available. That is still blocking the app from its networks whether it was done by aggressively disabling the app or not. Verizon used its influence to "blockade" the app.

I'm not sure about anyone else, but I'm loving the back and forth in the comments. I don't think I've ever seen this many intelligent and coherent discussions in a single comment section. Regardless of who is right/wrong, the discussion is amazing. Codos.

shing

My S3 sprouts wallet support when I make it appear to be a Sprint phone instead of a Verizon phone.

Almighty Peanut

How come the Sprint S3, which is the same phone, allows the use of Google Wallet? I came from a Sprint S3 to a Verizon S3 due to moving in to an area not served by Sprint. I enjoyed Google Wallet a lot actually. Imagine my surprise when I had to unlock my phone, root, then put another rom and still jumping through more hoops to get Google Wallet working.

Verizon wants a piece of all of those pennies that are involved in every transaction. Google Wallet does not allow them to have it.

ToHellWithISIS

This is incorrect in many areas. First off, all of your main points have been addressed in Klimek's complaint. (Have you read it?) It doesn't matter who is actively blocking the app, what matters is who is behind it, which was also the case with the tethering issue. Furthermore, Google is NOT blocking Google Wallet. I downloaded it from the Play Store yesterday on my Galaxy S4. But when I open it, it says that it is not compatible. The fact that I can download it may be an oversight, but the fact that I can't install it tells me that there is something different in my firmware than there is in phones that can install it without problems, and that firmware is "optimized" by none other than Verizon.

To anyone who has been following this issue, the secure element is nothing new. It is the same thing that Verizon's ISIS uses, which is clearly stated upon installation. Somehow, when Verizon wants to access it, it is no longer a security concern.

Verizon is completely within their rights to block apps that they feel jeopardize the integrity of their network. A customer's personal finances are a completely different and unrelated issue. It is not their job to police financial transactions, nor do they have jurisdiction over such things.

The secure element does NOT store your credit card on your phone. It stores a virtual MasterCard that pays for the transaction, and once the transaction has been processed, Google bills your card of choice.

I think it is ridiculous to make it so difficult to root phones. Obviously if people still go out of their way to circumvent the carrier's desire to keep their phones unrooted, there is a demand for it. Rooting voids the warranty, and that's that. They have no right to tell me what I can and can't do with my $200+ (subsidized price) device that I paid for with my money. All they have a right to do is provide a very clear disclaimer as to the risks that come along with rooting. But this (and your point about rooting in general) is all irrelevant, as rooting should not be necessary to use this app. If the carriers gave it the OK, it wouldn't be. And using it on a rooted device (which people WILL do) leaves them open to more security risks than using it natively on a stock device.

Do you think it is a coincidence that the three carriers that are blocking (phrase that as you will) Google Wallet are the three carriers that have dropped big money into ISIS?

I have never heard anyone take Verizon's side on this issue, but now that I have heard such a week argument, it confirms how valid the opposing argument is.

TechieXP

Verizon isn't blocking Google Wallet, Google is. Verizon has stated that Google Wallet is not being blocked by them. Google needs to simply make the application work the way Verizon is suggesting. Google blocks any application that is designed not to work with a phone model or specific carrier.

There are hacks available that allow Google Wallet to be installed on Verizon devices. I shouldn't have to do this. Is Google wants the USA's largest carrier to use its service, then Google needs to do what it needs to, to make it work.

John Kiser

Which would be what exactly? It needs access to that secure element to work properly just like ISIS does... Verizon ASKED Google to block it otherwise Verizon could threaten with maybe not carrying anymore android phones for example.

Graikos

THAT was awesome! I now find myself not even caring about wallet. .. I had so much fun reading the comments that I am aching for more input and responses from people that either have no idea or just want to sound smarter than the other. Man, that was fun. Thanks! So.... will I get wallet on my Verizon Galaxy Note 2 soon?

Michelle

So frustrating...Got my GS3 nov '12. Came with google play and the ability to bill to my verizon account. Then suddenly may '13, can't do it. Round and round with tech supports--GP (google play), verizon, samsung...learned about wallet (which proved I had done it b4)

Mom has same setup. Got hers in late may '13. GS3. Tried to bill to acct on GP 1st time yday. No go. Now learned that verizon is working with a company called "BillToMobile." (fyi...last month, Verizon store reps didn't even know @ ability to bill 2 acct.) If Verizon disabled bill to acct in GP.. why not have the guts and decency to tell me? 3 months of runaround...STILL they say nothing!

Michelle

Where did my post go? Sigh...anyway...After getting the runaround with tech supports from Google Play, Verizon, and Samsung starting in early May 2013...and continuing until now...I am glad to find this post. It explains a lot. I didn't know about the existence oc Wallet. But until May, I could purchsse spps snd music on google play and bill to my verizon acct. Then...screech...It ended...no notice...I found out that verizon in-store reps didn't even know that the feature had even existed. Now I find out that verizon is working on something called "BillToMobile." Hardly any "participating merchants" according to the BTM site. And CERTAINLY not google play. What I don't understand is that if it was a "hardware issue" for Verizon to block, it is pointless--same phones as the other carriers. At least I have a strong signal. That's more than I ever had with Sprint---even 2 blocks from their headquarters. Aargh!

grundy923

It is an issue of Verizon not letting consumes use the software they want. It is not an issue of Verizon not wanting Google to control the 'secure element.' Why on Earth would Verizon have the right to say who can control a piece of hardware that *I* own? It's MINE. And I want to run the software that uses it. Verizon *IS* preventing consumers from being able to run the software they want.