Cool! Thanks again for all the clarity you've provided. It's been a refreshing experience to get some insight from someone on the inside.
Android Pay and Custom ROM
- Thread starter luigidk
- Start date
- Status
Cool! Thanks again for all the clarity you've provided. It's been a refreshing experience to get some insight from someone on the inside.
What about Marshmallow, then?
Will we able to install the old Google Wallet on Marshmallow, and retain our functionality?
I'm glad you responded -- but this just tells me "stick with the old Wallet".
Also, maybe you can actually make this heard -- give us the ability to spend from our Wallet balance first again! I'll probably go unrooted on the Nexus 5X when it comes out, but Android Pay is inferior to Wallet in that respect, too.
---------- Post added at 03:29 PM ---------- Previous post was at 03:24 PM ----------
Not much support, is it? "Exactly as before, no new feature improvements, only bugfixes".
Done. I'd be SO much happier.
Will we able to install the old Google Wallet on Marshmallow, and retain our functionality?
I'm glad you responded -- but this just tells me "stick with the old Wallet".
Also, maybe you can actually make this heard -- give us the ability to spend from our Wallet balance first again! I'll probably go unrooted on the Nexus 5X when it comes out, but Android Pay is inferior to Wallet in that respect, too.
---------- Post added at 03:29 PM ---------- Previous post was at 03:24 PM ----------
Not much support, is it? "Exactly as before, no new feature improvements, only bugfixes".
Done. I'd be SO much happier.
Thank you for taking the time to provide us with info about Google pay.
Does the safetynet api use any of the "trustzone secure world" capabilities during check? Because if its not, isn't the produced checksum spoofable?
I'm very interested to know in what extend android utilizes trustzone in general (Android, not the proprietary Knox). Not allot of documentation around this.
Last edited:
lol thats another ongoing battle. I would say that its off topic and doesnt pertain to this but it does. Root is absolute a must for many of us because mistakes Google themselves made @robrob777 makes a very valid point.
These apps are a must to help with battery life and data.
Greenify - Should be a system option built in to let us keep apps at bay and from just running for no reason
Amplify - Limit them wakelocks caused by google. Like location service we need but not so much
AdblockPlus - Adds can be horrendous. I dont have data or battery to spare. Yes I pay for plenty APPs. Honestly Ive at least spend $150 on various apps, I support developers.
Service Disabler - Again Google fault that we have to stop Google Play Services from draining battery.
Viper4Android - Not Google fault but lets be honest, once U have it, 1 can never not have it.
Cerebus - Adds security for example. *I dont use it but many use it and similar apps.
AppsOps - It and its many variations add security
Firewalls - Again security
These are essential to Root Users who are basicly android users with knowledge.
So now we being told we put our info at risk, so we have to run stock. Yet stock roms are by far the most Insecure out there. Tell me this, why arent U blocking Touchwiz, Sense and Ect. ALL OEMs are behind in security, bugs, vulnerabilities and glitchs. Only Google Nexus Devices are kept up in real time. Oh wait, Nightly builds are kept secure too and many times faster at finding them.
II noticed play services draining my battery more after I upgraded and activated Android Pay. I am rooted.
After all this discussion and clarification from Google, it's my best guess that something within Google Play Services is running the root check here.
I am hopeful that by uninstalling Wallet and AndroidPay that this will stop the battery drain issues.
Oh well, I will get by without using my phone with Android Pay. I won't give up root any time soon.
This is the main argument I've been saying for years! I just don't understand why all the customization that root provides is not already built into the Android OS. More specifically - full app+data backup, detailed battery/wakelock stats, and UI customization. These are basic things that we the user should have access to without having to get superuser privileges! But unfortunately, we have to rely on root for these things, and now it sounds like I can never use Android Pay. It's really a shame.
Abbreviating both posts, but @Woody and @jasondclinton_google are saying very similar things, both of which I happen to agree with, despite being the one to develop RootCloak.
There's a balance between security and usability. It's the same reason that a standard linux distro doesn't really support running as root; a tenant of good security design and opsec is principle of least privilege. However, when we're talking about hundreds of millions of dollars in financial liability, security is the #1 priority. The attempt that Google is making at guaranteeing some degree of security and isolation is a huge part of what makes it possible for banks to sign up while still complying with regulations, and avoid passing risk mitigation charges down to cardholders. Ultimately, a financial risk/burden to banks is also a financial risk/burden to consumers.
Xposed + RootCloak is a fantastic example of the power and risks of rooting your device. For any application you choose, you are quite literally overriding fundamental methods used in Java, such as the File constructor. If you really sit down and think about it, it has the same characteristics as a rootkit: An exploit was used to gain higher privilege on the system, and then a module is used to hide any trace of that higher privilege. While RootCloak is working on behalf of the phone's user, what if the same techniques are applied to thousands of devices? Having a rooted device truly requires the user to be extremely diligent, and is part of why you have to be crazy to let an app use root that isn't vetted by any kind of community or open source.
I love the idea of an open dialog and the search for an ideal balance. Someone suggested a page or two back the idea of a power user, which has the ability to exceed normal privilege, but not interfere with the system itself. Many possible avenues, and with the vibrant community and the great people at Google, the best approach is just to take one step at a time.
Also, if you're curious why I personally prioritize security, even while developing something like RootCloak, you need to understand how subversive software can be. Check out http://www.underhanded-c.org/.
There's a balance between security and usability. It's the same reason that a standard linux distro doesn't really support running as root; a tenant of good security design and opsec is principle of least privilege. However, when we're talking about hundreds of millions of dollars in financial liability, security is the #1 priority. The attempt that Google is making at guaranteeing some degree of security and isolation is a huge part of what makes it possible for banks to sign up while still complying with regulations, and avoid passing risk mitigation charges down to cardholders. Ultimately, a financial risk/burden to banks is also a financial risk/burden to consumers.
Xposed + RootCloak is a fantastic example of the power and risks of rooting your device. For any application you choose, you are quite literally overriding fundamental methods used in Java, such as the File constructor. If you really sit down and think about it, it has the same characteristics as a rootkit: An exploit was used to gain higher privilege on the system, and then a module is used to hide any trace of that higher privilege. While RootCloak is working on behalf of the phone's user, what if the same techniques are applied to thousands of devices? Having a rooted device truly requires the user to be extremely diligent, and is part of why you have to be crazy to let an app use root that isn't vetted by any kind of community or open source.
I love the idea of an open dialog and the search for an ideal balance. Someone suggested a page or two back the idea of a power user, which has the ability to exceed normal privilege, but not interfere with the system itself. Many possible avenues, and with the vibrant community and the great people at Google, the best approach is just to take one step at a time.
Also, if you're curious why I personally prioritize security, even while developing something like RootCloak, you need to understand how subversive software can be. Check out http://www.underhanded-c.org/.
Ill say this bluntly and this is a strong statement that cant be simply overlooked. Most, if not all recent Community built roms are more secure than the devices stock rom provided by the OEM. In order to gain root, most devices need an exploit in the first place. Ure concerns are NOT security in my eyes. It feels more so like control and/or covering your own back if mistakes happen (to blame the OEM). If it was security, then it should work on custom roms that dont have SuperUser (root) privileges. Yes, many Roms dont come with Root and these Roms are more secure than OEMs stock. But U arent just checking for root, your forcing stock everything. Whats to stop the same malicious software U talking about from just using the exploit left behind by OEMs slower pace. Not hard to build it for the S4-S6 that covers a lot of Android. Stagefreight is an example of that and many devices are still vulnerable.
If anything, be more proactive. Instead of checking if the system been altered, check if the system vulnerable to common exploits.
If anything, be more proactive. Instead of checking if the system been altered, check if the system vulnerable to common exploits.
I haven't read the whole thread here, but there is some concern about secure datastore?? Please enlighten me as to what exactly is being stored on the device? And exactly how is the bank taking any risk? I think storing my card on my rooted phone is more secure than being stored in my physical wallet.
I mean, we've read the fluff about security, but it seems more like 'official' wording from Google execs rather than the technical discussion we would hope from a fellow developer.
---------- Post added at 10:24 PM ---------- Previous post was at 10:04 PM ----------
Good point on backups, but I also think removal of useless 'system' apps should also be on that list. How many people have useless and/or obsolete apps taking up space and running background services ? This is obviously a security issue! A particular one that was replaced by Google Wallet comes to mind, but it can't be replaced. Forcing people to have useless crap on their phone makes no sense unless that crap is downloading ads or spying on the user. Having root doesn't make my phone insecure, it allows me to manage my own security rather than the cellular providers, who have no interest in respecting my privacy or reducing my bandwidth usage.
---------- Post added at 10:34 PM ---------- Previous post was at 10:24 PM ----------
Because the door is made of paper, you look like a fool putting a lock on it.
I think there is some other reason for the no-root rule. This smells like the DVD-CCA implementation of CSS. Supposedly to prevent counterfitting, but it didn't stop that. It was about forcing people to watch commercials. I hate advertising and I'm tired of it being shoved down my throat everywhere I turn. If marketing didn't spend billions on ads, they could lower prices.
Watch, we'll find out soon what the real reason is.
I mean, we've read the fluff about security, but it seems more like 'official' wording from Google execs rather than the technical discussion we would hope from a fellow developer.
---------- Post added at 10:24 PM ---------- Previous post was at 10:04 PM ----------
Good point on backups, but I also think removal of useless 'system' apps should also be on that list. How many people have useless and/or obsolete apps taking up space and running background services ? This is obviously a security issue! A particular one that was replaced by Google Wallet comes to mind, but it can't be replaced. Forcing people to have useless crap on their phone makes no sense unless that crap is downloading ads or spying on the user. Having root doesn't make my phone insecure, it allows me to manage my own security rather than the cellular providers, who have no interest in respecting my privacy or reducing my bandwidth usage.
---------- Post added at 10:34 PM ---------- Previous post was at 10:24 PM ----------
Because the door is made of paper, you look like a fool putting a lock on it.
I think there is some other reason for the no-root rule. This smells like the DVD-CCA implementation of CSS. Supposedly to prevent counterfitting, but it didn't stop that. It was about forcing people to watch commercials. I hate advertising and I'm tired of it being shoved down my throat everywhere I turn. If marketing didn't spend billions on ads, they could lower prices.
Watch, we'll find out soon what the real reason is.
Sensitive data off the device?
Jason, thank you for coming here to explain what is going on!
Since I'm extremely disappointed that Pay is not working on rooted devices by design and since you've asked for constructive ideas to resolve this issue, I am trying to understand the reason for this restriction.
If I understand correctly from your replies quoted above, Pay is designed to store the actual card numbers in a datastore on the device and is exchanging them for a token on demand. Unlike Wallet that was storing a virtual card number, which seemed to work fine from security point of view for rooted devices
I'm not sure about the risk model differences between storing virtual card numbers and actual card numbers in a datastore on the device, and why would one need much greater security model than the other? The end result of stealing either card# (virtual or actual) from the datastore by root access would be unauthorized transaction. Granted, google has better control of the virtual card and could block suspicious transactions.
When Wallet was processing a transaction, I assume it gave the terminal the virtual card# and then went to google's servers and charged the actual card based on the actual info stored there. Undoubtedly, google's payment servers are more secure and better monitored than any end-user device. In that case, why wouldn't Pay app do similar thing -- keep the actual card info on google's servers like today and ask for a tokenized# from the server to provide to the terminal? At this point, both Pay and the server can do risk analysis on the specific transaction and decide whether to approve the request for a token or not. This way no sensitive data is stored on the device.
By removing the sensitive data from the user's device to a controlled and monitored environment, I assume you can relax the security model and go back to similar logic the Wallet app had with app-level authentication.
Looking forward to using Pay on my rooted devices knowing my actual card info is secured by you on google's servers!
Jason, thank you for coming here to explain what is going on!
Since I'm extremely disappointed that Pay is not working on rooted devices by design and since you've asked for constructive ideas to resolve this issue, I am trying to understand the reason for this restriction.
If I understand correctly from your replies quoted above, Pay is designed to store the actual card numbers in a datastore on the device and is exchanging them for a token on demand. Unlike Wallet that was storing a virtual card number, which seemed to work fine from security point of view for rooted devices
I'm not sure about the risk model differences between storing virtual card numbers and actual card numbers in a datastore on the device, and why would one need much greater security model than the other? The end result of stealing either card# (virtual or actual) from the datastore by root access would be unauthorized transaction. Granted, google has better control of the virtual card and could block suspicious transactions.
When Wallet was processing a transaction, I assume it gave the terminal the virtual card# and then went to google's servers and charged the actual card based on the actual info stored there. Undoubtedly, google's payment servers are more secure and better monitored than any end-user device. In that case, why wouldn't Pay app do similar thing -- keep the actual card info on google's servers like today and ask for a tokenized# from the server to provide to the terminal? At this point, both Pay and the server can do risk analysis on the specific transaction and decide whether to approve the request for a token or not. This way no sensitive data is stored on the device.
By removing the sensitive data from the user's device to a controlled and monitored environment, I assume you can relax the security model and go back to similar logic the Wallet app had with app-level authentication.
Looking forward to using Pay on my rooted devices knowing my actual card info is secured by you on google's servers!
Perhaps Google ought to use the power of the internet and develop a way to use the app itself as a linchpin on which the transaction turns: the authentication and processing takes place on a server, like the web browsing optimization, and then the internet transmits a payment token to the app, that transmits the information to the NFC reader to pay for my damned Diet Coke. Avoid doing all this on the phone, period, and whether I root or not, simply doesn't matter.
Without being able to use root, I won't use NFC payments anymore. There is evidently no one who will do things the way the old Wallet worked. I am disappointed. I liked using NFC but I won't give up root. I have to have root because I need to flash a kernel that doesn't heat up the Nexus 6 and allows for some kind of power management since unrooted I cannot reach all the data that will help me to know what is going on. I need root so I am able to use the notification light on the Nexus 6 that Google didn't tell us about, or so that I can change the heartbeat to receive messages from Hangouts easier, or everything else that makes it worth the root. I feel like Google doesn't really bother to talk to people and communicate or ask for anything, they don't have to any more. I am still a little sore about Glass so this doesn't help. Plus who thought it was a good idea to use Snapdragon 810 in the Nexus 6P? Probably will skip the next Nexus because they wouldn't choose to wait for the 820....
Thanks for asking, if nothing else. Nice to actually see someone at Google actually try to communicate with users, on any level.
Without being able to use root, I won't use NFC payments anymore. There is evidently no one who will do things the way the old Wallet worked. I am disappointed. I liked using NFC but I won't give up root. I have to have root because I need to flash a kernel that doesn't heat up the Nexus 6 and allows for some kind of power management since unrooted I cannot reach all the data that will help me to know what is going on. I need root so I am able to use the notification light on the Nexus 6 that Google didn't tell us about, or so that I can change the heartbeat to receive messages from Hangouts easier, or everything else that makes it worth the root. I feel like Google doesn't really bother to talk to people and communicate or ask for anything, they don't have to any more. I am still a little sore about Glass so this doesn't help. Plus who thought it was a good idea to use Snapdragon 810 in the Nexus 6P? Probably will skip the next Nexus because they wouldn't choose to wait for the 820....
Thanks for asking, if nothing else. Nice to actually see someone at Google actually try to communicate with users, on any level.
Last edited:
Stryke_the_Orc
Retired Senior Moderator
I don't understand all the feelings of betrayal here, honestly. What Google is doing by securing their payments is for your benefit.
Sure, you could rootcloak the app, but how many other apps are on your device, and do you know what permissions each of them is granted? What specifically they are asking to access? The explanation of permissions is far too vague IMO. (Mr. Security Engineer, you wanted am idea, here you go. Elaborate on the permissions. Like why the Subway app wants access to take photos and video (there's not a need for this), or what contents exactly is it reading, writing or deleting from my SD Card?)
Add to that the fact that rooting your devices has become a fad now so everyone "can haz kewl fones". We have people rooting that don't even understand what it is, what it does, or how it works. Taking that into consideration and add in allowing Android Pay to function on a rooted device is a recipe for disaster.
You want a disclaimer? How about the one that is in almost every OP on this site?
You have accepted the terms of use from Google when you activated your device, those terms only offer any protection while using OEM firmware, by flashing any modification you have given up any rights/claims to Google services and products. While it's great that Google pays attention to this community and user base, we need to be mindful that we are a miniscule percentage of the overall and that the bottom line is that Android is a business with millions of users data in the mix.
The great thing about this platform is that you have choices. So what if Google is protecting themselves by not allowing rooted devices to use this API? There are other apps that will, or maybe, you could just use a damn card. I mean really, how much harder is it to pull out a card and swipe it?
Guess what I'm driving at here is that Google, as a company, is taking steps to protect you, sometimes even from yourselves. Could be worse, so if you're even able to root your device, count yourselves lucky because others aren't so fortunate.
JM2C anyway...
Sure, you could rootcloak the app, but how many other apps are on your device, and do you know what permissions each of them is granted? What specifically they are asking to access? The explanation of permissions is far too vague IMO. (Mr. Security Engineer, you wanted am idea, here you go. Elaborate on the permissions. Like why the Subway app wants access to take photos and video (there's not a need for this), or what contents exactly is it reading, writing or deleting from my SD Card?)
Add to that the fact that rooting your devices has become a fad now so everyone "can haz kewl fones". We have people rooting that don't even understand what it is, what it does, or how it works. Taking that into consideration and add in allowing Android Pay to function on a rooted device is a recipe for disaster.
You want a disclaimer? How about the one that is in almost every OP on this site?
Code:
[COLOR="Red"][B][I][U]WARNING: Flashing anything on your device is done at your own risk. There is no way myself or any other developer can guarantee that flashing this ROM or any other file will not brick your device or otherwise cause some other type of damage. This is just a standard warning. I am not responsible for anything that you do to your device.[/U][/I][/B][/COLOR]You have accepted the terms of use from Google when you activated your device, those terms only offer any protection while using OEM firmware, by flashing any modification you have given up any rights/claims to Google services and products. While it's great that Google pays attention to this community and user base, we need to be mindful that we are a miniscule percentage of the overall and that the bottom line is that Android is a business with millions of users data in the mix.
The great thing about this platform is that you have choices. So what if Google is protecting themselves by not allowing rooted devices to use this API? There are other apps that will, or maybe, you could just use a damn card. I mean really, how much harder is it to pull out a card and swipe it?
Guess what I'm driving at here is that Google, as a company, is taking steps to protect you, sometimes even from yourselves. Could be worse, so if you're even able to root your device, count yourselves lucky because others aren't so fortunate.
JM2C anyway...
I can understand Google wanting to protect the users....but Android without root is simply not a world I want to live in currently...
I love vanilla android..but at the same time there is a lot of simple things that are extremely useful that have existed in the community for years now that simply does not exist in vanilla android. Hell if google gave native support for even RRO I would be a lot happier.
I wish google would start looking at the community more and find out what the most popular custom features the users are using and implement them natively in android.
The first being getting of that unbearable white background everywhere.
Ultimately if I have to choose between android pay and root....I don't see a future where I would choose android pay...
I love vanilla android..but at the same time there is a lot of simple things that are extremely useful that have existed in the community for years now that simply does not exist in vanilla android. Hell if google gave native support for even RRO I would be a lot happier.
I wish google would start looking at the community more and find out what the most popular custom features the users are using and implement them natively in android.
The first being getting of that unbearable white background everywhere.
Ultimately if I have to choose between android pay and root....I don't see a future where I would choose android pay...
It's been awfully confusing since the split to New Wallet and Android Pay on a rooted Nexus 6. Still works fine at McDonalds, but gags at Walgreens and Blue Bottle (Square). If Android Pay won't accept rooted phones, then why should it install quietly and successfully? Why should it still work at some venues and stop working with others. I used old Wallet just long enough to really like it.
Bottom line for me: if I can't do all this cool stuff with a rooted Android phone, then the difference between vanilla Android and iOS starts to shrink for me. A lot.
Bottom line for me: if I can't do all this cool stuff with a rooted Android phone, then the difference between vanilla Android and iOS starts to shrink for me. A lot.
So in other words, if someone was to pull down AOSP, generate their own signing keys and build a "user" build for, say, the Nexus 5 (and bunde all the necessary proprietary blobs) and then flash that on the device, it would still not be "good enough" according to SafetyNet (even if the bootloader was locked afterwards)? In that case, saying that the only blocker is the need to pass CTS would be incorrect, wouldn't it? As far as I know, such a build would pass all the actual CTS tests.At the moment, any non-official build will not pass SafetyNet because the system image signature isn't what was expected
So, we start with the CTS status inferred by a production image signature and then go about looking for things that don't look right. This community has identified quite a few of the things that we are looking at, already: presence of 'su', for example.
Maybe a Googler can sum up what a user can do and (s)he would be able to use Android Pay.
So far we know we can root device, remove bloatware and unroot device and Android Pay will work.
What about Xposed framework? We can use it without root. Is it blacklisted? Because there are many very useful mods which fix Android bugs, improves Android experience, solves most "WontFix" Android problems
Can we edit build.prop file? People should know what things trigger "uncompatible Android Pay".
If somebody builds AOSP build e.g. for Nexus 6, Android Pay will not work on such build, yes? Or just Build constants must match stock " Google Anddoid constants?
Can we backup OEM Keystore and place it to our AOSP build to pass check?
So far we know we can root device, remove bloatware and unroot device and Android Pay will work.
What about Xposed framework? We can use it without root. Is it blacklisted? Because there are many very useful mods which fix Android bugs, improves Android experience, solves most "WontFix" Android problems
Can we edit build.prop file? People should know what things trigger "uncompatible Android Pay".
If somebody builds AOSP build e.g. for Nexus 6, Android Pay will not work on such build, yes? Or just Build constants must match stock " Google Anddoid constants?
Can we backup OEM Keystore and place it to our AOSP build to pass check?
Last edited:
Thank you Jason for taking the time and explain the reason behind the security model in Android Pay. Now that I know I cannot add a card while running a custom ROM with root, how do I remove the card that I scanned in from Android Pay? It's not on my Wallet account but shown in Android Pay on my device when I click the add button.
Sent from my Nexus 5 using Tapatalk
I think part of it, like I said before, has to do with new PCI rules going into effect in October. The reason this is important is because Google could be held financially liable for stolen card information under these new rules unless Google demonstrates a high degree of attestation to ensure the payment instrument (in this case, the phone) is secure from end to end. That's one reason for the push to Chip cards. The way Android Pay is supposed to work is closer to how a Chip card works using tokenization.
If Google wants to satisfy BOTH the power users AND the PCI, someone needs to come up with a way to ensure a secure program within an insecure (meaning rooted or custom) environment. Last I checked, this is a hard problem in security being seriously examined by some of the biggest minds in the industry as a similar situation occurs on the Internet today (trying to ensure secure communications on an insecure medium, especially during the critical "first contact" phase where the two parties don't know each other yet).
How about a proposal? Today's Android has the capability to store security certificates. Now, most of us don't use this ability; it's usually for high-security enterprise environments, but perhaps something of the sort could be developed as an identity certificate that's unique between the Google user, the phone, and Google itself. Let's say if you want to secure one's identity on an Android phone, Google may send you (out of band) some kind of one-time token that can be input into the phone (how about a small NFC tag mailed to you), then you input some ways to verify your account to Google, then everything's put together into a certificate unique to the phone that says, "OK, we vouch for this phone and this user." And then Android Pay can secure itself against this certificate. This would not preclude a device with multiple users (since the certificate is unique per user) or multiple devices (though each one would have to be vouched separately). It should also be possible to perform backups of our system, so long as we don't change it (which would require a new authentication); this is one reason I prefer rooting: to install custom recoveries that allow me to back up. I can speak from experience that it's saved me several times from very strange crashes and reboots.
Now, I may be missing a trick or some issue here. If I am, spell it out and we can discuss the matter further. But what do you think? Some form of remote authentication predicated on a single user and system configuration that can be checked at both ends before establishing trust?
Last edited:
With chips on every card in the world now who in their right mind would bother with either Android Pay or Apple Pay? It's a silly gimmick that only power users might even attempt yet power users are locked out. Package it up and throw it away, it has become a bad joke. And an insecure one at that. There is going to be a way to get it to work via some kind of scheme (read root cloaker) and then everything will be compromised and the stock price will drop because of liability issues. Save yourselves the trouble and ditch this awful idea. Besides the fact that when you try to use it and it doesn't work 80% of the time and people behind you on line think you're a jerk because you had to pull out your wallet anyway... well I rest my case.
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
149
Hey Josh,
Android users who root their devices are among our most ardent fans and when this group speaks, we listen. A few of us around Google have been listening to threads like this one and we know that you're disappointed in us. I'm a security engineer who works on Android Pay and so this thread struck me particularly hard. I wanted to reach out to you all and tell you that we hear you.
Google is absolutely committed to keeping Android open and that means encouraging developer builds. While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact.
That "ensuring" is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and--by proxy--real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite--which includes checks for the security model.
The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases. I know that many of you are experts and power users but it is important to note that we don’t really have a good way to articulate the security nuances of a particular developer device to the entire payments ecosystem or to determine whether you personally might have taken particular countermeasures against attacks--indeed many would not have.
Let's keep the dialogue open: I'll be monitoring this and other threads for constructive ideas. I won't be able to reply to all messages but we will keep listening. We love our community and we want you to keep challenging us.30This thread is so embarrassing. We had the chance to work with Google, instead people decided to have a pissing match and use this thread as a forum to vent their frustrations with the "limited" ability of root. Then many go on to site their experience in the Linux or security research community only to provide credibility to their opinion....
All while no one actually tried to discuss how the security checks take place, what they do, and why they fail, what widevine is, how oemcrypto works to check system properties, or even how through all of this a scm call is made in secure context to the trustzone.
Also these petty differences on semantics just make us look like more of a idiotic crowd. I know I can't request for a thread to be closed, but if I had one "close this thread because it's embarrassing" card, this thread would hands down be what I'd use it for.2321
I don't want to falsely get your hopes up, so to be completely honest: I don't know of any way to currently or in the near future make an assertion that a particular app's datastore is secure on a non-CTS compatible device. As such, for now, the answer is "no". I could speculate about the future but I'm just one engineer.
I think what you are asking for is a "power user" bit that we would pass along when you set up Android Pay with a card. Something like, "I'm an Android Pay user who understands the risks but I want to root anyway." I think that this would be too hard to build a risk model for: every financial institution in the world would need to build a risk model that incorporates this signal and weigh it against all of the other signals that go in to approving or declining a transaction.
I can't speak for Google but I think that the virtual card didn't work particularly well for my use-case: I didn't get the full name of the merchant on my credit card statements and I didn't get all of the reward points that I was supposed to be getting. I also found chargebacks to challenging. With tokenization--which I've been using for months--my relationship with my credit card company is much better.
Yea, I don't blame you: I completely understand that you are disappointed. I wish that you could get the benefits of rooting without the root.
---------- Post added at 09:45 PM ---------- Previous post was at 09:41 PM ----------
Wow, never expected this
I greatly appreciate the response, like the commenter above, if I had to make a choice between having a rooted phone that I can make my own and being able to use Android Pay, the rooted phone would win out. However, I'm hopeful that the security concerns of moving money using phones and customers' ability to use their phones as they see fit can co-exist.
I'm glad to see that Google's taking active steps to see what the power user/dev community is doing and thinks about advances in Android and its various related applications. Thanks for reaching out to us, it's a cool thing, and make sure to say hi to Eric/Sergei/Larry/et. al. for me
Glad to reach out and completely understand why you find root valuable.
Actually, I'm just a lowly engineer so I think you're about as likely as I am to ever casually say hello to the founders.18
So what does that mean though? You're still open the possibility of allowing Android Pay to work on a rooted device?
I understand that rooting my device makes me more vulnerable, though I feel the the benefits outweigh the risks. I also know that when I choose to root my device I'm taking the responsibility upon myself to ensure that my phone remains secure. If there were some sort of breech, I would have no one to blame but myself. Could a disclaimer of some sort be added into the user agreement? Something that makes it clear that users with rooted devices are taking all the liability upon themselves?
Frankly, I just don't understand the reason for changing the model. I have been an avid user of Google Wallet for several years. I love the tech. Why make the change to tokenization? I understand that it's more of a standard and more secure. But the virtual cards seemed to work just fine. I've never had an issue with them. Better yet, why not let the user choose whether or not they use the tokens.
Simply put, rooting is more important to me. So if that means forfeiting the ability to use Android Pay, so be it. I just don't see why it has to be that way.
