Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is not malware. It's an official part of Google Play Services.


It all depends on how you define malware. If malware is software doing something that is contrary to the user's interests, then for many users it is indeed malware.


Too much hedging in this comment.

Malware is something that maliciously breaks your computer.

This maliciously breaks my computer so it's malware. There's no difference between this and the ILOVEYOU virus, except the delivery mechanism.


Can I install some software on your computer to send me over your bank details? It won't break your computer, I promise, it's not malware.


>this malevolent process has exactly one goal: to block you from running software by developers who haven’t been approved centrally by Google.

This claim is made by FDroid with no evidence. They make this scary claim which goes against everything Google has claimed so far. They are a biased party, and I can't trust their opinion. I would appreciate if they shared a more in depth investigation or a way to verify there big claim.


Trust is not binary; we can process data with a level of confidence. We do not need either Google or F-Droid to be sanctified before we evaluate their claims.

The claim is that a repeat monopolist is doing monopolist things. Feel free to make the case for the trustworthiness of Google's opposing claim, as I don't see anyone else doing that.


Google wrote their plans as blog posts.


But the plan doesn't include blocking developers who are not verified. You can still sideload such apps once you enable sideloading for them.


The point is that it is said to tamper with your installations. If it does, it is malware.


It doesn't tamper with your installations.


Oh? Maybe you could comment on what part of the f-droid article is wrong


>If you are running Android 8 or higher, a virus has been installed on your device and is silently awaiting remote activation.

I have such a phone and the "virus" has not been installed to it. There is no evidence behind this claim.

>with as many as 4 billion Android handsets and tablets estimated to have already been contaminated

This is misleading wording. It's just as true to say that as many as 1 trillion devices have been contaminated. It is state an impossible upper bound to drum up fear.

>this trojan horse runs surreptitiously in the background as a system service with full root privileges

Services in Android do not run with root privileges. Android practices the principal of least privilege where individual permissions are granted instead of giving it blanket access to everything.

>The service cannot be blocked, disabled, or removed.

This is unlikely to be true. You can most likely use "am" to disable it.

>In fact, Play Protect is itself the vector through which this virus is transmitted and installed.

This is probably false. Realistically it's going to be transmitted via the google play store like all other play service components.

>There are many things we don’t know about what to expect on September 30

>What will happen if I try to install or launch the F-Droid app?

Once active if FDroid not verified the user has to use adb or have enabled sideloading by unverified developers. If it's already installed the user can launch it.

>What will happen to all the apps I’ve installed through F-Droid? Will they be disabled? Deleted?

Nothing will happen to them.

>If apps that I rely on are suddenly disappeared, what happens to the data they contain? Can I still retrieve it?

Nothing will happen. But if Play Protect were to flag malware it manually asks you if you want to delete the app. If you delete the app the data will be lost.


We are in a dire situation as the world has been going towards the normalization of the pratices of spreading stubs missing crucial information.

-- The medicine? "It's good against illness. You'll be fine". ("You want to know the side effects - Due Diligence or OCD?")

-- The engine? "It's ecological. Ain't you glad?" ("Three clylinders with consumables inside the engine - really do you want to know?")

-- The stats? "Here is some aggregate data as the layout demands" ("People are confused by numbers, you cannot print them on newspapers" - I really was made to hear that years ago.)

-- The contract? "Everbody signs it, sign here!" ("Really you want to read it? But we had not allotted the time...")

-- New entrance checks? "It's for the children!" ("What do you mean if it involves uploading a document you will never?")

etc.

~~

Is there any place in which the crucial, critical information about this new idea from Google, duly FAQ, is found? E.g. what installs the service, what does the service do if it encounters the software that we develop locally and we install on the device etc. Is there any authoritative source?

~~

> Nothing will happen. But if Play Protect were to flag malware it manually asks you if you want to delete the app

charcircuit, could you share what makes you confident (or informed) that the above is what will happen?

Some people use Android devices for the development of non-public software that will never reach the Play Store. (The "Corporation C internal tools APK" has no place there.) Where do we read the warranties that no disaster will happen involving my_private_app.apk?


>charcircuit, could you share what makes you confident (or informed) that the above is what will happen?

Google has stated that this is about sideloading apps and has only talked about the sideloading flow being changed. Removing already installed apps is unrelated to the sideloading / package installation flow. Google has not stated anything about deleting apps from unverified developers so I am confident it won't happen. As I mentioned there already is a component in the system responsible for removing malware.

>Where do we read the warranties that no disaster will happen involving my_private_app.apk?

There is no warranty similar to how there is no warranty Google will make your phone summon nasal demons.

>Is there any place in which the crucial, critical information about this new idea from Google, duly FAQ, is found?

It will eventually be in an apk on the device and once someone dumps I would be willing to reverse engineer it and explain its functionality free of charge.


All you do is appreciated. But,

> There is no warranty similar to how there is no warranty

that an OS does not impede the use of self produced software it has never impeded seems to me a basic warranty to be given to its user base.

All kind of related questions from "Will Android Studio (etc.) still work as before in an unmodified workflow" to "Will `adb install` still work, and on which APKs" are questions that Google should have answered preemptively, as part of the news.


Thanks, I appreciate the elaborate response.

If you can just disable it with the activity manager or similar, I don't think Google would provide another workaround with a wait time and everything - and that only after a lot of public pressure. It's claimed to be a security feature against scams, and scammers can theoretically let you open up an adb shell and run an am command, so that would negate the safety. (That this never happens in practice imo demonstrates that it's just about ecosystem control and not actually for user safety.)

I agree on the root thing though. I don't have a device here that has this service running so I can't check the process permissions for myself, but it seems extremely doubtful that it runs as uid 0. Fdroid could have dumbed the technical permission level down in more accurate way

How do you know nothing will happen to already-installed apps and their data, when the user hasn't had time yet to go through the annoyance unlock procedure?


>and scammers can theoretically let you open up an adb shell and run an am command

It requires a lot more steps to do this. Finding another computer, installing Android dev tools, finding a cable to connect them. In reality this adds a lot of friction.

>How do you know nothing will happen to already-installed apps and their data, when the user hasn't had time yet to go through the annoyance unlock procedure?

Extrapolation based off how play services has handled things so far and how Google has explained what will happen. Of course without looking at the actual code I can't say for 100% certainty, but from my perspective fdroid is fear mongering here as there is no evidence that supports this viewpoint. If they had evidence to back these dramatic claims up I would be less critical on them.


> It requires a lot more steps to do this. Finding another computer, installing Android dev tools, finding a cable to connect them. In reality this adds a lot of friction.

That's exactly the point. I think it's fair to require people to use a command line (and go through the steps that we already need to get there) to do advanced things. My grandma is an excellent comprehenseless button presser but, when faced with an "MS DOS" window, even she would be stumped at how to fuck up her system :-). Yet that's not what Google is doing and thus I concluded in that paragraph:

> > it's just about ecosystem control and not actually for user safety.

Regarding destruction of data, Android does actively remove people's data unasked. Just today I got another one of these notifications "you haven't used these apps in the last 3 months, we've removed the permissions you've set", and I previously made the mistake of ignoring that annoyance but now I know it'll move to stage 2 "we've removed your user data, enjoy!" after something like half a year. One of those apps is one of the 2FA apps I have and need less than once a year for e.g. an insolvency I'm involved in (a slow process). They'd remove the hard-to-recover 2FA secrets if I don't actively move to prevent that. (Having root for making backups makes this a bit less impactful thankfully, but the average person doesn't know how to make full-system backups.)


False


Those are not mutually exclusive.


it is malware when everyone is explicitly asking to not have it.


Which is malware.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: