Comment by rom1v
3 months ago
I want to be able to install apps from alternative app stores like F-Droid and receive automatic updates, without requiring Google's authorization for app publication.
Manually installing an app via adb must, of course, be permitted. But that is not sufficient.
> Keeping users safe on Android is our top priority.
Google's mandatory verification is not about security, but about control (they want to forbid apps like ReVanced that could reduce their advertising revenue).
When SimpleMobileTools was sold to a shady company (https://news.ycombinator.com/item?id=45410805)
Yes, it's all about control. Control the platform. Control the access to the platform, and the world is your oyster. And the political and legislation system are their friends. It is the establishment.
The only way to fight is to indoctrinate the next generation, at home, and in school, to use FOSS. People tend to stick to whatever they used in childhood. We the software engineers should volunteer in giving speeches to students about this. It is much easier to sell ideologies to younger people when they are rebellious to the institutions.
I agree with you. But you do realize that it's been like that since about 20 years now. It started because of Microsoft (proprietary software), then Google (propriteary platform), now ChatGPT (proprietary knowledge).
And I tried to tell my kids. And it failed mostly.
But in the long run (a decade), what is exceptional and proprietary will become common FOSS. And everybody will benefit.
I envision this as an ideology. We don't need every kid to follow it, and I don't expect the majority to follow. A 1-2% is good enough. That's why giving speeches to teenages might be the best bang for the buck. There are always kids who need to escape into some cool ideas and it could be the idea of FOSS.
Really its probably the dumbass judge that told Google "The apple app store isn't anti-competitive because they don't allow any competitors on their platform" when google asked why the play store was ruled a monopoly and the app store wasn't.
I cannot think of a more detached and idiotic ruling than that.
The US anti trust legislation punishes the abuse of monopoly power, not being monopoly in itself. Google was found guilty in leveraging their dominating position on the platform to do just that.
On the other hand in the US Apple's App Store was not found to be a monopoly in the first place. Different cases about abusing dominating position also didn't go far.
Hmm, having read that, I am starting to sympathize with Google if they are going to be punished for being open.
No one seems to care that Apple has never allowed freedom on their devices. Even the comments here don't seem to mention it. Google was at least open for a while.
Or maybe no one mentions it just because the closed iPhone is a fait accompli at this point.
1 reply →
I guess they are going to say whatever to prove the case. The legislation system is highly...closed and shun of laymen.
8 replies →
But the ruling is correct. You can't have it both ways, if you invite competition you're not allowed to be anti-competitive. You can be Nintendo, offer a single store, only allow first party hardware, and exercise total control over your product. Then your anticompetitive behavior can only be evaluated externally. But if you open yourself up to internal competition with other phone vendors, other stores, and then you flex your other business units (gapps) to force those other vendors to favor you then you're in big trouble.
11 replies →
So basically you're saying we're fucked. People don't care about FOSS in general, let alone when their phone says it's dangerous.
If peopele cared about privacy as much as politics pretends they do, we'd have solved so many problems in society.
Fortunately, those fighting, albeit a minority, have done great work in protecting this. No reason to stop now.
Yeah we are fucked, but as long as a small percentage of us, like 1% of the population knows, understands and agrees with the idea I think we are fine.
1 reply →
Really difficult because you need to have two devices.
One mandated be the establishment and one mandated by visions and freedom.
But it would be a great start.
On my work laptop I am mandated to use Windows 11 but I run (and when I have time) I develop FOSS.
Imagine needing to agree with a TOS that can lock you out of your phone when they change/add some random new policy
I don't really see how you can both allow developers to update their apps automatically (which is widely promoted as being good security practice) and also defend against good developers turning bad.
How does Google know if someone has sold off their app? In most cases, F-Droid couldn't know either. A developer transferring their accounts and private keys to someone else is not easily detected.
> In most cases, F-Droid couldn't know either.
F-Droid is quite restrictive about what kinds of app they accept, they build the app from source code themselves, and the source code must be published under a FLOSS license. They have some checks that have to pass for each new version of an app.
Although it's possible for a developer to transfer their accounts and private keys to someone shady, F-Droid's checks and open source requirements limit the damage the new developer can do.
https://f-droid.org/docs/Inclusion_Policy/
https://f-droid.org/docs/Anti-Features/
One thing worth noting, these checks and restrictions only apply if you're using the original F-Droid repository.
Many times I've seen the IzzyOnDroid repository recommended, but that repo explicitly gives you the APKs from the original developers, so you don't get these benefits.
1 reply →
You know what? That's bullshit.
Anybody slightly competent can put horrendous back doors into any code, in such a way that they will pass F-Droid's "checks", Apple's "checks", and Google's "checks". Source code is barely a speed bump. Behavioral tests are a joke.
3 replies →
> In most cases, F-Droid couldn't know either. A developer transferring their accounts and private keys to someone else is not easily detected.
1. The Android OS does not allow installing app updates if the new APK uses a different signing key than the existing one. It will outright refuse, and this works locally on device. There's no need to ask some third party server to verify anything. It's a fundamental part of how Android security works, and it has been like this since the first Android phone ever release.
2. F-Droid compiles all APKs on its store, and signs them with its own keys. Apps on F-Droid are not signed by the developers of those apps. They're signed by F-Droid, and thus can only be updated through and by F-Droid. F-Droid does not just distribute APKs uploaded by random people, it distributes APKs that F-Droid compiled themselves.
So to answer your question, a developer transferring their accounts/keys to someone else doesn't matter. It won't affect the security of F-Droid users, because those keys/accounts aren't used by F-Droid. The worst that can happen is that the new owner tries injecting malware into the source code, but F-Droid builds apps from source and is thus positioned to catch those types of things (which is more than can be said about Google's ability to police Google Play)
And finally,
> How does Google know if someone has sold off their app?
Google should not know anything about the business dealings of potential competitors. Google is a monopoly[1], so there is real risk for developers and their businesses if Google is given access to this kind of information.
[1]: https://www.google.com/search?q=is+google+a+monopoly%3F&udm=...
Android also has the feature of warning the user if an update is coming from a different source than what is installed. This will happen even if they have the same key. This reply isn't trying to argue against anything you've said. I am just adding to the list of how Android handles updates.
> F-Droid compiles all APKs on its store, and signs them with its own keys. Apps on F-Droid are not signed by the developers of those apps. They're signed by F-Droid, and thus can only be updated through and by F-Droid. F-Droid does not just distribute APKs uploaded by random people, it distributes APKs that F-Droid compiled themselves.
For most programs I use, they just publishing the developer's built (and signed) APK. They do their own build in parallel and ensure that the result is the same as the developer's build (thanks to reproducible builds), but they still end up distributing the developer's APK.
3 replies →
You have to trust somebody.
Who is F-Droid? Why should I trust them?
How do I know they aren’t infiltrated by TLAs? (Three Letter Agencies), or outright bad-actors.
Didn’t F-Droid have 20 or so apps that contained known vulnerabilities back in 2022?
Who are all these people? Why should I trust them, and why do most of them have no link to a bio or repository, or otherwise no way to verify they are who they say they are and are doing what they claim to be doing in my best interests?
https://f-droid.org/en/about/
9 replies →
>> In most cases, F-Droid couldn't know either. A developer transferring their accounts and private keys to someone else is not easily detected.
> 1. The Android OS does not allow installing app updates if the new APK uses a different signing key than the existing one. It will outright refuse, and this works locally on device
You missed the and private keys part of the original claim.
1 reply →
If an app updates to require new permissions, or to suddenly require network access, or the owner contact details change, Google Play should ideally stop that during the update review process and let the users know. But that wouldn't be good for business.
An update can become malicious even without change in permissions.
E.g. my now perfectly fine QR reader already has access to camera (obvious), media (to read QR in an image file or photo) and network (enhanced security by on-demand checking the URL for me and showing OG etc so I can more informed choose to open the URL)
But it could now start sending all my photo's to train an LLM or secretly make pictures of the inside of my home, or start mining crypto or whatnot. Without me noticing.
3 replies →
>...or to suddenly require network access...
That's the most baffling thing to me. There is simply no option to remove network permissions from any app on my Pixel phone.
It's one of the reasons why I avoid using mobile apps whenever I can.
21 replies →
This is a huge problem in the Chrome Web Store and Google is doing very little about it. If you ever made an extension that is even just a little popular, expect to get acquisition offers by people who want to add malicious features somewhere between click fraud, residential IP services or even password stealers.
1 reply →
Indeed, an update can't be more malicious than the permissions allow it to be. You have a calculator app with limited permissions, it is "safe" to set to allow the developer to update it. No danger in that.
But I don't think it is enough, or it is the right model. In other cases, when the app has dangerous permissions already, auto-update should be a no-go.
1 reply →
> F-Droid couldn't know either
F-Droid is not just a repository and an organization providing the relevant services, but a community of like-minded *users* that report on and talk about such issues.
> which is widely promoted as being good security practice
Maybe that's the mistake right there?
It is a good practice only as long as you can trust the remote source for apps. Illustration: it is a good security practice for a Debian distro, not so much for a closed source phone app store.
OPEN SOURCE EVERYTHING is the premier solution.. again.
By using the distributor model, where a trusted 3rd party builds & distributes the apps. Like every Linux distro or like what F-droid does.
The point here is that app developers have to identify themselves. Google has no intention to verify the content of sideloaded apps, just that it is signed by a real person, for accountability.
They don't know if the person who signed the app is the developer, but should the app happen to be a scam and there is a police investigation, that is the person who will have to answer questions, like "who did you transfer these private keys to?".
This, according to Google and possibly regulators in countries where this will be implemented, will help combat a certain type of scam.
It shouldn't be a problem for YouTube Vanced, at least in the proposed form. The authors, who are already idendified just need to sign their APK. AFAIK, what they are doing is not illegal or they would have been shut down long ago. It may be a problem for others though, and particularly F-Droid, because F-Droid recompiles apps, they can't reasonably be signed by the original author.
The F-Droid situation can resolve itself if F-Droid is allowed to sign the apps it publishes, and in fact, doing that is an improvement in security as it can be a guarantee that the APK you got is indeed the one compiled by F-Droid from publicly available source code.
APKs are already signed. Now Google requries that they be signed by a key which is verified by their own signatures. Which means they can selectively refused to verify whichever keys are inconvenient to them.
> Google has no intention to verify the content of sideloaded apps, just that it is signed by a real person, for accountability.
for now
Still believe that signing binaries this way is always bullshit.
I stopped developing for mobile systems ages ago because it just isn't fun anymore and the devices are vastly more useless. As a user, I don't use apps anymore either.
But you can bet I won't ever id myself to Google as a dev.
> I don't really see how you can both allow developers to update their apps automatically (which is widely promoted as being good security practice) and also defend against good developers turning bad.
These are not compatible, but only because the first half is simply false. Allowing a developer to send updates is not "good" but "bad" security practice.
That's true in theory. But as you can see in practice is that google does very little to protect their users, while F-Droid at least tries.
Which shows that the whole 'security' rigmarole by google is bullshit.
In many cases developer e-mail address changes, IP address changes, billing address changes, tax ID changes...
This exactly. Transferring ownership is a business transaction. Track that. If the new owner is trying to hide it, this is fraud, and should be dealt with in court.
This is a big problem with Chrome extensions and Google hasn't done anything about it there, so I don't think they actually care about it. I'm not actually sure how you would solve that problem even theoretically.
To be fair, on Google Play you have the option to transfer the app to someone else's account. People don't need to trade accounts...
That doesn’t help mitigate the class of attack you responded to.
Quite simple: Actual human review that works with the developers.
But this costs money, and the lack of it is proof google doesn't really care about user security. They're just lying.
> without requiring Google's authorization for app publication.
funnily enough, I am installing google drive for computers right now (macOS), I had to download a .pkg and basically sideload the app, which is not published on the Apple Store
Why the double standard, dear Google?
>I had to download a .pkg and basically sideload the app, which is not published on the Apple Store
You mean install the app? The fact that Apple and Google wish to suggest that software from outside their gardens is somehow subnormal doesn't mean other people need to adopt their verbiage.
> You mean install the app?
Correct, I mean install the app.
Sideloading is the corporate jargon for "installing an app".
Probably because they require APIs which cannot be used when publishing to the AppStore. The whole Microsoft Office Suite is available in the macOS App Store - but Microsoft Teams must be downloaded from their website and cannot be installed via the AppStore...
> Probably because they require APIs which cannot be used when publishing to the AppStore
That's the funny part.
They do stuff they want to prohibit to other developers because "safety".
But we all know that Google can do massively more harm than scammers pushing their scammy apps to a few hundreds people.
For example, in today's news "Google hit with EU antitrust investigation into its spam policy".
There's a bit of irony in it and a lot of hypocrisy, IMO.
Bad example because that .pkg was probably signed with a developer certificate with approval from Apple - just as would be the case on Android in the future.
> > Keeping users safe on Android is our top priority.
Somebody tell them that I do not want to be kept safe by Big Brother.
Your personal data will be kept safe on our servers, citizen, whether you like it or not.
Enforcer, informing citizen on basic practices undermines citizen's delusion of being free. Please refer to room 22a for re-alignment and training.
> Your personal data will be kept safe on our servers, citizen, whether you like it or not.
... and our business partners. And app developers that grab your clipboard. And their business partners. and a few more levels of data brokers. The spi^H^H^H data-vacuum must flow
EU did more by mandating 5 years of updates…
And of course, code signing can't protect you from such a thing. When software publishing rights get bought, so (usually) do the signing keys.
Curation (and even patching) by independent, third-party volunteers with strong value commitments does protect users from this (and many other things). Code signing is still helpful for F/OSS distributions of software, but the truth is that most of the security measures related to app installation serve primarily to solve problems with proprietary app markets like Google's Play Store and Apple's App Store. Same thing with app sandboxing.
It's unfortunate but predictable when powerful corporations taint genuine security features (like anti-tampering measures, built-in encryption devices, code signing, sandboxing, malware scanning, etc.) by using them as instruments of control to subdue their competitors and their own users.
The entire SimpleMobileTools situation left such a bad taste in my mouth. No upfront communication, it had to be discovered in a GitHub issue thread after people started asking questions.
It was shady as fuck on Kaputa's part, especially given ZipoApps is an Israeli adware company, a.k.a. surveillance company, and given Israel's track record with things like using Pegasus against journalists/activists or blowing up civilian-owned beepers, this should automatically be a major security incident and at least treated as seriously as the TikTok debacle.
Kaputa should be extremely ashamed of himself and outted from the industry. I and many others would have gladly paid a yearly subscription for continued updates of the suite instead of a one-time fee, but instead of openly discussing such a model with his userbase, he went for the dirtiest money he could find.
If "automatic updates" were optional and off-by-default then users would not be vulnerable to something like SimpleMobileTools
Why not let the user decide
Letting someone else decide has potential consequences
Using F-Droid app ("automatic updates") is optional, as it should be
"Automatic updates" is another way of saying "allow somone else to remotely install software on this computer"
Some computer owners might not want that. It's their decision to make
I disable internet access to all apps by default, including system apps
When source code is provided I can remove internet access before compilation
Anyway, the entire OS is "user-hostile" requiring constant vigilance
It's controlled by an online ad services company
Surveillance as a business
> If "automatic updates" were optional and off-by-default then users would not be vulnerable to something like SimpleMobileTools
The problem is the vast majority of users want this on by default; they don't want to be bothered with looking at every update and deciding if they should update or not.
The vast majority of users want their apps to work. They don't care whether that happens through automatic updates or not.
It's the developers who don't want the headache of not having automatic updates.
"Automatic updates" is "remote code execution (RCE)" by permission
Given the frequent complaints about the former, the notion of "permission" is dubious
> I want to be able to install apps from alternative app stores like F-Droid and receive automatic updates
That's actually possible, though app stores need to implement the modern API which F-Droid doesn't seem to do quite well (the basic version of F-Droid (https://f-droid.org/eu/packages/org.fdroid.basic/) seems to do better). Updating from different sources (i.e. downloading Signal from GPlay and then updating it from F-Droid or vice versa) also causes issues. But plain old alternative app stores can auto-update in the background. Could be something added in a relatively recent version of Android, though.
If this Verified bullshit makes it through, I expect open source Android development to slowly die off. Especially for smaller hobbyist-made apps.
[dead]