yashsingh1/xdaforums huggingface dataset:
[Nexus 5 Q&A, Help & Troubleshooting] RaymondPJR:
Thank you, a confirmation of being heard was all I was looking for. Personally although I'm still very much a fan of Google, I think Samsung Pay is the one that may eventually come out on top. I don't think Google has done anything to make the user experience any better than it was with Google Wallet. The places that had scanners all had a different implementation and clerks mostly had no idea how to operate their particular system. Then there's the fact that NFC scanners are still quite scarce. If Samsung is able to get more banking institutions onboard with their payment system, that's the one I'd prefer since it will work on any type of hardware. If they can't, then that's no different than hardware being scarce, imo. Unfortunately I have no way to test either atm.
[Nexus 5 Q&A, Help & Troubleshooting] jt_04:
really sorry if i'm wasting your time here, but i'm genuinely curious as a fellow engineer in an unrelated field. what would the ramifications be if mobile touch payments were considered "card not present"? Because as the user, i wish i had the ability to weigh that against the cost of not having full ownership of my device.

based on a quick read of the apple pay site (#1 result of your google search, ironically enough), it comes down to trusting the device passcode as verification that the cardholder is present, "instead of the more traditional methods of PIN, signature for transactions in stores, " etc. I just wish there was a happy medium where we could choose to accept a little more inconvenience of entering a traditional PIN or signature (mine is usually a scribble anyway) in exchange for having a mobile payment system with root.

I say all this, but I'm sure greater minds than mine have thought through all these issues and arrived at the current solution as a result of a various number of justifiable tradeoffs and decisions, and it will be up to each of us in the root community to assess the final tradeoff of whether or not it's worth giving up root to have this capability.

Thanks again for your time and connecting with the community.
[Nexus 5 Q&A, Help & Troubleshooting] jasondclinton_google:
Not speaking specifically about any particular product, company, or technology (because this really has nothing to do with Android Pay), "card not present" transactions are generally:

More expensive to clear

More likely to get flagged as risky and declined

Occasionally subject to different rules

The devil is in the details and I'm vastly simplifying here but that's more or less the jist. (Again, this has nothing to do with Android Pay because it's not a "card not present" transaction.)
[Nexus 5 Q&A, Help & Troubleshooting] Robalboa:
i see your point here. most likely its the 1st point on your list. its just hard to understand that this app worked perfectly with no issues and now all of a sudden all these rules.

enough rules to run people off.

i know this isnt in your department but i wonder if they realize how many devices are rooted?

for every husband that roots he also roots his wifes phone most of the time to remove bloatware and battery consuming apps etc. also most of the kids are now rooting their devices for all the benefits. and we root to keep our systems up to date with all the latest patches (IE stagefright etc) bloatware , battery etc, even to fix things that are broke with the underlying android system out of the box. (before google fixes them)

this move literally cut off a HUGE chunk of the android users from pay access.

this move by google may in fact kill android pay all together. I love Google so much too. my first gripe since 2000.

anyway if they dont listen to the customers i know they'll heed the numbers.

its really all about numbers. we all know that
[Nexus 5 Q&A, Help & Troubleshooting] WhosAsking:
I've mentioned it a few times, but I don't know if anyone acknowledges it is an issue. Google likely isn't doing this of their own volition but because they are being pressured by the likes of Visa and MasterCard themselves to implement these new standards.

The primary motivation is a "liability shift," a change in the terms of merchant agreements between card issuers and merchants. They basically require that merchants begin implementing EMV and tokenized transactions or, should there be a data breach, it's the merchant who has to foot the bill, not the card issuer.

The old Wallet, in this case, doesn't meet the standard as it's based on the old MasterCard PayPass system, which if you'll look carefully is being phased out. This means if there is a problem and there is a fraud using the Wallet information (such as via an NFC sniffer), the bill will end up on Google's lap, not MasterCard's.

Thus the transition to Android Pay, which works more like an EMV system. This is also why there was a transition period: because merchants who had dropped their contactless systems in the past are setting them up for the more-secure systems being implemented now: first with Apple Pay (which uses a Secure Element) and now with Android Pay.

Now, as for the reason Android Pay won't work on a non-pristine phone, again this goes to liability. The card issuers apparently insist on an unbroken chain of trust in any device that uses a tokenization system, figuring that any break in the chain allows for some kind of subversion of the system: if not now, then in the future. They're basically trying their hardest not to discover yet another massive card breach. They have enough egg on their faces, so don't blame them for being uptight. Since the card issuers have the power to deny the ability to Google as well as impose penalties and liability risks if Google doesn't comply, you can see where this is going.
[Nexus 5 Q&A, Help & Troubleshooting] karthics4:
I just got a one plus one after my nexus 4 died and android pay works fine. I have a locked bootloader. Although I'm a bit annoyed it only works with US banks for now. Hopefully UK banks will jump on board soon
[Nexus 5 Q&A, Help & Troubleshooting] noncomjd:
What one takes away from all of this is the tacit admission that Wallet was insecure (although probably no more so then the physical card in your pocket and most other apps) and they have attempted to "patch" that with Android Pay. I did use Google Wallet and aside from the lack of tokenization and lack of wide spread adoption by retailers, I liked it. I currently use Looppay (more specifically the Loopay FOB) which can be widely used, no tokennization, but it is convenient (I probably use Loopay for 90% of my purchases), so it gets used a lot. AP updated my Google Wallet and because of the issues here (root, "can't verify device.software" and because I'd have to lock down my phone) I simply deleted the app, who needs the hassle.

The difference between Android and IOS is Android users have always had a certain level of control. IOS users have never had (or really seemed to want) control and have been willing to live in a restricted locked down environment. (Most) Android users want and expect freedom and ultimately will find a way to get what they want. Work a rounds are a *****, but they are a fact of life and they (already) will be had here. Google has some serious decisions to make. They can take a hard line stance and not modify AP to reflect what people want, in which case AP will go the way of Google Wallet and never gain wide spread adoption by users and will be another Google historical footnote or Google can make changes people want and maybe it will flourish. As it is, when and if Loopay adds tokenization I will never look back.
[Nexus 5 Q&A, Help & Troubleshooting] WhosAsking:
The way LoopPay works precludes it advancing to tokenization. It's basically an electromagnet that simulates a swipe. Sorta like how those cassette adapters work, only more sophisticated. Furthermore, Samsung has bought out LoopPay, intending to incorporate the technology into future Galaxy products. The rub is that swiping is likely going to phase out in the coming years. The US was one of the big holdouts, but with new rules set up by Visa, MasterCard, and the others (primarily by ways of liability shifts), Chip and other EMV transactions will be the way forward. That's why you cannot swipe a Chip card on a pad that has an active Chip reader (it'll tell you to use the Chip instead). Expect this to continue to progress.
[Nexus 5 Q&A, Help & Troubleshooting] AndroidDeveloperLB:
True, but I'm sure there is a solution for this.

---------- Post added at 11:32 AM ---------- Previous post was at 11:29 AM ----------

The exploit is for getting the root access. If you already have root access, you don't need to use an exploit.

If root would be legit and official, of course it should have a UI for the user, to choose which apps to allow root access and which shouldn't (like SuperSu).

Exploits should all be handled and they should not be the way to gain root.
[Nexus 5 Q&A, Help & Troubleshooting] dk_zero-cool:
[MENTION=6957306]jasondclinton_google[/MENTION]

First of all, making information gathered from a device a part of the security is simply a bad design. Do your websites security also depend on the header information from the client? Making a security design for this type of thing, that does not conflict with custom ROM's, root access etc. is not only possible, but better and already in use by other companies. My country has already been using a similar product for some time. So don't say that it cannot be done without these ridicules restrictions.

Second, if Google is having such a big problem with rooted devices, how about you stop reducing applications possibilities? Android is becoming more and more boxed in, allowing applications absolutely nothing. I for one is becoming really tired of developing for Android. Every single time a new Android version is released, more features are removed from the API's and your application needs to be rebuild and former features needs to be replaced by dirty hacks. Does google really think that ALL developers only want to create browsers, games and launchers? No, we (developers and users) love tools. But Android is no longer a platform that supports anything, not unless you add root and/or xposed. Normally a platform will get more features added with each release., but with Android it is just the opposite. Applications get's their own little boring sandbox and is no longer allowed to play with anyone else. And I got to tell you that playing with yourself all day, quickly becomes less and less interesting.

So here is one suggestion. Instead of removing more features from the API's, how about you create an administrative permission group instead? The simply add these features that applications should not normally have, and let the damn users decide for them selfs by having them manually enable these permissions per application?
[Nexus 5 Q&A, Help & Troubleshooting] WhosAsking:
Rant aside, perhaps you can give some concrete examples of how this would work. And how would they contend with a process with root access which (like the Linux counterpart) is capable of doing anything?
[Nexus 5 Q&A, Help & Troubleshooting] dk_zero-cool:
It sounds to me like you do not know much about root or Linux. For one, root on Android is not a counterpart to root on Linux. Android IS Linux, and root is the administrative user account build into the kernel. Linux/Root = Windows/Administrator. And just like Root/Administrator on other Linux based systems and on Windows, it is possible to allow access to it, without compromising security by handling the access by a per process/app basis.

However, if you read my comment properly, you would know that it was not about root access. It was more about the fact that Google continues to remove API features from regular applications, without providing any alternatives. For an example since Android 5.1.1, applications can no longer get a list of running processes, which just broke one of my applications. This list provides no security concerns what so ever, yet they removed it. I can still access the information from the /proc directory, but from this location I cannot sort Linux processes from Android App processes. And this is only one example of the many features being removed over the years. In the beginning you could create all sorts of applications for Android, but with the later versions of Android, the API's has become so restricted and limited that your choice of applications has been severely limited. That is, unless you use root or Xposed Framework to make up for the missing options. Without one of these or both, Android would be useless, except as a small gaming console or a browser device.
[Nexus 5 Q&A, Help & Troubleshooting] noncomjd:
I was aware how it works (which is why I useit so much, it can be used where GW couldn't) and I was aware that Samsung bought it out. I'm not an engineer so I'm not familiar with the ability to engineer a tokenization solution although it would seem to me to be possible, but I think flying pig are possible, so what do I know.

The chip and pin solution are wonderful, but the account data is still readily available on the face of the card and as long as transactions are permitted without the card being physically present (on line and with these payment apps) there are still going to be vulnerabilities.

Getting back to my ultimate point: AP needs to be convenient and as flexible in the real world as possible, otherwise it is doomed. Restrictions and lock downs will not work. I would love to know what the level of initial use and repeated use is (Google will never make that public) I would bet it is pretty dismal. Google has managed to botch, cripple and limit some amazing applications/properties that had amazing potential, including Wallet and now AP (IMO).
[Nexus 5 Q&A, Help & Troubleshooting] WhosAsking:
Then we talked past each other. Going back to the topic at hand, Google is under pressure from the Credit Card companies to lock Android Pay down (or Google risks having the bill for a data breach passed to them), so AP won't work on any system they can't trust, on the assumption it's been tampered to alter underlying APIs, including those AP needs to maintain the chain of trust the CC companies demand. Since root can do anything and custom ROMs and Xposed can alter APIs at the source, modders are getting the door shut as a precaution. And according to our friend from Google, since anything of those sorts breaks the fundamental security model, AP and root (and the like) just can't mix and will probably never will officially...unless someone here can demonstrate a way to achieve an unbreakable chain of trust even with the omnipotence of root and (as the developer noted) within the 200ms window of an NFC session.

---------- Post added at 09:16 AM ---------- Previous post was at 09:06 AM ----------

The stripe reader is built on the assumption of a fixed number. It makes no sense to tokenize the stripe reader since readers are already being upgraded to take NFC and Chips (they may not be on yet, but the capabilities are lying in wait--virtually any reader that can take Chips will take NFC; it's easier for the likes of Ingenico to throw it all in and let the merchant choose what to turn on).

As for Cardholder Not Present, that's why there are those numbers on the back of the card, which are nowadays required for CNP transactions. It'd be a rare thing for a shoulder surfer to get a clear enough view of both sides of the card at once to get both sets of numbers needed to do a CNP transaction.

As for Android Pay, it's about money. Big-time money. Particularly the liability bill for data breaches. Let's not forget about the recent big-time breaches at places like Target and Home Depot. The card companies are under pressure to put a cork in it or face the music of the regulators. So they're laying the law down and telling merchants and intermediaries like Google, "Get your act together or you'll be the ones footing the bills." Like I said, that makes for one heck of a motivation. As far as NFC is concerned, the credit card companies don't face the pressure and could care less; they'll be just fine with Chips. So Google is in a bind. They can't make it too easy or they'll risk getting the bill for a breach.
[Nexus 5 Q&A, Help & Troubleshooting] dk_zero-cool:
Yes I am aware of that. But the API's has been trimmed down long before Pay was even an idea.

Also as you mentioned, Root and Xposed can do anything, which includes faking device information to trick apps into thinking that nothing has been altered. There is even a current Xposed Module that can bypass this new security check. It's like I said in the first comment, using device information as part of the security model is a very bad design. If you use Root, Xposed Framework, or you create your own ROM from the Android Source, you have the ability to change, add, manipulate any type of data that you wish. So collecting this data thinking that you can trust it, it's not very well thought out.

Let's take a simple example. Is it safe to check for the existence of the SU binary? Can this tell you with 100% certainty if the device is rooted or not? No it cannot. If you use any of the Java classes to do this check, a simple Xposed Module can intercept it and return any result that a user wishes. If you use native code to do the check, it's more difficult to intercept the direct check, but at some point the result will need to be handed of to the framework in order for applications to retrieve it via the API's, and at this location Xposed can still intercept it. It would also be possible for ROM's and Xposed to create a randomizing system that hides the binary under random names and intercepts and directs any calls to "su". This way you would be able to launch a root process but it would be impossible to check for the actual binary since you never know what it is called. There are many options, and these checks only irritates developers, but they can always be circumvented.
[Nexus 5 Q&A, Help & Troubleshooting] WhosAsking:
Perhaps that will mean NFC Android phones will go back to using Secure Elements the way NFC-enabled iPhones do. Maybe that's why jailbroken Apple Pay is tolerated; IIRC, not even root can tamper with that sensitive stuff without risking a permanent brick.
[Nexus 5 Q&A, Help & Troubleshooting] Joshmccullough:
Semi-related aside: wouldn't that be an interesting thing? ROM developers/teams submitting work to or linking with Google somehow in order to get 'verified', some sort of certification that their work meets certain standards that would let others know that the ROM they're looking at installing is trustworthy/high quality/secure/etc? I think your idea's kind of a cool one, both in the context of the Android Pay discussion we're all on but also just in general.
[Nexus 5 Q&A, Help & Troubleshooting] ajm786:
I think this would be almost optimal.

[MENTION=6957306]jasondclinton_google[/MENTION], you hear this? At the very least, CyanogenMod is the biggest, most well known custom ROM out there. I can't speak for other custom ROMs, but it might be a good idea to let them get CTS verification so that we can use Android Pay on our phones. How about it?
[Nexus 5 Q&A, Help & Troubleshooting] jasondclinton_google:
This idea was first mentioned in comment #70 on page 7 and I relayed the idea to the wider Android leadership then. I, personally, think it's a great idea but I can't speak for the Android project. From a security engineer perspective, I think the community should consider what entity owns the private keys, keeps them safe, and uses those private keys to stand behind its ROM before advancing this idea.
[Nexus 5 Q&A, Help & Troubleshooting] uudruid74:
And you can still root your phone and use the web to transfer money, no different.

Now, find a way to broadcast your credit card number via NFC, and remember I'm standing behind you inline with my phone turned on and listening for NFC transactions.

Taglines suck. https://eddon.systems

---------- Post added at 11:16 AM ---------- Previous post was at 11:12 AM ----------

Samsung Pay is not supposed to work on rooted devices. Do you actually know a rooted Sanding user using Samsung Pay, or are you going by hearsay?

Taglines suck. https://eddon.systems

---------- Post added at 11:19 AM ---------- Previous post was at 11:16 AM ----------

It only works if you have the latest model Samsung devices and there are other restrictions (US only, etc). If they want to license the technology (which they purchased - Google should have bought it IMHO), they might have a chance, but I'm not about to buy a Samsung phone just to use Samsung pay!

Taglines suck. https://eddon.systems
[Nexus 5 Q&A, Help & Troubleshooting] uudruid74:
Question: If I had an Android Watch, is there some way to put Android Pay on it and keep it unrooted and still root my phone?

Taglines suck. https://eddon.systems
[Nexus 5 Q&A, Help & Troubleshooting] techdog:
Thanks. That was a great response. I have been working in computer security for over 30 years and I couldn't agree more.
[Nexus 5 Q&A, Help & Troubleshooting] Entropy512:
I don't think any of the Android Wear devices have NFC. Or are you referring to some of those funky items like the Omate TrueSmart? Likely to fail SafetyNet checks...
[Nexus 5 Q&A, Help & Troubleshooting] uudruid74:
OnePlus has already done this and it wont help rooted devices. And if you can flash a new ROM ..... you basically have root! How does this help?

Taglines suck. https://eddon.systems
[Nexus 5 Q&A, Help & Troubleshooting] ajm786:
No, they haven't. OnePlus doesn't use CyanogenMod. CyanogenMod is different from OxygenOS, Cyanogen, or whatever it is they use.

---------- Post added at 04:04 PM ---------- Previous post was at 04:03 PM ----------

lol, this is almost an oxymoron. How would Google like it if we all bought Apple Watches JUST to use Apple Pay??? :p
[Nexus 5 Q&A, Help & Troubleshooting] uudruid74:
Oxygen has nothing to do with it. OnePlus uses CyanogenOS which is the same code base as CyanogenMod. There is almost no difference except for some pack-in apps.

However, you missed my point. If I can flash a new OS, would the banks be happy that the OS I flashed was signed by 'some guy on XDA forums'? And the approved releases could never be put out as fast as every change means going through the approval process again, and its all pointless if I can flash a new library over the top.

Taglines suck. https://eddon.systems
[Nexus 5 Q&A, Help & Troubleshooting] Robalboa:
They are expanding samsung pay compatibility to many devices and yes it works with stock Rooted devices.

So yes

And no you won't need a Samsung phone.

Sprint GS5 Moars 6.2
[Nexus 5 Q&A, Help & Troubleshooting] uudruid74:
According to digitaltrends, engadget, phonearena, phandroid, and sammobile you can not use Samsung pay on a rooted device. I have yet to see one source say otherwise, so I ask again, what is your source?

Samsung pay on other devices might be interesting, but I haven't seen any evidence of that either, and I'm guessing you'd need specific hardware support? It likely won't be available on MY device, ever. Android Pay could work as I have NFC.

Taglines suck. https://eddon.systems
[Nexus 5 Q&A, Help & Troubleshooting] shdwphnx:
So Android Pay is being blocked from rooted devices for "security reasons"? To the best of my knowledge, the biggest security threat on Android at this time is data stealing applications. The best defense against those data stealing applications that I know of is XPrivacy, which is only available on rooted devices. So how does making me vulnerable to data theft increase my security?
[Nexus 5 Q&A, Help & Troubleshooting] GatoL0c0:
Search SafetyNet as it's been talked about many times over.