As another reply to your post says, paraphrased, allowing applications to escalate privileges is absolutely less secure than not allowing applications to escalate privileges.

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.

Listen, I'm with you. Root is special and granting root to ~stuff~ should be something you don't do on a whim.

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?

> failed attempt to close the analog hole

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 only argument I would make against your points 1 & 2 is that I as a developer can't assume that a person with a rooted device knows what they are doing. For instance... I have a number of friends that have purchased rooted devices for the sake of using things like Kodi, against my advice. They do not understand their devices, or why downloading movies that hit the theater that day is illegal b/c they legally downloaded Kodi or bought a Kodi device legally. I am constantly having to fix/wipe them because they dont even understand the basics of security, ( i.e. they click ok on every popup without reading them, etc). Fortunately they pay me as I have refused for many years now to give free support, even to family. Anyhow, whenever my friends buy phones and other media devices, they almost always without fail and without asking my advice, purchase rooted ones online. Hell, for all they know, those devices could have software on them specifically for keylogging, etc.. and they would never know. So yeah, you can't assume a rooted device is in the possession of a competent user.

May have nothing to do with it but paying with CC details pretty much always has some traceable chain to the person who is gaining from the fraudulent activity. Contactless payment does not. Therefore a contactless scam could yield higher gains with lower risk than traditional cc fraud, and this poses a huge risk to any payment providers.

I'd tend to somewhat agree, but differ in what I think the big risk is - your cell phone has an internet connection, and a hacker in $foreignCountry can get to it..

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

Agreed - I said the same elsewhere on this thread

> 1) Maybe I know what I'm doing (honestly .. I consider myself capable and still have cringe while writing this)

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.

> 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?

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.

> In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

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.

I can no longer reply any deeper on this thread, must have tripped a reply limit :) Time for bed right after this!

Re adding a delay to counter this, see my other reply here https://news.ycombinator.com/item?id=13701227 - a delay isn't enough..

> In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

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 don't see how protection from hostile NFC and protection from rogue applications are related. You want both, ideally, but the increased difficulty of solving problem 1 on a phone vs. desktop does not make it harder to solve problem 2 on a phone vs. desktop. So I think you're wrong to say that it's "two totally different landscapes".

Ah, I was suggesting that comparing "I have a CC in my wallet and can do stupid things with it" to "I have a CC on my phone now others (hackers, bad apps) do can evil things with it" are two totally different things.

I was drawing parallels between hostile NFC readers and hostile apps/hackers :)

But the more important comparison in those posts is not CC in wallet. It's that CC on desktop computer has no restrictions.

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

I'm not sure I agree it's a weak comparison, mostly because I think we've made a whole bunch of bad decisions in how we handle things on a PC.. The PC was born in a different era to the smartphone, and it's treated as such.

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.

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

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

Absolutely, 100% agree. I'd go further, and require a password or pin too.

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

My main reason, or probably only reason to root my devices is to populate the hosts file with anti-advertising entries. Which may be safer than a device that is exposed to all the advertising crap.

You can do this with an on-device VPN, which doesn't require root: https://github.com/M66B/NetGuard/blob/master/ADBLOCKING.md

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

And this is one of the few reasons I envy iOS users, Apple shipped ad-blocking APIs of some kind (or did that actually come out yet/ever?)

Google will likely never do this :(

Services like Android Pay quite reasonably elect to not work if the device appears like it may have been compromised. It's not easy to tell if a device is rooted because the user wanted root access or because a virus got in.

But suppose you established that the user intentionally rooted the phone (somehow). It'd still not be clear whether the rootkit that the user used was trustworthy. Even if you established that it was trustworthy (stretching the bounds of reasonableness; who is auditing these?), you couldn't assume that the user hadn't run other malicious programs. That last point is true for non-rooted phones, of course, but since this user had root access those hypothesized malicious programs become much more dangerous.

(Also, I doubt you own or have root access to your credit card. But what would you do with it if you did? All I can come up with is to consolidate a few of them onto one piece of plastic.)

Re: Credit card: I own one, I can hand it out. Most of the information necessary to use it (name, number, CSC) are available if you hold that card for a second.

My (honest, I'm not trying to pull your leg or anything) question is:

I have a phone. I own it. You (payment provider) cannot control it and I might do stupid things.

I have a credit card. I own it. You (card issuer) cannot control it and I might do stupid things.

Where's the difference? How can CCs work, but Android Pay/Samsung WhateverWhyWouldIUseIt doesn't, given my current impressions above. Can you correct my errors?

Credit cards don't have radios in them with 24/7 internet connections and software vulnerabilities.

I think it is reasonable to assume, as mentioned elsewhere, that rooted devices are more prone to data-compromising attacks. And, due to security bugs, devices that are rooted may not have been rooted with the owners knowledge or permission.

It's a lot harder to attack at scale when targeting credit cards than an attack that targets mobile devices.

The difference is, you don't actually own your CC. You have physical possession yes, you can manage various aspects of it yes, you can even turn it off if you desire - but you don't own it. The bank does. The bank controls the card far more thoroughly than you do, including rights to create, replace, remotely destroy, cancel transactions, etc. You have the physical card and you can use it, but all of the permissions you have are rights granted to you by the true owner of the card - the bank.

its actually against the banks ToS to give your credit card to anyone else... even at the register.

but everyone ignores that :-P

It's easy: just ask the user.

As if the user knows if they've been rooted by a malicious third party.

Rooting can allow software to elevate privileges enough so it can see outside its sandbox and access other software's private storage.

That means (for example) spyware has one less thing stopping it form manipulating (eg) Android Pay to steal money.

>So, 'jailed' is a reason to mark it as 'requires attention'? Well played, well played..

I must be reading the image wrong. Jailed has a green check mark beside it, and Up-to-date has a red negative sign. Presumably, this is why the device would require attention?

You don't own Netflix content. You pay for temporary access to it. If you could use root access to compromise the app and pirate their content, that could cost them licensing deals and lots of money. If you can't use root, that costs them little.

You don't own your credit card either. The piece of plastic is actually owned by the bank. As they will likely be the ones that take a loss in the event of fraud from malware breaking into Android Pay, but similarly they gain nothing from letting you root your device, so their behavior makes sense.

It's the usual security theater. Custom roms do a good job of securing root access for apps, what I find hilarious is a sideloaded app can do a lot more damage yet Android Pay works if you have sideloading enabled... go figure.

You can get Android Pay to work on a rooted device using systemless Xposed framework and root cloak, it basically just lies to the dumb checks.

A side-loaded app cannot access another app's storage.

But if you have root, then why would any software you don't want to know you have root, know you have root? That is, if you control the device, have it lie about the control you have to things that care...

But you don't own your CC if you read the back it normally says "property of (whatever bank)"

> So, 'jailed' is a reason to mark it as 'requires attention'? Well played, well played..

Yeah, that's pretty dumb security theatre. If the device is rooted, it can fake your root checks. Just ask Blizzard.

Better to figure out how to operate even when that happens.

>If the device is rooted, it can fake your root checks. Just ask Blizzard

What happened with Blizzard and rooting?

Blizzard is continuously playing cat and mouse games to see if you are using bots or cheats for their games. Blizzard comes up with a bunch of anti-cheating checks and within days they all get defeated.

It's a never-ending task.