Aren't HTML5 EME plugins sandboxable, though? That is, aren't they definitely not rootkits?

I wasn't saying HTML5 EME supported rootkits. DRM doesn't belong in the web standard, that's a fundamental belief of mine against DRM in general. I'm saying TBL and Netflix are both campaigning for non-rootkit-like DRM, better than the worst DRM, but DRM none the less. Netflix is a company, it's only real concern is making money, regardless what they're owners/employees personally believe, they won't get big budget films without it, so I understand why they're working for "Good" DRM. But no individual should be lobbying for "better" DRM.

I think that describing Google Play Services (or Android? or I'm-not-sure-what) as "a google rootkit" isn't super conducive to a meaningful discussion, even if there's a technical interpretation under which it's true.

In particular, most users of Netflix on Android have a threat model that involves Google legitimately having the ability to push software updates to the phone that run as root. So "rootkit" is not a very useful term, any more than describing any Debian package maintainer script as a "random volunteer's rootkit" would be.

Suppose you needed to install this particular Debian package with root privileges (well, necessarily, but you get the point) that you otherwise would not want to install and that then goes on to enforce a certain behaviour of your computer against your interests as a prerequisite for using some other piece of software.

Suppose further that someone put forward the argument that it's not so bad, as at least there is no rootkit involved.

Then, yes, it would obviously be perfectly sensible to in that context call that Debian package a "random volunteer's rootkit".

Whether most users would like to have some other functionality provided by that same package is completely irrelevant to the question at hand, as is whether most users would install the package.

> Suppose you needed to install this particular Debian package with root privileges (well, necessarily, but you get the point) that you otherwise would not want to install and that then goes on to enforce a certain behaviour of your computer against your interests as a prerequisite for using some other piece of software.

This happens to lots of people under the name of systemd. I think any definition of "rootkit" that includes involuntary installations of systemd is so broad that we cannot conclude anything from the term. (There are legitimate criticism of Debian requiring systemd, but they're basically entirely orthogonal from the criticisms of, say, the Sony BMG rootkit.)

So, let me ask - what in particular are you seeing as the "google rootkit," and how would you describe its negative behavior in words other than "it's a rootkit"?

> So, let me ask - what in particular are you seeing as the "google rootkit," and how would you describe its negative behavior in words other than "it's a rootkit"?

Well, I am not all that well-versed in Android/Google components/APIs/whatever, so I can't really tell you what specific component that would be, but as I understand it, there is some mechanism provided by the platform that allows an app to check whether the owner is locked out from controlling their own device, right?

So, it's some component with high privileges that gives the power to control how you use your device to a party that's not you ... now, "rootkit" isn't really all that clearly defined, but I would say that that's clearly the core of what makes a rootkit a rootkit, don't you think?

The relevant service provides some information about your device to Google, which makes a decision (I'd assume based on heuristics or ML) about your device's integrity compared to Google's baseline. An app's vendor can choose to condition the Play Store entry on the result of the Google calculation.

A rootkit, traditionally, hides its existence from you and provides root access (i.e., code execution as root) for some outside attacker. Oxford defines it as "a set of software tools that enable an unauthorized user to gain control of a computer system without being detected;" Veracode defines it as "a clandestine computer program designed to provide continued privileged access to a computer while actively hiding its presence;" Wikipedia, citing McAfee, says that a it's "designed to enable access to a computer or areas of its software that would not otherwise be allowed (for example, to an unauthorized user) and often masks its existence or the existence of other software." I think these two properties are the core of what makes a rootkit a rootkit (and also the core of what makes it bad).

This Google service neither attempts to hide its existence nor does it provide remote access / code execution to anyone.

The closest term I can think of for something that provides information to others is "spyware", but even that's a serious stretch. This utility is most similar to the function called by desktop software installers that check to see if you have enough disk space, so the installer can choose to abort based on the result. And I'd definitely not call that a "rootkit" or "spyware".

I think you are far too literal, instead of looking at the big picture.

I mean, Windows doesn't even have a default privileged user named "root", does that mean that the Sony BMG rootkit was not a rootkit, because, traditionally, that's the name applied to stuff that gave access to the root account on a unixoid system? If all you cared about was etymological purity, you certainly could make that argument.

Now, what does "access to a computer" mean? What does "otherwise not allowed" mean? What does "remote access" mean? What does "code execution" mean? What does "hiding" mean?

Does the average user actually know that there is a component on their phone that reports to google whether they have tinkered with it? Is it advertised to them that that is the case? What would it take in your mind to qualify as "hiding"? And mind you, traditional, unixy, rootkits aren't necessarily undetectable either, not even on the running system.

Suppose there were some mandatory software installed on your phone that allowed some other party to control which telephone numbers you are allowed to call. Is that "remote access"? I mean, it's obviously giving someone remote control over what your phone will do, or refuse to do. What would it take in your mind to qualify as "remote access"? Would that necessarily require code execution? And if so, what does "code execution" actually mean? Is a javascript interpreter you can load code into (aka a web browser) "code execution"? Or is it not because it's in a sandbox? But then, what if the phone has a hypervisor, and the "rootkit" only gives you root access to the linux kernel running on top of that hypervisor ... that's also kindof a sandbox, so that doesn't qualify as a rootkit either? Or does it?

Suppose you were to ask people "do you want to have software installed on your phone that reports to third parties whether you have tinkered with your phone?" ... how many people do you think would say "yes"? If it's installed on the phones of people who would answer "no" to this question, wouldn't that qualify as "access [...] that would not otherwise be allowed"? How would you justify that as authorized use of the phone? Or would you?

What distinguishes spyware from rootkits is exactly that spyware just exfiltrates data, whily rootkits allow some sort of control of the system (but also, the distinction isn't always all that clear-cut).

Now, you might argue that google's component is just spyware (and you kindof did) ... but that's again missing the big picture, because the whole point of this spyware obviously is to control what the user can do with their device, even if part of that mechanism then is technically implemented by a third party and/or on a remote server.

> This utility is most similar to the function called by desktop software installers that check to see if you have enough disk space, so the installer can choose to abort based on the result.

That shows that you are completely missing the point: This is about power structures, not about technical implementation details. You might as well be arguing that a gun is most similar to a computer case, because they are both made from metal, in a discussion about whether someone holding a gun to your head is comparable to someone threatening to hit you with a baseball bat.