That said: I question that services should stop working if I have the ability to grant root. Reasons:
1) Maybe I know what I'm doing (honestly .. I consider myself capable and still have cringe while writing this)
2) Your software isn't immediately compromised in its core functionality if _I_ own my _own_ device.
For Netflix, this feels like another failed attempt to close the analog hole. Android Pay and whatever else might try to be your wallet (I'm a huge fan, as you might notice in this thread) should be able to withstand that. Otherwise it's just a crappy payment system.
I can pay stuff from my PC (various operating systems) and I do have root (or the equivalent permissions). I also own - as I stated in my original post - a CC that allows me to spend money freely. I don't know how hard it would be to copy it physically, but you'd be able to strip the core details (name, number, CSC) in a couple seconds/with two pictures.
Why is the CC secure, but a rooted phone isn't. Ignore Netflix, they're brain-dead and content related DRM isn't what I'm going for. I'm asking why random legitimate services refuse to work on a phone, because .. the owner actually seems to own the device?
Stethoscope has nothing to do with user's of Netflix's service, and the DRM on it. This is for Netflix employees, on IT managed smartphones. This could have just as easily come from any of a number of other companies that issue phones to employees.
The scope of risks are so significantly larger than the traditional "people who can place their hands on your wallet, or read the number while you have it in the open"...
My example kinda covers this, phones really are getting faster... It's no longer a case of "I know what I'm doing" when it now comes down to human recognition and reaction time. In other words, you clicked allow before your brain had time to stop you. How do you prevent this?
> 2) Your software isn't immediately compromised in its core functionality if _I_ own my _own_ device.
100% agreed. For the Google Pay example, fair enough. It's your credit cards, and it's harder to come up with a counter point.. For the OP / Netfix example, it's not your data, and likely not your device - or - by connecting to company services, you've basically agreed it's not yours (This could be a whole sidetrack on it's own! :))
> Android Pay and whatever else might try to be your wallet (I'm a huge fan, as you might notice in this thread) should be able to withstand that. Otherwise it's just a crappy payment system.
Credit card companies are generally responsible for theft of money where you remained in possession of your card at all times. Sure, they really hate admitting it, and gathering the proof is hard, many times impossible. But that doesn't change the responsible party when the proof is found.. Given this, it's easier for them to accept less secure alternatives (e.g. the US's reliance on signatures).
The rise of NFC credit cards has changed this somewhat, if a credit card hands out all the details needed to make a purchase to anyone who bumps into you on the street, possession is now not the only factor, and banks have built safeguards around this (e.g. max transaction size, max NFC transactions before being required to enter your PIN).
Google with Android Pay must prevent that same bump on the street from stealing their customers money. The cell phone payment version of this comes in the form of other apps on the device, hackers breaking into the phone remotely, etc. With a rooted device, or a device using unknown firmware[1], all bets are off.
> I can pay stuff from my PC (various operating systems) and I do have root (or the equivalent permissions).
And this is a security hole, granted it's one I wouldn't want to see shutdown, but it's still security hole. I don't have any good answers here, but I do look forward to seeing a solution that works while letting me keep root access on my Linux box!
> Why is the CC secure, but a rooted phone isn't.
I'm think I've mostly covered this, but you're looking at two totally different landscapes. They just cant be compared in the same way.
> Ignore Netflix, they're brain-dead and content related DRM isn't what I'm going for.
While I'm no DRM fan, this entire article is about Netflix's corporate employee device security, it's nothing to do with DRM or content..
[1]: Unknown firmware in this case means firmware google doesn't trust - unrooted AOSP built from a unknown manufacturer can't be trusted any more than rooted firmware from Google itself.
If this really is a problem, the OS could pop up a question such as "This app is requesting escalated privileges", and then wait ten seconds before popping up the allow/deny buttons so the user doesn't click blindly.
The simple solution to this specifically (which I think has been implemented already anyway for some Android rooting options?) is to have a few seconds of delay where the "Allow" button on the root permission request is greyed out.
Re adding a delay to counter this, see my other reply here https://news.ycombinator.com/item?id=13701227 - a delay isn't enough..
The best SU apps have a timeout on the popup specifically to prevent this. I specifically use phh superuser (or, rather, MagiskSU) which has a 2 or 3 second timer from when the popup shows up till you can press accept.
I was drawing parallels between hostile NFC readers and hostile apps/hackers :)
"hackers/hostile apps can do evil things on desktop" is nearly identical to "hackers/hostile apps can do evil things on phone"
So while in a vacuum you could argue that you need to protect against hostile apps the same way you protect against hostile NFC, it's a weak comparison. While the treatment of hostile apps on your heavier home computing device is a super strong comparison.
Example: CVV numbers, these are needed for "Card not present" transactions are must not be saved (e.g. no browser will save them). Using your phone for an NFC payment on the other hand does not need this number.
Yes, this is a tiny detail. But this detail entirely changes the share of responsibility between the consumer/merchant/payment processor/bank.. This is usually reflected in the different fees that are charged for different types of transactions, card swipe vs card not present vs Chip+PIN vs NFC.
Assuming that just because a CC number + errata stored on a PC can be stolen an abused, that the banks etc should just let me do that on e.g. Android Pay is just wrong..
Nobody is stopping you from creating a text file on your phone with the card and CVV numbers, but don't expect to be able to use that text file as a NFC payment method!
Edit: in case I wasn't clear (I know I wasn't, because I kinda forgot to say it ;)), once your phone is untrusted - as in untrusted by the bank etc - everything stored on it may as well be that plain text file as far as they are concerned.
I would consider this a software fault. Your SuperSU-or-equivalent app should do something similar to what Firefox does for downloads (the button is greyed out for a few seconds before you can click it).
But - they don't currently do this, and there's no way that I can think of to reliably, as a third party, validate SuperSU etc is actually doing this.
EDIT: Also, some users really are.. ill informed and gullible. I hate saying it, but a large number of employees even at a tech company will click accept after a quick popup that says "For best 3D performance, we need root access to use your phones graphics chip directly".
The app is also on the Play Store, but the adblocking features are only in the Github version (presumably Google will not approve this functionality for Play Store apps).
Google will likely never do this :(
This really has nothing to do with services not working because root is enabled, instead it has everything to do with companies (Netflix in this case, or Google for Android Pay in your example) preventing widespread theft of employee/customer data.
Even the most cautious users can accidentally click "allow" by mistake. Here's a example of how that might happen:
Build an app that some user wants - maybe a game. Make the user click a "Start" button to play. Time how long between presenting the button and receiving the click, after a few rounds of this, wait a fraction of a second less than the average time and trigger the sudo call which in turn usually triggers an allow/deny popup.
Did it register with you in time, or did you click allow? Did you even notice it if the game starts anyway? Probably not! Netflix just gave an attacker an entry point, and Google just lost the confidence of their banking partners, who are likely looking for any excuse to avoid working with Google (and Apple etc) anyway.
A good IT department has to protect the company from risks like this, and nothing the company requires you to do will require root (There are obviously exceptions, but the number of employees worldwide who fit this bill, outside of phone OS development, is likely less than a 5 or 6 figure number).
If you need root for personal tasks, and the company isn't happy with root, then they are entirely within their right to deny that device access to company systems.