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=38505229), the new owner was able to push any user-hostile changes they wanted to all users who had installed the original app through Google Play (that's the very reason why the initial app could be sold in the first place, to exploit a large, preexisting user base that had the initial version installed).
That was not the case on F-Droid, which blocked the new user-hostile version and recommended the open source fork (Fossify Apps). (see also this comment: 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.
Perhaps because Apple never “promised” to be open, Google instead built itself by playing the good guy and started to switch when money called so those who chose them for that reason feel betrayed.
Because that's the law, like it or not. Apple doesn't have a problem because the rules were the rules from day 1. Google did a bait and switch, legally.
What does antitrust law have to do with "day 1"? So if Ford and GM are both already in all 50 states and then they try to divide up territory between them, that's illegal, but at the point when there were still areas one of them wasn't in, they could publicly announce a contractual agreement to not enter into the other's territory? That seems not just questionable but actively bad policy with an enormous perverse incentive.
And if you're going to say this:
> Because that's the law, like it or not.
I would ask you to point me to the text in the statute requiring the courts to do that.
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.
> But the ruling is correct. You can't have it both ways, if you invite competition you're not allowed to be anti-competitive
That's just stupid, because being anti-competitive is an emergent outcome, rather than anything specific.
Apple is definitely anti-competitive, but they exploited such a ruling so that they can skirt it. Owning a platform that no other entrants are allowed is anti-competitive - whether you're small or large. It's only when you're large that you should become a target to purge via anti-competitive laws. This allows small players to grow, but always face the threat of purging - this makes them wary of trying to take advantage too much, which results in better consumer outcomes.
That's like Karcher opening a megamall to sell all their offering, vacuums, pressure washers, floor washers, you name it .. and then you, Bosch, complaining you can't sell your vacuum in Karcher's megamall where all the people go.
What are you even saying?
Whereas google was letting Bosch sell vacuums in their megamall, but only if it uses Google dust filters and people buy only Google made dust filters and Bosch isn't allowed to sell their own dust filters in the megamall.
It's like a company buying all the land within a 100 mile radius and then nominally "selling" plots to people but with terms of service attached that restrict what you can do with the land you bought and that allow the company to change the terms at any time. And then, after people have moved in, most of them having not even read the terms or realized it wasn't an ordinary sale, they start enforcing the terms against competitors. Which most people don't notice because they aren't competitors, and because the terms also prohibited anyone in the city from telling people what's going on[1]. Then people eventually notice and start to ask whether terms locking out competitors like that are an antitrust violation, and someone says that they're not because the people there agreed to them.
But how is an agreement prohibiting people from patronizing competitors not an antitrust violation? It's not a matter of who agreed to it, it's matter of what they're requiring you to agree to.
> nominally "selling" plots to people but with terms of service attached that restrict what you can do with the land you bought and that allow the company to change the terms at any time.
> Karcher opening a megamall to sell all their offering
And their mall is monopolistic if it is only for Karcher products. However, because a competitor can easily open a mall next door, it means this Karcher mall is small, and so the enforcers should leave it be. Until the day Karcher buys up all the mall space, in which case, they (regulators) start purging their mall monopoly.
The threat of being purged because you've acquired a large enough monopoly should _always_ be there. It's part of doing business in a fair environment.
> You can be Nintendo, offer a single store, only allow first party hardware, and exercise total control over your product.
How is this not even more anti-competitive?
It's fine to be mad at Google for being duplicitous, but treachery is in the nature of false advertising or breach of contract. Antitrust is something else.
"You can monopolize the market as long as you commit to it from the start" seems like the text of the law a supervillain would be trying pass in order to destroy the world.
You can't monopolize a market where there is no market. Nintendo can be anticompetitive in the wider games industry, but there is no market for software that runs on a Switch.
I didn't say I liked the ruling, just that it's correct. The opposite conclusion would be absurd, that you can invent a market where there isn't one and claim a company has a monopoly over it. You would be asking the court to declare that every computing device is a de facto marketplace for software that could run on it and that you can't privilege any specific software vendor. I would love if that were true but you can hopefully agree that such a thing would be a huge stretch legally.
> You can't monopolize a market where there is no market. The opposite conclusion would be absurd, that you can invent a market where there isn't one and claim a company has a monopoly over it.
There is no such thing as "there is no market". There is always a market. The question is, what's in the market? The typical strategy is to do the opposite -- have Nintendo claim that they're competing with Sony and Microsoft in the same market to try to claim that it isn't a monopoly.
But then the question is, are they the same market? So to take some traditional examples, third party software that could run on MS-DOS could also run on non-Microsoft flavors of DOS. OS/2 could run software for Windows. The various POSIX-compliant versions of Unix and Linux could run the same software as one another. Samsung phones can run the same apps as Pixel phones. Which puts these things in the same market as each other, because they're actually substitutes, even though they're made by different companies.
Conversely, you can't run iOS apps on Android or get iOS apps from Google Play or vice versa. It's not because they're different companies -- both of them could support both if they wanted to -- it's that they choose not to and choices have consequences.
If you intentionally avoid competing in the same market as another company then you're not competing in the same market as that company and the absurdity is trying to have it both ways by doing that and then still wanting to claim them as a competitor.
You avoided the important part, there is no market for hardware that can play Nintendo Switch games and there is no market for software providers on Nintendo Switch. And they are legally allowed to do that. You can sell appliances that are bound to a single vendor and you are allowed to not license your hardware or software to 3rd parties.
Since that is a legally permissible action it would be an odd thing for a court to declare that doing such a thing is anticompetitive. If they did they would be declaring all locked down hardware effectively illegal. And while that might be nice it's a bit of a pipedream. Where Google fucked up is that they did license their software to 3rd parties—good for them. But then Google had some regrets and didn't like the fact that they didn't have control over those 3rd parties. But they did have
some leverage in the form of Google Play and GSM because users expect it to be there on every Android phone. And then they used that leverage. That's the fuckup. They used Google Play and GSM access to make 3rd parties preinstall Chrome and kill 3rd party Android forks. They used anticompetitive practices on their competitors—other Android device manufacturers.
This situation can't occur for Apple or Nintendo because there aren't other iOS/Switch device manufacturers and they don't have to allow them to exist. They can be anticompetitive for other reasons but not this.
> You avoided the important part, there is no market for hardware that can play Nintendo Switch games and there is no market for software providers on Nintendo Switch.
There is a market for these things. Nintendo sells hardware that can play Nintendo Switch games and people buy it. That's a market.
It seems like you're trying to claim that a monopoly isn't a market, but how can that possibly be how antitrust laws work? Your argument is that they don't apply to something if it is a monopoly?
> And they are legally allowed to do that.
That's just assuming the conclusion. Why should it be legal for them to exclude competitors from selling software to their customers? The obviously anti-competitive thing should obviously be a violation of any sane laws prohibiting anti-competitive practices. The insanity is the number of people trying to defend the practice.
Consider what it implies. 20th century GE could have gone around buying houses, installing a GE electrical panel and then selling the houses with a covenant that no one could use a non-GE appliance in that house ever again, or plug in any device that runs on electricity without their permission. They could buy and sell half of all the housing stock in the country and Westinghouse the other half and each add that covenant and you're claiming it wouldn't be an antitrust violation.
Apple wouldn't have been able to get their start because they'd have needed permission from GE or Westinghouse for customers to plug in an Apple II or charge an iPhone and they wouldn't get it because those companies were selling mainframes or flip phones and wouldn't want the competition. If that's not an antitrust violation then we don't have antitrust laws.
> If they did they would be declaring all locked down hardware effectively illegal.
It's fine for hardware to be locked down by and with the specific permission of the person who owns it. But how is it even controversial for the manufacturer locking down hardware for the purpose of excluding competitors to be a violation of the laws against inhibiting competition? It's exactly the thing those laws are supposed to be prohibiting.
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.
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.
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.
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.
That's true. The whole point of an open ecosystem is that you get to decide who you get your software from. You can decide on the official F-Droid repository and get the benefits and drawbacks of a strict open source rule with the F-Droid organization's curation if that's your preference. You can add other repositories with different curation if you prefer that.
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.
Anyone determined enough can break into any house. If not through ingenuitiy, then by a brick to your window. Doesn't mean we shouldn't lock our doors, turn off our lights, and close our curtains anyway.
The fortunate thing is that 99% of people won't bother trying to break your app if it's not dead simple. Advanved security mechanisms to check for backdoors is probably something only billionaire tech companies need to worry about.
You totally misunderstand the threat model. It's not about anybody breaking your app. It's about people making their own apps do things they're not supposed to do.
... and there's always a tradeoff in terms of how much of a deterrent anything is. The app store checks are barely measurable.
The app store checks are barely measureable, yes. Hence why being open source is the best check for any undocumented changes. Even if it's not discovered on FDoid, reports will come out for those who dig. Much easier to view source code than decompiling an APK to analyze.
But at some point there needs to be some level of trust in anything you install. You can't rely on institutions to make sure everything is squeaky clean. They can't even do that on content platforms (or at least, they choose not to afford it).
> 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.
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.
Can you give some examples? I've heard that's a thing, but I'm not familiar with any apps that actually pull it off (reproducible builds are difficult to achieve)
Reproducible builds may be hard to achieve, but that doesn't mean you don't have a list of such builds long enough to crash your browser: https://verification.f-droid.org/verified.html
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?
I trust them, at least a lot more than I do Google, which is a known bad actor, and collaborator with "TLAs". F-Droid has been around for a very long time, if you didn't know. They've built and earned the trust people have in them today.
> Didn’t F-Droid have 20 or so apps that contained known vulnerabilities back in 2022?
Idk what specific incident you're referring to, but since they build apks themselves in an automated way, if a security patch to an app breaks the build, that needs to be fixed before the update can go out (by F-Droid volunteers, usually). In that case, F-Droid will warn about the app having known unpatched vulnerabilities.
Again, this is above and beyond what Google does in their store. Google Play probably has more malware apps than F-Droid has lines of code in its entire catalog.
Right, that's literally the team marking 12 apps as having known vulnerabilities (seems like it was because of a WebRTC vulnerability that was discovered). It's the F-Droid system working as intended to inform users about what they're installing.
You're calling it an incident like it was an attack or something, but it just seems like everyday software development. Google Play and the App Store don't let me know when apps have known vulnerabilities. I think F-Droid is coming out way ahead here.
So Google and Apple are already known to work with US government agencies. This was revealed in the Snowden leaks in 2013, and confirmed on multiple occasions since. Neither Google nor Apple tell you when apps you're downloading from the store contain known vulnerabilities. We know for a fact that both Google Play and the App Store are filled with scams and malware: it's widely documented.
So to my reading F-Droid comes out ahead on every metric you've listed: It has no known associations with US government agencies. They do inform you when your apps have known vulnerabilities. I'm not aware of any cases of scams or malware being distributed through F-Droid.
I highly recommend it. It's the main store I've been using on my phone for probably more than a decade now.
I understand your concern, though your suspicion is a little shortsighted. It can be personally dangerous to volunteer for projects that directly circumvent the control of the establishment.
For the same reason you trust many things. They have a long track record of doing the right thing. As gaining reputation for doing the wrong thing would more or less destroy them, it's a fair incentive to continue doing the right thing. It's a much better incentive that many random developers of small apps in Google's play store have.
However, that's not the only reason to trust them. They also follow a set of processes, starting with a long list of criteria saying what app's they will accept https://f-droid.org/docs/Inclusion_Policy/ That doesn't mean malware won't slip past them on occasion, but if you look at the amount of malware that slips past F-Droid and projects with similar policies like Debian and compare them to other app stores like Google's, Apple and Microsoft there is no comparison. Some malware slips past Debian's defences once every few years. I would not be surprised if new malware isn't uploaded to Google app store every few minutes. The others aren't much better.
The net outcome of all that is the open source distribution platforms like F-Droid and Debian, that have procedures in place like tight acceptance policies and reproducible builds are by a huge margin the most reliable and trustworthy on the planet right now. That isn't saying they are perfect, but rather if Google's goal is to keep their users safe they should be doing everything in their power to protect and promote F-Droid.
> How do I know they aren’t infiltrated by TLAs? (Three Letter Agencies), or outright bad-actors.
You don't know for sure, but F-Droid policies make it possible to detect if the TLA did something nefarious. The combination of reproducible builds, open source and open source's tendency to use source code management systems that provide to audit trail showing who changed every line shine a lot of sunlight into the area. Sunlight those TLA's your so paranoid about hate.
This is the one thing that puzzles me about F-Droid opposition in particular. Google is taking a small step here towards increasing accountability of app developers. But a single person signing an app is in reality a very small step. There are likely tens if not hundreds of libraries underpinning it, developed by thousands of people. That single developer can't monitor them all, and consequently libraries with malware inserted from upstream repositories like NPM or PyPi regularly slips through. Transparency the open source movement mostly enforces is far greater. You can't even modify the amount of whitespace in a line without it being picked up by some version control system that records who did it, why they did it, and when. So F-Droid is complaining about a small increase in enforced transparency from Google, when they demand far, far more from their contributors.
I get that Google's change probably creates some paper-cuts for F-Droid, but I doubt it's something that can't be worked around if both sides collaborate. This blog post sounds like Google is moving in that direction. Hear, hear!
You can run any software you like on Android, if it's open source. You just compile it yourself, and sign it with the limited distribution signature the blog post mentions. Hell, I've never done it, but re-signing any APK with your own signature sounds like it should be feasible. If it is, you can run any APK you want on your own hardware.
Get a grip. Yes it might be possible the world is out to get you. But it's also possible Google is trying to do exactly what they say on the tin - make the world a safer place for people who don't know shit from clay. In this particular case, if they are trying to restrict what an person with a modicum of skillz can do on their own phone it's a piss poor effort, so I'm inclined to think it's the latter. They aren't even removing the adb app upload hole.
>> 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.
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.
See that's what the intent system was originally designed to prevent.
Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
Similarly for the camera.
And in fact, it should have no network access whatsoever (and network should be a user controllable permission, as it used to be — the only reason that was removed is that people would block network access to block ads)
> And in fact, it should have no network access whatsoever (and network should be a user controllable permission, as it used to be — the only reason that was removed is that people would block network access to block ads)
Sure, a QR code scanner can work fine without network.
E.g. it could use the network to check a scanned URL against the "safe browsing API" or to pre-fetch the URL and show me a nice OG preview. You are correct to say you may not need nor want this. But I and others may like such features.
Point is not to discuss wether a QR scanner should have network-access, but to say that once a permission is there for obvious or correct reasons, it can in future easily get abused for other reasons. Without changing the permissions.
My mail-app needs network. Nothing prohibits it from abusing this after an update to pull in ads, or send telemetry to third parties. My sound record app needs microphone permissions. Nothing prohibits it from "secretly" recording my conversations after an update (detectable since a LED and icon will light up).
If you want to solve "app becoming malicious after an update", permissions aren't the tool. They are a tiny piece of that puzzle, but "better permissions" aren't the solution either. Nor is "better awareness of permissions by users".
> See that's what the intent system was originally designed to prevent.
> Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
On the one hand, yes, good point, but it runs into the usual problem with strict sandboxing – it works for the simple default use case, but as soon as you want to do more advanced stuff, offer a nicer UI, etc. etc. it breaks down.
E.g. barcode scanners – yes, technically you could send a media capture intent to ask the camera app to capture a single photo without needing the camera permission yourself, but then you run into the problem that maybe the photo isn't suitable enough for successful barcode detection, so you have to ask the user to take another picture, and perhaps another, and another, and…
So much nicer to request the camera permission after all and then capture a live image stream and automatically re-run the detection algorithm until a code has been found.
The network permission was displayed in the first versions of Android, then removed. I heard (hearsay alert) at the time that it was because so many apps needed it, and they wanted to get rid of always-yes questions. IIRC this happened before the rise of in-app advertising.
If people always answer yes, they grow tired and eventually don't notice the question. I've seen it happen with "do you want to overwrite the previous version of the document you're editing, which you saved two minutes ago?" At that point your question is just poisoning the well. Makes sense, but still, hearsay alert.
As far as I'm concerned they can grant this permission by default. I just want the power to disable it.
A while ago I wanted to scan the NFC chip in my passport. Obviously, I didn't want this information to leave my device.
There are many small utility apps and games that have no reason to require network access. So "need" is not quite the right word here. They _want_ network access and they _want_ to be able to bully users into granting it.
That's a weird justification for granting it by default. But I wouldn't care if I could disable it.
Android doesn't grant this by default, strictly speaking. Rather, an application can enable it by listing it in the application manifest. Most permissions require a question to to the user.
Well, the original intent was to ask the user for permission at installation time, which turned out to be a poor idea after a while. Perhaps you mean that it would have been simple to change the API in some particular way, while retaining compatibility with existing apps? If I remember the timeline correctly, which is far from certain, this happened around the same time as Android passed 100k apps, so a fairly strong compatibility requirement.
I mean, just make it "Granted" by default and give user ability to control it. Permissions API was already broken few times(i.e. Location for bluetooth and granular Files permissions)
> Does Google refuse to veriy their firmware if they offer this feature?
If a manufacturer doesn't follow the Android CDD (https://source.android.com/docs/compatibility/cdd), Google will not allow them to bundle Google's closed source apps (which include the Google Play store). It was originally a measure to prevent fragmentation. I don't know whether this particular detail (not exposing this particular permission) is part of the CDD.
It's not explicitly part of the CDD, but implicitly. The device must support the Android permissions model and is only allowed to extend this implementation using OWN permissions (in a different namespace than 'android'), but not allowed to deviate from it.
INTERNET is a "normal permission", automatically granted at install time if declared in the manifest.
OEMs cannot change the grant behavior without breaking compatibility because:
The CDD explicitly states that the Android security model must remain intact.
Any deviation would fail CTS (Compatibility Test Suite) and prevent Play certification.
Well, apart from the OEM violating the Android Compatibility Definition Document (CDD), failing the Compatibility Test Suite (CTS) and thus not getting their device Play-certified (so not being able to preload all the Google services, there is an economical impact as well:
As OEM you want Carriers to sell your device above everything else, because they are able to sell large volumes.
Carriers make money using network traffic, Google is paying Revenue-Share for ads to Carriers (and OEMs of certain size). Carriers measure this as part of the average revenue per user (ARPU).
--> The device would be designed to create less ARPU for the Carrier and Google and thus be less attractive for the entire ecosystem.
I've been using a similar VPN solution. It works great for apps that absolutely should not be connected, like my keyboard. But it has an obvious downside: you can't use a VPN on your phone while you're using that.
Some apps would use this for loopback addresses, which as far as I know will then need network permission. The problem here is the permission system itself because ironically Google Play is full of malicious software.
And neither Android nor iOS a safer than modern Desktop systems. On the contrary because leaking data is its own security issue.
Yes. Facebook/Meta was using a locally hosted proxy to get info smuggled back without using routes that are increasingly obstructed by things like ad blockers if I recall correctly.
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.
Same for Play Store. I have 2 games and I keep getting offers all the time. The last one offered $2000 for the developer account or a $100 monthly rent.
From their email pitch:
> We’re now offering from $500 to $2000 for a one-time purchase of a developer account that includes apps, or a rental deal starting from $100.
> No hidden conditions — quick process, secure agreement, and immediate payment upon verification.
> We’re simply looking for reliable accounts to publish our client apps quickly, and yours could be a perfect match.
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.
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.
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.
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.
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.
> 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
>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.
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...
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.
> 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
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
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.
> 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.
From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.) The “Why verification is important” section of this blog post goes into a bit more detail (see also the We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer), but ultimately the point is:
there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I don't buy this argument at all that this specific implementation is under pressure from the government - if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps in the first place! Why should apps have access to a user's SMS / RCS? (Yeah, I know it makes onboarding / verification easy and all, if an app can access your OTP. But that's a minor convenience that can be sacrificed if it's also being used for scams by malware apps).
But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy. And that's why they have come with such convoluted implementation that further give them control over a user's device. Obviously some government's too may favour such an approach as they too can then use Google or Apple to exert control over their citizens (through censorship or denial of services).
Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them. This is just the "boil the frog slowly" approach. Once this is normalised, they will make a move to prevent sideloading completely, again, in the future.
> Why should apps have access to a user's SMS / RCS?
It could be an alternative SMS app like TextSecure. One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
It could also be a SMS backup application (which can also be used to transfer the whole SMS history to a new phone).
Or it could be something like KDE Connect making SMS notifications show up on the user's computer.
> One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
When sideloading is barred all that can easily change. If you are forced to install everything from the Google Play Store, Google can easily bar such things, again in the name of "security" - alternate keyboards can steal your password, alternate browsers can have adware / malware, alternate launcher can do many naughty things etc. etc.
And note that if indeed giving apps access to SMS / RCS data is really such a desirable feature, Google could have introduced gate-keeping on that to make it more secure, rather than gate-keeping sideloading. For example, their current proposal says that they will allow sideloading with special Google Accounts. Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
The point is that they want to avoid adding any barriers where a user's private data can't be easily accessed.
> Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
Because then you still need a special Google Account to install your app when it needs to access SMS / RCS.
How about solving this problem in a way that doesn't involve Google rather than the owner of the device making decisions about what they can do with it? Like don't let the app request certain permissions by default, instead require the user to manually go into settings to turn them on, but if they do then it's still possible. Meanwhile apps that are installed from an app store can request that permission when the store allows it, so then users have an easy way to install apps like that, but in that case the app has been approved by Google or F-Droid etc. And the "be an app store" permission works the same way, so you have to do it once when you install F-Droid but then it can set those permissions the same as Google Play.
It's not Google's job to say no for you. It's only their job to make sure you know what you're saying yes to when you make the decision yourself.
>instead require the user to manually go into settings to turn them on, but if they do then it's still possible
They clearly addressed this option in the post, under sufficient social engineering pressure these settings will easily be circumvented. You'd need at least a 24h timeout or similar to mitigate the social pressure.
> They clearly addressed this option in the post, under sufficient social engineering pressure these settings will easily be circumvented. You'd need at least a 24h timeout or similar to mitigate the social pressure.
"Under sufficient social engineering pressure" is the thing that proves too much. A 24h timeout can't withstand that either. Nor can the ability for the user to use their phone to send money, or access their car or home, or read their private documents, or post to their social media account. What if someone convinces them to do any of those things? The only way to stop it is for the phone to never let them do it.
By the time you're done the phone is a brick that can't do anything useful. At some point you have to admit that adults are responsible for the choices they make.
>By the time you're done the phone is a brick that can't do anything useful. At some point you have to admit that adults are responsible for the choices they make.
Absolutely this! It's just nanny state all over again.
This is somehow even worse. It's strictly enforced with no regard for context, you don't have the constitutional rights you have against the government and you can't vote them out.
Markets are supposed to be better because you can switch to a competitor but that only applies when there is actually competition. Two companies both doing the same thing is not a competitive market.
It'd just devolve into security whack a mole about what permissions need those special account or not, ending with basically all of them making it the same as just needing dev verification anyway for anything remotely useful.
And despite that, you assuming that dev verification means no malware. The Play Store requires developers to register with the same verification measures we're talkingand malware is hardly unheard of there.
> alternate keyboards can steal your password, alternate browsers can have adware / malware, alternate launcher can do many naughty things etc. etc.
It's plausible that Google is done some of these things, like doing some sort of data mining on everything that you type for example (steal your password), and many official google apps have ads if you don't pay them
Definitely. All mobile keyboards become keyloggers if you enable the spellcheck feature or autocomplete / suggestion feature or any AI feature on it (because they need to collect data to "improve service"). Apple also has made changes to its mobile OS when it helps data collection. E.g Allowing messenger apps like WhatsApp to integrate with the Phone app ensures that Apple now knows who you call (voice / video) on WhatsApp.
Last year Australians reported losing AU$20 million to phishing attacks, and AU$318 million to scams of all types.
It stands to reason that financial service industry peak bodies are in conversation with governments and digital service providers, including data providers, to try to better protect users.
There are obvious conflicting goals, and the banks / governments can’t really appear to be doing nothing.
And technical users are probably most certainly lacking a representative at the table, and are the group that has the least at stake. Whacko fringe software-freedom extremists, they probably call us.
Yeah. I mean the irony is that the one advantage of having a controlled and monitored app store would be that the entity monitoring it enforces certain standards. Games don't need access to your contacts, ever. If Google Play would just straight up block games that requested unnecessary permissions, it might have value. Instead we have 10,000 match-three games that want to use your camera and read all your data and Google is just fine with that. If the issue was access to personal data, a large proportion of existing apps should just be banned.
I really think all permissions systems need what we had back in xposed/appops days:
Permissions should ~always be "accept (with optional filters)", "deny", and "lie". If the game wants contacts access and won't take no for an answer, I should be able to feed it a lie: empty and/or fake and/or sandboxed data. It's my phone and my data, not the app's.
We had it over a decade ago, xposed supported filtered and fake data for many permissions. It's strictly user-hostile that Android itself doesn't have this capability.
so no, it's not necessary at all. and many apps identify OTPs and give you an easy "copy to clipboard" button in the notification.
but that isn't all super widely known and expected (partly because not all apps or messages follow it), so it's not something you can rely on users denying access to.
Installing apps from sources that are not the Play Store requires a bit of technical knowledge anyway. My grandma is not going to download a random APK and give all the necessary permissions to install it and run it.
no, that is not done via developer mode. When You download or try to open an apk from any app, it asks you if you want to allow it to install apps and send you to the configuration dialog. You still have to validate the app installation manually tbrough another dialog. In that case I usually leave the config dialog open while the app is installed, then disable the app permission right after install because that option is usually not easy to find. I usually only do it once on a new smartphone to install f-droid from a browser then allow f-droid and aurora store permanently.
I think that is the part that should be fixed, users should be able to allow a one time exception to avoid letting that permission activated by mistake. I don't need to allow permanently a web browser to install apps.
> Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them.
This blog post is specifically saying there will be a way to bypass the gatekeeping on Google-blessed Android builds, just as we wanted.
> But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy.
Despite this, they sell some of the most privacy-capable phones available, with the Pixels having unlockable bootloaders. Even without unlocking the bootloader to install something like GrapheneOS, they support better privacy than the other mass market mobile phones by Samsung and Apple, which both admittedly set a low bar.
If they are concerned about malware then one of the obvious solutions would be safe guarding their play store. There is significant less scam on iphone because apple polices their app store. Meanwhile scam apps that i reported are still up on google play store.
>Why should apps have access to a user's SMS / RCS?
can you imagine the outrage from all the exact same people who are currently outraged about develeloper verification if google said they were cutting off any third-party app access to SMS/RCS?
> if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps
Then you'd have the other "screaming minority" on HN show up, the "antitrust all the things" folks.
Your first link shows a graph that indicates more than 50% of Americans believe there is at least some competition, or a lot of competition; and that less than 1/3rd believe there is not enough, or no, competition in every sector of the economy that would be relevant to this discussion.
And that most Americans believe that bigger companies tend to have lower prices than smaller ones.
It’s not particularly clear then that there should be a lot of motivation to change things.
You're choosing the questions that have framing issues:
> more than 50% of Americans believe there is at least some competition, or a lot of competition in every sector of the economy that would be relevant to this discussion.
We're talking about Google and Apple but the relevant category would be "technology companies". Do phone platforms or mobile app distribution stores have "a lot of competition"? It's hard to see how anybody could think that. Do games and AI and web hosting? Sure they do. But they're lumping them all together.
They're also using "some competition" as the second-to-highest amount of competition even though that term could reasonably apply to a market where one company has 90% market share but not 100%, and it's confusingly similar to "not much competition". And they're somehow showing oil and gas as having less competition than telecommunications when oil and gas is a textbook fungible commodity and telecommunications is Comcast. That question has issues.
> And that most Americans believe that bigger companies tend to have lower prices than smaller ones.
This is the thing where Walmart has lower prices than the mom and pop. That doesn't imply that Walmart has better quality or service than a smaller company, and it doesn't imply that Walmart is operating in a consolidated market. Retail is objectively competitive in most areas.
Whereas when a big company is in a consolidated market, "big companies tend to have lower prices" doesn't hold and you get Google and Apple extracting 30%.
Moreover, the relevant part of that link was this part: More than two thirds of people, including the majority of both parties, support antitrust laws, six times as many people think they're not strict enough than think they're too strict and significantly more people agree with "the government should break up big tech" than disagree.
> On the other hand, maybe if the railways weren’t broken up the USA might have been crisscrossed with high speed rail by now.
Eh. The rails themselves are a natural monopoly in the same way roads are. It's one of the few things it makes sense to have the government build, or at least contract to have someone build, and then provide to everyone without restriction.
Meanwhile train cars and freight hauling and passenger service aren't any more of a natural monopoly than taxis or trucks. They get monopolized if someone is allowed to leverage a monopoly over the tracks into a monopoly over the rest of it, but that's unnecessary and undesirable. Separating them out allows the market that can be competitive to be competitive. Which is the same reason you don't want a tech monopoly leveraging it into control over ancillary markets that could otherwise be competitive.
There are two main reasons train service in the US is a shambles. The first is that the population density is too low, especially in the west. How many people do you expect to be riding a train from Boise to Des Moines on a regular basis? And the second is that truck drivers don't like freight rail, car companies don't like passenger rail and oil companies don't like either one, and they all lobby against anything that would make it better in the parts of the country where it could actually work. It's hard to make something good when there are millions of voters and billions of dollars trying to get it to suck.
Google have their own reasons too. They would love to kill off YouTube ReVanced and other haxx0red clients that give features for free which Google would rather sell you on subscription.
Just look at everything they've done to break yt-dlp over and over again. In fact their newest countermeasure is a frontpage story right beside this one: https://news.ycombinator.com/item?id=45898407
I can easily believe that Google's YouTube team would love to kill off such apps, if they can make a significant (say ≥1%) impact on revenue. (After all, being able to make money from views is an actual part of the YouTube product features that they promise to “creators”, which would be undermined if they made it too easy to circumvent.)
But having seen how things work at large companies including Google, I find it less likely for Google's Android team to be allocating resources or making major policy decisions by considering the YouTube team. :-) (Of course if Android happened to make a change that negatively affected YouTube revenue, things may get escalated and the change may get rolled back as in the infamous Chrome-vs-Ads case, but those situations are very rare.) Taking their explanation at face value (their anti-malware team couldn't keep up: bad actors can spin up new harmful apps instantly. It becomes an endless game of whack-a-mole. Verification changes the math by forcing them to use a real identity) seems justified in this case.
My point though was that whatever the ultimate stable equilibrium becomes, it will be one in which the set of apps that the average person can easily install is limited in some way — I think Google's proposed solution here (hobbyists can make apps having not many users, and “experienced users” can opt out of the security measures) is actually a “least bad” compromise, but still not a happy outcome for those who would like a world where anyone can write apps that anyone can install.
I would like a world where I have the final say over whether I should have a final say.
One way to achieve this is to only allow sideloading in "developer mode", which could only be activated from the setup / onboarding screen. That way, power users who know they'll want to sideload could still sideload. The rest could enjoy the benefits of an ecosystem where somebody more competent than their 80-year-old nontechnical self can worry about cybersecurity.
Another way to do this would be to enforce a 48-hour cooldown on enabling sideloading, perhaps waived if enabled within 48 hrs of device setup. This would be enough time for most people to literally "cool off" and realize they're being scammed, while not much of an obstacle for power users.
You can sideload, I mean INSTALL, software on any linux desktop. Yet there are still tons of people saying that desktop linux has gotten good enough for most of everyone's grandma to daily-drive.
When everyone's Grandma is running Linux then the Indian scammers will know how to trick Grandma into thinking dmesg spam is "a virus" and just install this totally-not-malware, just like they do with the windows event viewer.
In other words, it's not any quality of Linux other than how niche it is.
It's an excellent example of the fruitlessness of technical solutions to people problems. Some people are just destined to get scammed, and it isn't worth throwing away General Purpose Computing to try to help them. Be present in Grandma's life and she won't be desperate to trust the nice man on the phone just to have someone to talk to. If it weren't this it would be iTunes gift cards, or Your Vehicle's Extended Warranty, or any number of other avenues.
The actual stopping power here is that any grandma who uses a Linux desktop has a family member (or other contact) who helps with technical matters. They've been educated about internet & phone scams, and will immediately call their technical contact when anything is suspicious.
This becomes a problem when someone asks me for help with their phone and I want to point them to some apps from F-Droid to reduce their exposure to surveillance marketing.
Of course that's a side effect Google probably wouldn't be sad about.
These two solutions wouldn't work for me. My phone is covered, I use a custom ROM, but I like being able to help people install cool stuff that's not necessarily on the Play store, organically, without planning.
I'm not sure I like the idea of "you have to wait 48 hours now for sideloading in case you are an idiot". Most idiots will then have sideloading on after 48 hours and still get hit with the next scam anyway.
You’re still proving the point above, which is ignoring the fact that the restriction is specifically targeted at a small number of countries. Google is also rolling out processes for advanced users to install apps. It’s all in the linked post (which apparently isn’t being read by the people injecting their own assumptions)
Google is not rolling this out to protect against YouTube ReVanced but only in a small number of countries. That’s an illogical conclusion to draw from the facts.
"Android" is really a lot of different code but most of it is the Apache license or the GPL. Google Play has its own ToS, but why should that have to do with anything when you're not using it?
iPhone has always been that way (try installing an .ipa file that's not signed with a valid apple developer certificate). For Google forced app verification is a major change. Xbox I don't know..
> Yeah, let's ask the Debian team about installing packages from third party repos.
Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows.
Hence you don't realize how good of an argument it is, because you even bamboozled yourself without realizing it.
It gets a worse argument if we want to discuss Qubes and other distributions that are actually focused on security, e.g. via firejail, hardened kernels or user namespaces to sandbox apps.
"Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows."
This is only true if you use Secure boot. It is already not needed and insecure so should be turned off. Then any OS can be installed.
> This is only true if you use Secure boot. [...] so should be turned off. Then any OS can be installed.
You can only turn off Secure Boot because Microsoft allows it. In the same way Android has its CDD with rules all OEMs must follow (otherwise they won't get Google's apps), Windows has a set of hardware certification requirements (otherwise the OEM won't be able to get Windows pre-installed), and it's these certification requirements that say "it must be possible to disable Secure Boot". A future version of Windows could easily have in its hardware certification requirements "it must not be possible to disable Secure Boot", and all OEMs would be forced to follow it if they wanted Windows.
And that already happened. Some time ago, Microsoft mandated that it must not be possible to disable Secure Boot on ARM-based devices (while keeping the rule that it must be possible to disable it on x86-based devices). I think this rule was changed later, but for ARM-based Windows laptops of that era, it's AFAIK not possible to disable Secure Boot to install an alternate OS.
I agree with you and run with it disabled myself, but some anti-cheat software will block you if you do this. Battlefield 6 and Valorant both require it.
Turning off UEFI secure boot on a PC to install another "unsecure distribution"
vs.
Unlocking fastboot bootloader on Android to install another "unsecure ROM"
... is not the exact same language, which isn"t really about security but about absolute control of the device.
The parallels are astounding, given that Microsoft's signing process of binaries also meanwhile depends on WHQL and the Microsoft Store. Unsigned binaries can't be installed unless you "disable security features".
My point is that it has absolutely nothing to do with actual security improvements.
Google could've invested that money instead into building an EDR and called it Android Defender or something. Everyone worried about security would've installed that Antivirus. And on top of it, all the fake Anti Viruses in the Google Play Store (that haven't been removed by Google btw) would have no scamming business model anymore either.
"... is not the exact same language, which isn"t really about security but about absolute control of the device.
The parallels are astounding, given that Microsoft's signing process of binaries also meanwhile depends on WHQL and the Microsoft Store. Unsigned binaries can't be installed unless you "disable security features".
My point is that it has absolutely nothing to do with actual security improvements."
While it's possible to install and use Windows 11 without Secure Boot enabled, it is not a supported configuration by Microsoft and doesn't meet the minimum system requirements. Thus it could negatively affect the ability to get updates and support.
> It is already not needed and insecure so should be turned off.
The name “Secure Boot” is such an effective way for them to guide well-meaning but naïve people's thought process to their desired outcome. Microsoft's idea of Security is security from me, not security for me. They use this overloaded language because it's so hard to argue against. It's a thought-terminating cliché.
Oh, you don't use <thing literally named ‘Secure [Verb]’>?? You must not care about being secure, huh???
Dear Microsoft: fuck off; I refuse to seek your permission-via-signing-key to run my own software on my own computer.
Also Secure boot is vulnerable to many types of exploits. Having it enabled can be a danger in its self as it can be used to infect the OS that relies on it.
I do not want to be in the business of key management. This is not something that needed encryption. More encryption ≠ better than.
I also dual-boot Windows and that's a whole additional can of worms; not sure it would even be possible to self-key that. Microsoft's documentation explicitly mentions OEMs and ODMs and not individual end users: https://learn.microsoft.com/en-us/windows-hardware/manufactu...
Name a single prevented bootkit that wasn't able to avoid the encryption and signature verification toolchain altogether.
Malware developers know how to avoid this facade of an unlocked door.
Users do not.
That's the problem. It's not about development, it's about user experience. Most users are afraid to open any Terminal window, let alone aren't even capable of typing a command in there.
If you argue about good intent from Microsoft here, think again. It's been 12 years since Stuxnet, and the malware samples still work today. Ask yourself why, if the reason isn't utter incompetence on Microsoft's part. It was never about securing the boot process, otherwise this would've been fixed within a day back in 2013.
Pretty much all other bootkits also still work btw, it's not a singled out example. It's the norm of MS not giving a damn about it.
The countries that go after Google are the first wave, they're applying these restrictions globally not much later.
The linked post is full of fluff and low on detail. Google doesn't seem to have the details themselves; they're continuing with the rollout while still designing the flow that will let experienced users install apps like normal.
yt-dlp's days are fairly numbered as Google has a trump card they can eventually deploy: all content is gated behind DRM. IIRC the only reason YouTube content is not yet served exclusively through DRM is to maintain compatibility with older hardware like smart TVs.
Youtube already employs DRM on some of their videos (notably their free* commercial movies). if you try to take a screenshot, the frame is blacked out. this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction; detection of DRM protection and applying the bypass is likely trivial for the kinds of people already writing scripts and programs utilizing yt-dlp. the css method of bypass has been widely disseminated for years (over a decade?), but programmers love puzzles, so a sequel to current DRM implementation seems justified. YT could also substantially annoy me by expiring their login cookies more frequently; I think I have to pull them from my workstation every month or two as-is? at some point, they could introduce enough fragility to my scripts where it's such a bother to maintain that I won't bother downloading/watching the 1-3 videos per day I am today -- but otoh, I've been working on a wasm/Rust mp4 demuxer and from-scratch WebGL2 renderer for video and I'm kind of attached to seeing it through (I've had project shelved for ~3 weeks after getting stuck on a video seek issue), so I might be willing to put a lot of effort into getting the videos as a point of personal pride.
the real pain in the butt in my present is Patreon because I can't be arsed to write something separate for it. as-is, I subscribe to people on Patreon and then never bother watching any of the exclusive content because it's too much work. some solutions like Ghost (providing an API for donor content access) get part of the way to a solution, but they are not themselves a video host, and I've never seen anyone use it.
> this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction
That's not real DRM then. The real DRM is sending the content such that it flows down the protected media path (https://en.wikipedia.org/wiki/Protected_Media_Path) or equivalent. Userspace never sees decrypted plaintext content. The programmable part of the GPU never seen plaintext decrypted content. Applying some no-op blur filter would be pointless since anything doing the blur couldn't see the pixels. It's not something you can work around with clever CSS. To compromise it, you need to do an EoP into ordinarily non-programmable scanout of the GPU or find bad cryptography or a side channel that lets you get the private key that can decode the frames. Very hard.
Is this how YT works today? Not on every platform. Could it work this way? Definitely. The only thing stopping them is fear of breaking compatibility with a long tail of legacy devices.
Something I've never understood about DRM is, if the content is ultimately played on my device, what stops me from reverse engineering their code to make an alternative client or downloader? Is it just making it harder to do so? Or is there a theoretical limit to reverse engineering that I'm not getting? Do they have hardware decryption keys in every monitor, inside the LCD controller chip?
in short and simple terms, those parasites colluded with hardware manufacturers and put a special chip in your computer and monitor that runs enslavement software
without opening it up physically there is no way to make it stop or get the raw stream before it's displayed
This. Some ways back I actually purchased bluray recording device only to learn that its firmware is deliberately crippled to accommodate someone's business model. There are people who do the unsung hero work, but those types of skills are not exactly common and a business asshole is a dime a dozen any century you want to pick.
Yes, the decryption happens in hardware. For your OS (and potential capturing software running on it) the place where you see the video is just an empty canvas on which the hardware renders the decrypted image.
All levels of Widevine are cracked, but only the software-exclusive vulnerabilities are publicly available. It's only used for valuable content though (netflix/disney+/primevideo), so it might still work out for YouTube as no one will want to waste a vulnerability on a Mr. Beast slop video.
The reason they have different levels is that the DRM pitchmen got tired of everyone making fun of their ineffective snake oil, so they tried to make a version that was harder to break at the cost of not supporting most devices.
Naturally that got broken too, and even worse, broken when it's only supported by a minority of devices and content, because the more devices and content it's used for the easier it is to break and the larger the incentive to do it.
If you tried to require that for all content then it would have to be supported by all devices, including the bargain bin e-waste with derelict security, and what do you expect to happen then?
I don’t have any personal links but know that there is a constant cat-and-mouse game of cracking Widevine devices for their L1 keyboxes and using them on high-value content (as mentioned).
That’s why a lot of low end Android devices often have problems playing DRMed content on the Web: their keyboxes got cracked open and leaked wide enough for piracy that they got revoked and downgraded down to L3.
Too bad that I'm going iPhone if Google removes sideloading and now I know about revanced so they aren't getting any more than the zero dollars that youtube and youtube music are worth from me
If I'm going to live in a walled garden it's going to the fanciest
If they're going to reduce me to a user, iOS is the better choice. I had an iPhone before and it's a picture taking, instagram, social media machine with iMessage—bringing the console wars to normies since inception.
Because the hardware is so constrained an iphone lasts forever compared to a similar android. My two year old pixel is slow now, but I know people completely happy with a five year old iphone. Pause, I checked and the oldest iphone that receives updates is an iphone 11, which is the exact model I had before going back to android.
I have multiple generations of pixel phones and could not tell the difference in performance between them in basic tasks. Maybe because i installed GrapheneOS which makes both stock android and ios feel like a bloat and spyware riddled toy.
Developers of these apps would have little motivation if the maximum audience size was cut down to the very few who would use adb. The ecosystem would die.
That uses a workaround based on WiFi debugging even though it's all local. It doesn't run if you're not connected to a trusted WiFi network, you have to set it all up when connecting to a new network, etc.
Not only users are not connected to WiFi all the time, but in many developing countries people often have no WiFi at home and rely on mobile data instead. It's a solution, but not a solution for everyone or a solution that works all the time.
And how do you estimate the audience that even cares about those issues?
I think number of people caring about alternative app stores, F-droid or whatever is very similar to the number of people willing to use adb if necessary, so rather small.
But the ecosystem exists, regardless of what the absolute number is, and it would be bad to lose it. If the platform was more open like Windows the ecosystem would grow, if it was less open like iOS it would die.
> In early discussions about this initiative, we've been encouraged by the supportive initial feedback we've received.
> the Brazilian Federation of Banks (FEBRABAN) sees it as a “significant advancement in protecting users and encouraging accountability.” This support extends to governments as well
> We believe this is how an open system should work
Google isn't "hinting" that they're doing this under pressure, that announcement makes it quite clear that this is Google's initiative which the governments are supportive of because it's another step on a ratcheting mechanism that centralizes power.
> because the governments of countries where such scams are widespread will hold Google responsible
Your comment is normalizing highly problematic behavior. Can we agree that vague "pressure from the government" shouldn't be how policies and laws are enacted? They should make and enforce laws in a constitutional manner.
If you believe that it's normal for these companies and government officials to make shadow deals that bypass the rule of law, legal procedures, separation of powers and the entire constitutional system of governance that our countries have, then please drop the pretense that you stand for democracy and the rule of law (assuming that you haven't already).
Otherwise we need to be treating it for what it is - a dangerous, corrupt, undemocratic shift in our system of governance.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
What, the same way they hold Microsoft responsible for the fact that you can install whatever you want in Windows?
Obviously, there can exist an easy way for a non-technical user to install unverified apps, because there has always been one.
This is actually a good point, and something I've been wondering about too. What changed between the 90s and now, that Microsoft didn't get blamed for malware on Windows, but Google/Apple would be blamed now for malware on their devices? It seems that the environment today is different, in the sense that if (widespread) PCs only came into existence now, the PC makers would be considered responsible for harms therefrom (this is a subjective opinion of course).
Assuming this is true (ignore if you disagree), why is that? Is it that PCs never became as widespread as phones (used by lots of people who are likely targets for scammers and losing their life savings etc), or technology was still new and lawmakers didn't concern themselves with it, or PCs (despite the name) were still to a large extent "office" devices, or the sophistication of scammers was lower then, or…? Even today PCs are being affected by ransomware (for example) but Microsoft doesn't get held responsible, so why are phones different?
What changed is that Apple made the masses familiar with the concept of installing software only from a store with a vetting process. For short, the walled garden. That was mostly an alien thing in the world of software. All of us grew with the possibility of getting an installer and install it whenever we wanted. There were some form of protections against piracy but nothing else.
Once Apple created the walled garden every other company realized how good it could be for their bottom lines and attempted to do the same thing.
So, to answer your question, Microsoft got blamed for viruses and made fun of but there wasn't a better way in the mainstream. There is one now.
PCs will resist this trend for a while because it's also mainstream that they are used to do work. Many people use a PC every day with some native application from a company they have a direct contract with. For example: accounting software. Everybody can add another example from their own experience. Those programs don't come from the Windows store and it will be a long term effort to gatekeep everything into the store or move them into a web browser.
The .NET MAUI technology we had a post about yesterday is one of the bricks that can build the transition.
> So, to answer your question, Microsoft got blamed for viruses and made fun of but there wasn't a better way in the mainstream. There is one now.
I don't think App Store is a better way.
From my point of view, people keep mistaking the actual progress - generalised sandboxing and reduced API surface - with the major regression - controlled distribution. At the beginning of the App Store, when the sandboxing and APIs were poor, they were frequent security issues.
Apple marketing magic is somehow convincing people that it's their questionable veting which made things secure and not the very real security innovations.
I'm with you and personally I boycott Apple because of the walled garden, for what it's worth. However it is a better way (a more convenient way?) for companies to make money and it gave an idea to legislators and regulators. Now they expect that the owner of the OS can decide what runs and what does not run on their OS and be made accountable for it.
Windows 95 (and patronage) had become a shitshow. It’s easy to forget how much time us tech types were spending “fixing” uncle’s PC that somehow got malware on it. How we touted Linux as an escape from the hellscape of crapware.
It was into this void that the “everything seems new” iPhone stepped and ventured out in a different course. I’m neither speaking for or against apples normalization of an App Store as a primary source of updates, just recalling the way things were, and positing that Apple was trying a different approach that initially offered a computing platform that wasn’t the hellscape that MS platform was quickly becoming.
Windows 95 was fundamentally broken as if I recall correctly there was much less security features (accounts, file permissions, etc.). Nowadays there are less problems with it.
Its not that it was broken, its that security was not really a thing. You had your antivirus to protect you from people adding stuff to discs, but thats it. Windows 95 was just an exe file in the windows folder that you could run from DOS.
Windows NT / OS2 did have more security as it was meant for shared environments, but even there, corporations ended up using stuff like Novell NetWare to get the actual networking services.
Windows 2000 was the first version of consumer windows based on the NT kernel instead of the DOS / Windows 95/98/ME based systems. I still remember running around the office updating windows 2000 machines to service pack 4 to protect us against the first real massive virus "ILOVEYOU".
Edit: Still on first coffee, sorry about the ramblings
Sure, my point was that even if iPhone ecosystem is more secure than Windows 95, I do not think this is due mostly to the "walled garden", but because (as you mention) Windows 95 just did not care about security at all. By the time iPhone appeared the security of Windows systems (2000 and later) had already improved (even if not perfect) and there was a possibility to configure it more "locked down", if you wanted.
I always blamed Microsoft for Windows insecurity. But seriously, Windows did not have any vetting process for apps and apps didn't really have access to money. Google's problem is that they claim Android is a secure way to do banking but it isn't.
Nah, that's the beauty of it. Liberal principles make a much more robust political foundation that post-liberal principles. The US is known for the former despite current flirtations with the latter. However, liberal principles aren't tied to any one country. Fortunately for us!
It's not a separate problem, Google are actively suppressing any possibility of open mobile hardware. They force HW manufacturers to keep their specs secret and make them choose between their ecosystem and any other, not both. There's a humongous conflict of interests and they're abusing their dominating position.
> They force HW manufacturers to keep their specs secret
Spoken like someone who has never ever worked with any hardware manufacturers. They do not need reasons for that. They all believe their mundane shit is the most secret-worthy shit ever. They have always done this. This predates google, and will outlive it.
Given how antitrust is not really working right now I would say this is debatable. Also monopolies in the past were forced to do various things to keep their status for longer.
> I bought the hardware, therefore I have the right to modify and repair. Natural right, full stop.
There is absolutely nothing "natural" about trading your pile of government promises for the right to call government men with guns and sticks if you are alienated from the option to physically control an object. Your natural right is to control what you can defend.
Rights are what we decide them to be. Or rather, what people in power decide them to be, i.e. people who hold and issue large amounts of government promises, and recruit and direct the most men with guns and sticks.
Oh, so you're good with everyone having the "natural right" to turn handguns into automatic weapons simply because they find themselves in possession of the correct atoms? How about adding a 3rd story on the top of your house without needing a permit or structural evaluation?
Note that adding "full stop" pointlessly to the end of sentences does not strengthen your argument.
I don't think it's illegal to do whatever you want with your phone. That doesn't mean google legally is required to make it easy or even possible. That being said I ethically they should allow it, and considering their near monopoly status they should be forced to keep things open. In fact there should be right to repair laws too.
I suppose you have the right to do whatever you want with it, including zapping it in the microwave or using it as a rectal probe. I am not sure that right extends are far as forcing companies to deliver a product to your specifications (open software, hardware, or otherwise)
You’re still missing the point the comment is making: In countries where governments are dead set on holding Google accountable for what users do on their phones, it doesn’t matter what you believe to be your natural right. The governments of these countries have made declarations about who is accountable and Google has no intention of leaving the door open for that accountability.
You can do whatever you want with the hardware you buy, but don’t confuse that with forcing another company to give you all of the tools to do anything you want easily.
That's deflection, there's Google blocking users from installing apps and there's OP insinuating that it might be because of governments coercion but there's no evidence to support this. Scammers pay Google to show ads to install apps, that's what the governments are holding Google responsible and it won't change with blocking installing apps.
Malicious app delivery goes beyond Google ads. In Singapore, most scam app installs are from social engineering, e.g. install new app to receive payment, install new app to buy something for cheap.
I’m amazed at how gullible some people are but that’s how it is.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
You can also view this as a "tragedy of the commons" situation. Unverified apps and sideloading is actively abused by scammers right now.
> Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I get that viewpoint and I'm also very glad an opt-out now exists (and the risk that the verification would be abused is also very real), but yeah, more information what to do against scammers then would also be needed.
It's not possible to provide a path for advanced users that a stupid person can't be coerced to use.
Moreover, it's not possible to provide a path for advanced users that a stupid person won't use by accident, either.
These are what drive many instances of completely missing paths for advanced users. It's not possible to stop coercion or accidents. It is literally impossible. Any company that doesn't want to take the risk can only leave advanced users completely out of the picture. There's nothing else they can do.
Google will fail to prevent misuse of this feature, and advanced users will eventually be left in the dust completely as Google learns there's no way to safely provide for them. This is inevitable.
Android could have, for example, a 24 hour "cooling off" period for sideloading approval. Much like some bootloader unlocking - make it subject to a delay.
That immediately takes the pressure off people who are being told that their bank details are at immediate risk.
> Android could have, for example, a 24 hour "cooling off" period for sideloading approval.
And, to prevent the scammer from simply calling back once the 24 hours are gone, make it show a couple of warnings (at random times so they can't be predicted by the scammer) explaining the issue, with rejecting these warnings making the cooling off timer reset (so a new attempt to enable would need another full 24 hours).
The people gullible enough to fall for a scam like that are also gullible enough to follow more instructions 24 hours later. I think if you could force a call to the phone and have an agent or even AI that talks to user and makes sure no scam is involved then gives an unlock code based on deviceID or something. But that would cost money and scammers would work around it anyway.
>It's not possible to provide a path for advanced users that a stupid person can't be coerced to use.
I actually think you might be wrong about this? Imagine if Google forced you to solve a logic puzzle before sideloading. The puzzle could be very visual in nature, so even if a scammer asked the victim to describe the puzzle over the phone, this usually wouldn't allow the scammer to solve it on the victim's behalf. The puzzle could be presented in a special OS mode to prevent screenshots, with phone camera disabled so the puzzle can't be photographed in a mirror, and phone call functionality disabled so a scammer can't talk you through it as easily. Scammers would tell the victim to go find a friend, have the friend photograph the puzzle, and send the photo to the scammer. At which point the friend hopefully says "wait, wtf is going on here?" (Especially if the puzzle has big text at the top like "IF SOMEONE ASKS YOU TO PHOTOGRAPH THIS, THEY ARE LIKELY VICTIM OF AN ONGOING SCAM, YOU SHOULD REFUSE", and consists of multiple stages which need to be solved sequentially.)
In addition to logic puzzles, Google could also make you pass a scam awareness quiz =) You could interleave the quiz questions with logic puzzle stages, to help the friend who's photographing the puzzle figure out what's going on.
I guess this could fail for users who have two devices, e.g. a laptop plus a phone, but presumably those users tend to have a little more technical sophistication. Maybe display a QR code in the middle of the puzzle which opens up scam awareness materials if photographed?
Or, instead of a "scam awareness quiz" you could could give the user an "ongoing scam check", e.g.: "Did a stranger recently call you on the phone and tell you to navigate to this functionality?" If the user answers yes, disable sideloading for the next 48 hours and show them scam education materials.
It would also fail for users who are differently abled. That sounds like an absolute nightmare for accessibility. Good news for preventing scams, but bad news for anyone without full mental and physical faculties.
I'm not sure why you couldn't make the flow I describe just as accessible as anything else in Android? But I'll grant your premise and respond anyways.
If the user lacks full mental faculties, they are part of the userbase we need to protect from scams. Most likely, a user without full mental faculties who is trying to sideload will be a scam victim.
If the user lacks the necessary physical faculties to "solve a puzzle on their phone", they probably get help from friends regularly; a friend should be able to help with sideloading. Enabling sideloading should be a one-time operation right?
Notice though that we don't forbid people from withdrawing cash from the bank in order to prevent this.
Warning about scams is fine, as is taking steps to make it harder, but once you start trying to completely remove the agency of mentally sound adults "for their own good" then we have a problem.
It seems to me if you raise the difficulty enough, and lower the success rate enough, at some point a given scam stops being economical. https://news.ycombinator.com/item?id=45913529
It's waaaay more complicated to download ADB and side load a random APK.
This is either a move towards tighter control of the platform or a government request. And somewhat ironic, given that iOS is being pressured to be a bit more open.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
But it is perfectly fine to sell crypto and other complex financial assets to kids and other people that do not know they are from apps in the Play store.
If "safety" takes control from you then it is implemented. If real safety puts profits in danger then it is fight against. Quite a dystopia.
Then let them do that for those countries. Not for everyone. I'm not in any of those autocratic countries. Or offer an opt out in the countries where this isn't a thing. Using adb is not really great for doing updates.
And also, I'm the owner of my device. Not my country.
I'm pretty sure Brazil doesn't have a law saying that Google must forbid sideload. I'm sure that government (be it President, Central Bank etc) doesn't pressure Google about it.
I'm sure some private actors (for example, banks) would love that smartphones are as tight as possible (reason: [0]). Perhaps the same reason applies to Google [1]. But no, "Brazil" isn't demanding that from Google.
[0]: consider that some virus (insecure apps, for example) could somehow steal information from bank apps (even as simple as capture login information). The client might sue the bank and the bank might have to prove that their app is secure and the problem was in the client's smartphone.
[1]: the client, the bank etc might complain to Google that their Android is insecure
Aha - that is a much better explanation than I assumed, aka "the people forced Google to behave". So Google is scared of having to pay fines or having their CEOs end up in jail. I actually think there should be a new rule - easy-jail mode for CEOs globally. Does not have to be long but say, a few days in jail for ignoring the law, and right hold the CEOs responsible for that. You earn a lot of money, so you also gotta take the risk.
> From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.)
In ye goode olde times, the US would have threatened invasion and that would have been the end of it.
Half /s, because it actually used to be the case that the US government exercised its massive influence (and not just militarily) onto other countries for the benefit of its corporations and/or its citizens... these days, the geopolitical influence of the US has been reduced to shreds and the executive's priorities aren't set by doing what's (being perceived as being) right but by whomever pays the biggest bribes.
Why can't they just put up a big, red warning: "Never enable software installation if someone asks you to (over the phone or via message). If you're unsure, check out this article on scams."?
> "Never enable software installation if someone asks you..."
Imagine a situation in which a frightened, stressed user sees such a message on their screen. Meanwhile, a very convincing fake police officer or bank representative is telling them over the phone that they must ignore this message due to specific dangerous emergency situation to save the money in their bank account. Would the user realize at that moment that the message is right and the person on the phone is a thief? I'm not so sure.
What if there is a 12-hour delay to unlock "power user mode", and during that entire 12-hour unlock period, the phone keeps displaying various scam education information to help even an unsophisticated user figure out what's going on? Surely Google can devote a few full-time employees to keeping such educational materials up to date, so they ideally contain detailed descriptions of the most common scams a user is going to be subject to at any given time.
This would help for sure. Ideally, the phone should stay in "expert mode" for a limited time only, like 1 hour.
However, there is still a danger that scammers will call after 12 hours, and they will be more convincing than educational material (or the user may not have read it).
> However, there is still a danger that scammers will call after 12 hours
It is unlikely it will work. Scammers are talking all the time and creating a sense of urgency, people have issues to think and listen at the same time, and they tend to drop thinking completely when in a haste. 12 hours of a break will give the victim time to think at least. Probably it will give time to talk about it with someone, or to google things.
> because the governments of countries where such scams are widespread will hold Google responsible.
How many virus infections and scams was Microsoft held responsible for? What about Red Hat, or Debian?
And at least let Google plainly state this, instead of inventing legal theories based on vague hints from their press releases, to explain why their self-serving user-hostile actions are actually legally mandatory.
> the governments of countries where such scams are widespread will hold Google responsible.
This argument is FUD at this point.
Sovereign governments have ways to make clear what they want: they pass laws, and there needs to be no back deal or veiled threats. If they intend to punish Google for the rampant scams, they'll need a legal framework for that. That's exactly how it went down with the DMA, and how other countries are dealing with Google/Apple.
Otherwise we're just fantasizing on vague rumors, exchanges that might have happened but represent nothing (some politicians telling bullshit isn't a law of the country that will lead to enforcement).
This would be another story if we're discussing exchanges with the mafia and/or private parties, but here you're explicitely mentionning governments.
That's a disingenuous argument though: they are in that position because they chose to make themselves the only way that a 'normal' user is able to install software on these devices. If not for that these governments wouldn't have a point to apply pressure on in the first place.
BTW, Stallman and FSF have been saying this the whole time - if you become the only gatekeeper, don't be surprised when government people show up and force you to ban apps or users from your platform.
This is just lies spread by the very own people that created this system in the first place, if PCs can have apps without "verification" then so can a phone.
Imagine if they tried to hold the entire world to the standards of Russia, China or North Korea. Yet they don't. This is just an excuse from them, or else they would only enable it in those countries. They don't hold the entire world to Chinese standards so why should they hold them to Brazilian standards? The only reasonable answer is: they also like those standards.
No, then the results of many google web searches would not put scam sites at the top over the official sites. Google is fine with people being scammed. As long as they get their cut. Large corporations don't have empathy.
Meta ads too. It’s bonkers the type of ads they approve, straight up scams or obvious misinformation (some prominent figure is in jail! Click here to find out!)
From what I've seen, millions lost to scams are with social engineering; through cold calls masquerading as the authorities, phishing, pig butchering; plenty of scam apps on the Play store harvesting data as well, but not a single real life instance of malware installed outside the officially sanctioned platform.
> because the governments of countries where such scams are widespread will hold Google responsible.
This is the unsurprising consequence of trying to hold big companies accountable for the things people do with their devices: The only reasonable response is to reduce freedoms with those devices, or pull out of those countries entirely.
This happened a lot in the early days of the GDPR regulations when the exact laws were unclear and many companies realized it was safer to block those countries entirely. Despite this playing out over and over again, there are still constant calls on HN to hold companies accountable for user-submitted content, require ID verification, and so on.
Yes. The same goes with payment processing. I hate visa/mastercard as much as the next person. But if the court says they're accountable for people who buy drug/firearm/child porn, then it seems to be a quite reasonable reaction for them to preemptively limit what the users can buy or sell.
The government(s) have to treat the middlemen as middlemen. Otherwise they are forced to act as gatekeepers.
These two things are not the same. The GDPR afforded rights to common people. Those companies that would pull out are the ones that were abusing data that was never theirs and could no longer do so.
Nah. I know of several startups that had nothing but anonymous telemetry and they blocked all Europe because there was no capacity for compliance. I was at an incubator at the time and the decision was unanimous across a dozen or so companies. It’s not like anyone was going to lose out on VC money from that market
And it's a bit hard to believe that these several startups functioned without ever collecting names, emails, IP, phone number, or address of any lead or customer ever.
Maybe they did? Who knows? Never gonna find out because no one had time to look into it. It certainly wasn’t done with malicious intent, perhaps by accident or oversight, which is likely the situation in most small companies.
If nobody pushed back on anything we'd all be subjected to the laws of the worst country on earth, because big tech companies want to do business there, and putting an if/else around the user's country takes effort.
Excuse me, what exactly is "sideloading"? If I wanted to run third-party code on a system through the means that's supported by the system, then it should be called "running", it's a part of normal operation.
The word "sideload" made it sound like you're smuggle something you shouldn't onto the system. Subtle word tricks like this could sneak poisons into your mind, be watchful.
You can't make people just stop using a word. The best course of action is to reclaim it. Look at us, we're posting on Hacker News. With a sideloaded browser.
They already did! The word was install. Or as GP noted, run. They're actually even now much more conventional and widely understood uses, and if anything it's Google attempting to swim against the stream and normalize sideload as language for software installation. Theirs is an object lesson, I think, in appropriately registering the objection and pushing us back to normal language.
I keep hearing that here, and people have good reasons why they think of that but to me sideloading always meant having your phone physically next to the device you're pulling an apk from, in other words loading the app from the side.
I always thought of it as coming from side-channel. Which (until I searched just now and was only offered side channel attacks as a result) I generally construed it as a good thing because the system was assumed to be broken. Things like track 2 diplomacy or messaging the CEO/minister because customer service/bureaucracy was broken. You can go in the side door of a business if you own it or belong there, only dis-empowered customers are forced to go in the front.
Side loading was getting something to work because it should when the system hadn't caught up to the fact that it should work.
Yeah, that strikes me as a familiar use also. They seem to be using it to mean not only that but any software installation that doesn't happen via the Play Store, so it's rooted in real history but also conveniently re-appropriated to imply it's veering outside of typically intended use cases.
The old Indian word for setting up software was in-sta-lin-it. It was so common, anyone with basic tribal knowledge could gather next to their "Pee See" and execute the code.
You're about two decades late to the complaint party in this context at least. I can find references on google books back in 2006 referencing sideloading.
I'm ready to grant that you found an occurrence in the wild but it takes more than that to demonstrate prevalence, conventional usage, or semantic fidelity to originally intended meanings. Also they are appealing to a usage that's practically as old as the paradigm of personal computing itself, so I don't think they're the one that's out of date.
I happen to remember "sideload" as a term of art for some online file locker sites to mean saving it to your cloud drive instead of downloading it to your computer. A cool usage, but it never caught on.
I think nomenclature as it exists in the PC software universe is closest in spirit on all fronts, in describing running software as, well, running software, and describing installing as installing. While a little conspiratorial in tone they're not wrong that "sideload" pushes the impression that controlling what software you run on your phone should be understood as non-default.
This is an instance of an on target usage though relating to the unofficial loading of software onto the device. And in my eyes finding it in a published work by a major publication means it was likely in wider usage in the same context, at the very least it can be an indicator of the start of that particular usage.
Edit: be sure to read geoffschmidt's reply below /edit
The buried lede:
> a dedicated account type for students and hobbyists. This will allow you to distribute your creations to a limited number of devices without going through the full verification
So a natural limit on how big a hobby project can get. The example they give, where verification would require scammers to burn an identity to build another app instead of just being able to do a new build whenever an app gets detected as malware, shows that apps with few installs are where the danger is. This measure just doesn't add up
Oh! I thought I had found the crucial piece finally after ~500 words, but there's indeed better news in the section after that! Thanks, I can go sleep with a more optimistic feeling now :)
Also this will kill any impetus that was growing on the Linux phone development side, for better or worse. We get to live in this ecosystem a while longer, let's see if people keep damocles' sword in mind and we might see more efforts towards cross-platform builds for example
That's like accepting vaders 'altered' deal, and being grateful it hasn't been altered further.
If google wants a walled garden, let it wall off it's own devices, but what right does it have to command other manufactures to bow down as well? At this stage we've got the choice of dictato-potato phone prime, or misc flavour of peasant.
If you want walled garden, go use apple. The option is there. We don't need to bring that here.
Google Certified Devices is any device that has GMS (Google Mobile Services) installed - ergo almost all of them. It's worth noting that a _lot_ of apps stop functioning when GMS is missing because Google has been purposefully been putting as much functionality in them instead of putting them in AOSP. So you end up in a situation where, to make an Android phone compatible with most apps, you need GMS. Which in turn means you need your phone to be Google Certified, and hence must implement this specification.
The others answered the question, but I wanted to add that this is "new English" to me as well (also non native though). I first saw it in chats with mostly teenagers in ~2021, where I've also learned "let's go" isn't about going anywhere at all (it means the same as w)
This is the first sign we're getting old :) new language features feel new. The language features I picked up in school, that my parents remarked upon, were simply normal to me, not new at all. I notice it pretty strongly nowadays with my grandma, where I keep picking up new terms in Dutch (mainly loan words) but she isn't exposed to them and so I struggle to find what words she knows. Not just new/updated concepts like VR, gender-neutral pronouns, or a new word for messages that are specifically in an online chat, but also old concepts like bias. It's always been there but I'd have no idea what she'd use to describe that concept
Yes, but it's often just "a W" or simply "W" in response to something good or seen as a "win."
There is also the same thing with L for loss/loser. "that's an L take", "L [person]", "take the L here", etc.
They are pretty straightforward in their meaning, basically what you described. I believe it comes from sports but they are used for any good or bad outcome regardless of whether it was a contest.
This isn't a "W", but I am finding my own "W" from this by seeing others distrust Google, and remembering to continue supporting and looking for open alternatives to Google.
Ok, but sideloading is already a thing. What will this way to install unverified apps be? I doubt it will be an extra screen asking "Are you super-duper sure you want to enable sidloading???" after the one already asking the same question.
They talk about doing it under pressure, so my guess is there might be a waiting period before you're allowed free reign, or maybe per-app. Or some level of calling google, listening to 10 minutes of how poor billionaires are going to starve if you have control of your own device before being allowed to unlock it.
That doesn't say that you can just build an APK and distribute it. I suspect this path _still_ requires you to create a developer console account and distribute binaries signed by it... just that that developer account doesn't have to have completed identity verification.
That's not fine at all. A developer who doesn't want to (or can't) distribute through the Play Store will now need to teach their users how to enable developer mode and toggle a hidden setting. This raises the barrier a bit more than the current method of installing outside the Play Store.
Maybe this sounds dark but see also how the net is tightening around phones that allow you to run open firmware after you've bought the hardware for the full and fair price. We're slowly being relegated to crappy hobbyist projects once the last major vendors decide on this as well, and I don't even understand what crime it is I'm being locked out for
We're too small a group for commercial vendors to care. Switching away isn't enough, especially when there's no solidarity, not even among hackers. Anyone who uses Apple phones votes with their wallet for locking down the ability to run software of your choice on hardware of your choice. It's as anti-hacker as you can get but it's fairly popular among the HN audience for some reason
If not even we can agree on this internally, what's a bank going to care about the fifty people in the country that can't use a banking app because they're obstinately using dev tools? What are they gonna do, try to live bankless?
Of course, so long as we can switch away: by all means. But it's not a long-term solution
I think pretty soon I'll carry a "normal" phone in my bag for things like communication and banking/ticketing, but I'll carry a device I actually like in my pocket. It'll be the best of both worlds - content I want to see often and easily in my pocket, and the stuff I don't want to be distracted by will be harder to reach on a whim.
Yes, I think I'll have to do the same. I've been in the market for a new phone but the one I had pretty much settled on removed the option to update the boot verification chain so I'm obviously not buying that. Might as well buy apple then
It seems like a finite solution though. Having a second phone is not something most people will do, so the apps that are relegated to run on such devices will become less popular, less maintained, less and less good
Currently, you can run open software alongside e.g. government verification software. I think it's important to keep that option if somehow possible
Let me guess, a warning box that requires me to give permission to the app to install from third-party sources? Is that not clear enough confirmation that I know what I'm doing? /s
A simple yes/no alert box is not "[...] specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer". In fact, AFAIK we already have exactly that alert box.
No, what they want is something so complicated that no muggle could possibly enable it, either by accident or by being guided on the phone.
The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
It’s been fairly clear from the start that this wasn’t the end of sideloading, period. However that doesn’t get as many clicks and shares as writing a headline claiming that Google is taking away your rights.
> The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
No, until this post, Google had said that it wouldn't be possible to install an app from a developer who hadn't been blessed by Google completely on your device. That is unacceptable. This blog post contains a policy change from Google.
> The angry social media narratives have been running wild from people who insert their own assumptions
There may have been exaggerations in some cases but these hand wavy responses like "you can still do X but you just can't do Y and Z is now mandatory" or "you can always use Y" is how we got to this situation in the first place.
This is just the next evolution of SafetyNet & play integrity API. Remember how many said use alternatives. Not saying safetynet is bad but I don't believe their intentions were to stop at just that.
Sorry what? Their original plan absolutely was the end of sideloading on-device outside of Google's say so. That's what the angry social media narratives were that you seem upset about. Anyone being pedantic and pointing out that adb install is still an option therefore sideloading still exists can fuck off at this point.
I don't think this section is actually the same as the present state just with a new alert box.
I suspect they mean you have to create a android developer account and sign the binaries, this new policy just allows you to proceed without completing the identity verification on that account.
What are you talking about? This change for "experienced users" was only just announced and not part of any previous announcement. It has not been clear from the start at all.
You're right: if the logic is that low-install apps are the most dangerous (because they can fly under the radar), then making it easier for unverified apps to reach a "small" audience doesn't really solve the problem
> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands.
As long as this is a one-time flow: Good, great, yes, I'll gladly scroll through as many prompts as you want to enable sideloading. I understand the risks!
But I fear this will be no better than Apple's flow for installing unsigned binaries in macOS.
I also think we should stop calling it "sideloading". We need a better word. Sideloading has a negative vibe, as if it's a dangerous thing to install apps from sources other than the Play Store.
There is a distinction between installing something via the primary or a secondary mechanism. If someone said I just had to "install" a windows program and it turned out I had to compile it from scratch and set all the registry entries myself, I would be "astonished"(as in: The Principle Of Least Astonishment).
I fully understand that language matters and if this was an attempt by Google to de-legitimize this way of installing, that's no good. But for Christ's sake, having different names for different things is not inherently malicious.
I don't see why you'd be astonished here. The Play Store downloads the APK and installs the APK. If you've downloaded it already (eg with a browser), you just install the APK.
How is that comparable to compiling from scratch and setting the registry entries yourself?
About five clicks more(than a single click) and a scary safety setting to turn off. But I didn't mean that installing an apk was as involved as my windows example. That was meant to illustrate that there are two completely different lines of action, two completely different levels of user competence at play.
Installing from the play store involves exactly zero knowledge of what an apk even is.
I want to flip the question around and ask you: How are you not seeing that there is a distinction?
Does this allow unsigned binaries like today? Or is this now requiring you have a binary signed by a android developer account but just one without full identity verification.
Exactly, this would greatly reduce the ability for scammers in "urgent" situations, but for power users who flip the switch on day one it would rarely be a problem. What would be terrible though ... is if Google made it require a network connection or Google approval.
> Keeping users safe on Android is our top priority.
I highly doubt this is your "top" priority. Or if it is then you're gotten there by completely ignoring Google account security.
> intercepts the victim's notifications
And who controls these notifications and forces application developers to use a specific service?
> bad actors can spin up new harmful apps instantly.
Like banking applications that use push or SMS for two factor authentication. You seem to approve those without hesitation. I guess their "top" priority is dependent on the situation.
> And who controls these notifications and forces application developers to use a specific service?
Am I alone in being alarmed by this? Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps? And they must instead rely on centralized control to disable those apps after the crime? So.. what’s the point of the sandboxing - if this is just desktop level lack of isolation?
Glossing over this ”detail” is not confidence inspiring. Either it’s a social engineering attack, in which case an app should have no meaningful advantage over traditional comms like web/email/social media impersonation. Or, it’s an issue of exploits not being patched properly, in which case it’s Google and/or vendor responsibility to push fixes quickly before mass malware distribution.
The only legit point for Google, to me, is apps that require very sensitive privileges, like packet inspection or OS control. You could make an argument that some special apps probably could benefit from verification or special approvals. But every random app?
> Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps?
An app can read the content of notifications if the appropriate permissions are granted, which includes 2FA codes sent by SMS or email. That those are bad ways to provide 2FA codes is its own issue.
I want that permission to exist. I use KDE Connect to display notifications on my laptop, for example. Despite the name, it's not just for KDE or Linux - there are Windows and Mac versions too.
> An app can read the content of notifications if the appropriate permissions are granted, which includes 2FA codes sent by SMS or email.
Do apps generally do this? I've never run into one that doesn't expect me to type in the number sent via SMS or email, rather than grabbing it themselves.
I don't use a lot of apps on my android phone, though, so maybe this is a dumb question to those who do.
Most apps don't read notifications for that purpose, and I'm not sure they'd be allowed in the Play Store if they wanted the permission just for that. It's mainly used for automation and sending notifications to other devices like PCs and maybe smartwatches.
Yes, but see my last paragraph. Reading notifications doesn’t apply to the majority of apps. It’s not a binary choice. On iOS, you need special entitlements for certain high level privileges. Isn’t it already the same on Android?
It's similar. I think there's a difference in that special entitlements have to be approved by Apple. Read/manage notifications is under "special app access", which has a different prompt where the user has to pick the app from a list and flip a toggle to grant the permission rather than just tapping OK.
yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.
powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.
(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)
You may be overthinking it. Verification of some sort isn’t the end of the world, it’s arguably an acceptable damage control stop-gap that has precedent on other platforms like special entitlements on iOS and kernel extensions on Windows.
Googles proposal was to require everyone to verify to publish any app through any channel. That would be the equivalent of a web browser enforcing a whitelist of websites, because one scam site asked for access to something bad.
If scam apps use an API designed by Google to steal user data, then they should fix that, without throwing the baby out with the bathwater.
I mean the solution really is a comprehensive permissions system, for an accessibility system that needs to read notifications you should be able to deny it network permissions and whitelist which app's notifications it's allowed to read
entirely agreed, but in the context of this thread that means you just have to convince someone to enable it for the one app, rather than the phone as a whole. which doesn't seem to help at all with the coercion scenario (if anything that might make it safer-sounding and therefore easier), just under normal use / to limit possibly-malicious apps.
browsers are really not much better. on an absolute level, I definitely agree they're better (e.g. they have per-url and only-after-click permissions for some things), but they've all got huge gaps still once you start touching extensions. and beyond that it remains to be seen, since OS-level permissions are significantly broader-possibility than in-browser due to being able to touch far more sensitive data.
Making money and complying with the law. They are obligated to do both. In many countries laws are still enforced.
Protecting their app store revenues from competition exposes them to scrutiny from competition regulators and might be counter productive.
Many governments are moving towards requiring tech companies to enforce verification of users and limit access to some types of software and services or impose conditions requiring software to limit certain features such as end to end encryption. Some prominent people in big tech believe very strongly in a surveillance state and we are seeing a lot of buy in across the political spectrum, possibly due to industry lobbying efforts. Allowing people to install unapproved software limits the effectiveness of surveillance technologies and the revenues of those selling them. If legal compliance risks are pushing this then it is a job for voters, not Google to fix.
Complying with the law is just another way of protecting your money. I have no doubt if they would break laws if they judged it better for the bottom line --- in fact I have little doubt they're already doing so. On the flip side, if there were ruinous penalties for their anticompetitive behaviors (i.e., in the tens or hundreds of billions of dollars) they might change course.
Certainly voters need to have their say, but often their message is muffled by the layers of political and administrative material it passes through.
BINGO! Google doesn't care at all about user security.
- Just yesterday there was a story on here about how Google found esoteric bugs in FFMPEG, and told volunteers to fix it.
- Another classic example, about how Google doesn't give a stuff about their user's security is the scam ads they allow on youtube. Google knows these are scams, but don't care because they there isn't regulation requiring oversight.
> Just yesterday there was a story on here about how Google found [a security vulnerability that anyone running `ffmpeg -i <untrusted file> ...` was vulnerable to] in FFMPEG, and told [the world about it so that everyone could take appropriate action before hackers found the same thing and exploited it, having first told the ffmpeg developers about it in case they wanted to fix it before it was announced publicly]
Fixed that for you. Google's public service was both entirely appropriate and highly appreciated.
Yes, but it was a public service not a service for the maintainers, and as a member of the public who like anyone who had run `ffmpeg -i <thing I downloaded from the internet>` was previously exposed to the vulnerability I highly appreciate their service.
I'd highly appreciate even if the maintainers never did anything with the report, because in that case I would know to stop using ffmpeg on untrusted files.
So you were using untrusted video files that required the LucasArts Smush codec?
Again, if YOU highly appreciate their service, that's great, but FFMPEG isn't fixing a codec for a decades old game studio, so all Google has done is tell cyber criminals how to infect your Rebel Assault 2. I'm glad you find that useful.
No, I was running on normal untrusted video files. The standard ffmpeg command line would happily attempt to parse those with the LucasArts Smush codec even though I'd never heard of it before.
See the POC in the report by google, the command they run is just `./ffmpeg -i crash.anim -f null /dev/null -loglevel repeat+trace -threads 1` and the only relevant part of that for being vulnerable is that crash.anim is untrusted.
Edit: And to be clear, it doesn't care about the extension. You can name it kittens.mp4 instead of crash.anim and the vulnerability works the same way.
this is an absurd rant. they invest, like, billions into security. It's not as perfect as you want it to be but "completely ignoring" is a joke. if you've got actual grievances you should say what they are so that we can actually get on your side instead of rolling our eyes
They absolutely eo completely ignore many security and privacy things because they're very selective in what they focus on, particularly around how those things might impact their ad revenue.
How much they spend is no indicator of how and where they spend it, so is hardly a compelling argument.
Some security is better than no security. It already took years to even get some of these backwards-thinking companies and services to adopt SMS OTP and it's simple for non-technical users to intuit. Also, believe it or not, some people don't have smartphones, and they will riot if you try to make them switch to any other MFA method...
Of course, I'm not saying we shouldn't push to improve things, but I don't think this is the right reaction either.
This is the worst of both worlds, you can spread your malware as a sideloaded apk just fine, but when it's so big that you're probably burned anyways, then you need to verify your account.
I think a better compromise would have been for google to require developer verification, but also allow third party appstores like f-droid that don't require verification but still are required to "sign" the apks, instead of users enabling wide-open apk sideloading. that way, hobbyists can still publish apps in third party stores, and it is a couple of more steps harder for users to fall for social engineering,because they now have to install/enable f-droid, and then find the right malicious app and download it. The apk downloaded straight from the malicious site won't be loaded no matter what.
Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores, and maybe even require an inconsistent set of steps to search and find apps to make it harder to social engineer people (like names of buttons, ux arrangements, number of clicks,etc.. randomize it all).
What frustrated me on this topic from the beginning is that solutions like what I'm proposing (and better ones) are possible. But the HN prevailing sentiment (and elsewhere) is pitchforks and torches. Ok, disagree with google, but let's discuss about how to solve the android malware problem that is hurting real people, it is irresponsible to do otherwise.
It's not super clear from the post, but if I read it correctly there are two modifications suggested.
- 1: Separate verification type for "student and hobbyist"
- 2: "advanced flow" for "power users" that allows sideloading of unverified apps - I imagine this is some kind of scare-screen, but we'll see.
What you describe as "worst of both worlds" is about point 1.
I'm not sure point 2 is powerful enough to suppor things like f-droid, but again, we'll see.
If you don't look both ways when you cross the road, then you may get hit by a car. The solution is to pay attention.
It's acceptable to build a system where human error can lead to catastrophic consequences, even death. Every time you go outside you encounter many of these systems.
Not everything in life can be made 100% safe, but that's no reason to stop living.
Swindlers work by that is a story as old as time. Even snakeoil salesmen were good at distracting people from obvious signs of false promises and warnings. People often overestimate their own capabilities greatly, same as there are no bad drivers on the road when you ask people about themselves.
There are definitely things you could do to improve it though. E.g. you can't activate "I know what I'm doing" mode while on the phone or for 1 hour after a phone call. Someone else suggested a one-day cooldown.
Also for the specific scam they mentioned, why do apps even have permission to intercept all notifications?? Just fix that!
> why do apps even have permission to intercept all notifications?? Just fix that!
I fear "fixing" it would mean removing the feature entirely, which breaks many workflows. Primarily this is used for accessibility (and is controlled in the accessibility settings), but applications such as KDE Connect also make good use of it.
Then i guess you can't publish apps? One of those issues where i should be "writing to my congressman" or whatever I guess. the problem is real and people like you are being obtuse, unwilling to find a solution or a compromise. Something as simple as number of installs is an invasion of privacy? how? it's a number, you increment a counter when someone hits download, that's it.
Yeah, if google gets to have rules over what happens by apps that have their seal of approval. that's how seals of approvals work. you're not entitled to these things. you don't have the right to publish to the android platform, if Google, wary of anti-trust suits allows a 3rd party app store, it can institute reasonable requirements.
If an appstore is willingly hosting malware, should Google still provide their seal of approval? That was supposed to be rhetoric, but I wouldn't be surprised if you told me that they should.
This is willful ignorance, I only hope you educate yourself on the harms caused by malware and malicious actors and consider taking a practical approach to finding solutions instead of dying on every single hill.
> life is full of people doing harms and malicious actors, but we don't let Google or any other company gatekeep our lives
Yeah, you're certainly not speaking for malware victims here. android is not your life, so google gatekeeping android (actually only google approved builds) is not gatekeeping your life.
You certainly should be able to load an alternative OS. isn't that what lineage and other android distributions do already?
Not when google lobbies your government and banks to require "play integrity" in order to use government apps and bank apps
Not device integrity (locked bootloader, signed image, which can be done with alternative OS) but "play integrity" so approved by google. In other words, you can't run android without Google's services, google's builtin ads.
How about the harms of fascist authoritarian governments that will use this functionality to ban any apps they don't like? Why do you people only care about malware and not essential fundamental freedoms that affect us every fucking day?
talk about a straw man. "fascist authoritarian" is rich, governments don't need that to ban apps. Google can ban apk's on all android phones with a play store any time they want. Microsoft can do this on any windows machine with windows update turned (they have in the past), apple can do that with their OS's too.
Your freedoms are not the subject of this topic, not even remotely. Google isn't even banning you from doing anything on android phone, this is strictly about approving android builds by phone vendors, you're not even the subject here. Google doesn't want to approve android builds that allow sideloading. You can still install lineage.
Your argument here is actually "fascist authoritarian", you want to impose your views on the general public, that sideloading should be enabled. Having an option for yourself and other willing people to just not just vendor built android is not enough, you want the public to also leave the gates open so you can sideload your random apk's.
Oh, and for the record, my post was about finding a compromise, not a false dichotomy as you presented. If you made a car without a seatbelt it won't be allowed on the roads, if a phone vendor also builds an unsafe android where random devs an sideload apks, that shouldn't be allowed. Forget Google, governments should be enforcing the sideload ban lol.
You don't appreciate your freedoms and insist on abusing them, so actual freedoms end up being taken away!
> people like you are being obtuse, unwilling to find a solution or a compromise.
How are people being obtuse for refusing to compromise for solutions on a problem which doesn’t exist?
You can’t misrepresent the situation, establish that one American company having absolute control on what people do with their devices is somehow the norm and then complain that people won’t meet you halfway.
> How are people being obtuse for refusing to compromise for solutions on a problem which doesn’t exist?
I'll give you the benefit of doubt and assume you're just not well informed.
Millions of people are losing billions of dollars. Women are having their private media published to the masses. People are getting divorces, fired from jobs,etc.. because of android malware. The problem is nearly non-existent on iPhones to the most part, because they lock that down (but now thanks to "my freedom" type of freedom abusers are changing that too).
Apple already does this. You can't publish a driver for Windows without verifying your identity and buying an expensive code signing cert. Google isn't doing anything new, matter of fact, they're not doing enough! this still permits things like lineageos and other android builds to be installed -- that's your freedom. But since the prevailing sentiment is to resist a more secure way of doing things, the outcome will be that all smartphones will only load signed kernels/firmware in the future, and all signers will be required to id themselves, this will kill a lot of android builds.
This is why compromise is important. Your liberties are important to you, but you can't just dismiss the harm to the masses like that and refuse to find a compromise or a solution, that's how you lose what little freedom you have.
This is why things like "chat control" keep creeping up, and they will succeed down the road.
In light of Google's recent push to eliminate this, I went and installed F-Droid to see what we'd be losing. I had thought about it for years, but always held off on doing it on my daily driver phone because I simply didn't want to open the floodgates on allowing apps to start randomly installing on my phone.
But having done it, I'm actually pretty impressed with the existing security. At least on my S24, you have to both enable sideloading at the system level, and enable each specific app to be allowed to "Install other apps" (e.g. when I first tried to launch the APK that I had downloaded from Firefox, I received a notification that I would need to whitelist Firefox to be allowed to install apps. I decided no, and instead whitelisted my File Manager app and then opened the APK through that).
I then installed F-Droid, allowed it to install other apps, installed NewPipe, and then toggled back off the system-level sideloading setting. NewPipe still works, and I don't think anything else can install. This satisfies my security paranoia that once the door to sideloading is opened that apps can install other apps willy-nilly. Not so.
So I really don't see what this new initiative by Google solves, other than, as others have said, control. The idea that somehow all user security woes come from sideloading apps and they would somehow be safe if they simply stuck strictly to the Play Store is patently untrue, given the number of malware-laden apps currently lurking in the Play Store.
Sounds like they're rolling back the mandatory verification flow:
Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.
I'm a little nervous about what this advanced flow is going to look like, given that sideloading already requires jumping through a bunch of hoops to enable and even that apparently wasn't enough to satisfy Google.
I'm cautiously optimistic though. I'm generally okay with nanny features as long as there's a way to turn them off and it sounds like that's what this "advanced flow" does.
> Sounds like they're rolling back the mandatory verification flow
absolutely no. this is for the user side. but if you're a developer who is planning to publish the app in alternative play store/from your website, you have to do verification flow. please read the full text.
I feel like if safety was really their top priority, they would have done this long ago and not bothered with this mandatory signing nonsense to begin with...
"Allow". This is the entirety of the problem. They are allowing things on my machine that I purchased with monies that I leased my soul for.
Anyway, I am already planning for a future in which Google does not feature as prominently as did until now. Small steps so far ( grapheneOS ), but to me the writing the wall is unmistakable. Google got cold feet over feedback and now they can allow things.
When negative publicity ends, they will start working towards further locking it in again. I am personally done with passively accepting it. It might be annoying, but it degoogling is a simple necessity.
> I am already planning for a future in which Google does not feature
This. Currently I am still a paying Google customer for a few things running my freelance side business. I am in the process of migrating my data out of Google Drive and migrating my photos out as well.
Next step is taking back control over my email infrastructure. Especially as google nowadays sorts quite a relevant number of important mail to spam, while allowing more and more crap to pass into my inbox.
Also they one sidedly raised the price because they now have AI included. Fuck them - I am not using their shitty AI and I did not buy that. I am using AI daily - just not the crap product Google shoved down my throat.
garpheneOS/postmarketOS are next on my list. As I have a tertiary device around, I will during the dark months ahead set this up and see if it fits my needs.
With Arch now my daily driver (except for the main job), I plan to use way less US tech vendor crap. There are so many beautiful and not to difficult to use OS solutions out there, easily hostable on servers inside a more sensible jurisdiction.
Also currently working on a solution to get around the enshittified YouTube experience. Without it becoming an unreasonable effort to still watch the interesting things on my big screen in the living room. But automated AI audio translations did this in for me. I already find the automated title translations to be abhorrent - now, having had the absolute shit experience of starting a video and having it dubbed by an awful AI voice was just a bit too much for me.
Ironic suggestion in this context considering how hard Ubuntu has pushed snaps over competing solutions. Canonical is the Google of the Linux ecosystem.
The key question for me is whether this "advanced flow" will allow the practical use of entirely separate app stores (like F-Droid) or if they're going to throw up tons of barriers for every individual app install.
There's a second path, whereby F-Droid registers as an "alternative app store", which is a new category of app created in the fallout of Epic Games v. Google [0]. This is interesting because it applies to all regions and will necessarily need more elevated permissions than the typical REQUEST_INSTALL_PACKAGES permission used today. No idea what requirements Google will impose on such apps.
Up to what a committee of 3 people (or in the alternate district court judge James Donato) believes this means, assuming the judge approves the proposed modification to the injunction in the first place
> Google may create reasonable requirements for certification as a Registered App
Store, including but not limited to review of the app store by Google’s Android
team and the payment of reasonable fees to cover the operational costs
associated with the review and certification process. Such fees may not be
revenue proportionate.
One appointed by Google, one by Epic, one appointed by the other two. All three will be barred from private communications about any of this with any parties.
Considering this is an anti-trust suit I suspect the judge would be extremely unamused if the committee members found that "must ban NewPipe" was a reasonable requirement.
That sounds reasonable, but I doubt F-Droid can cough up the required US$1 million to pay 12 Google L7 SWEs to spend a month reviewing F-Droid once they get enough free time. I wonder if they'd require F-Droid to comply with PCI-DSS? That seems to be the trendy thing in review and certification processes, and naturally it's important for an "App Store" to have secure payments, isn't it? (Never mind that F-Droid doesn't accept payment except donations via liberapay.)
If I were designing the advanced flow, I'd require the decision to be made at phone setup time. Changing your mind later requires a factory reset.
Real sideloaders (F-Droid users, etc.) know at setup time that that's how they'll be using their phone, so it works for them. But ordinary users who are targets for sideloading malware will become a lot less attractive if attackers must convince them to wipe their phone to complete the coercive instructions.
Aliexpress has a similar approach to protect their accounts from takeovers. If you change or forget your password, all your saved payment methods are erased. This makes the account less valuable to an attacker, at the cost of a little pain to authentic account holders.
No, that's ridiculous. If I want to send an app to someone, now they have to wipe their phone to install it? That would kill installing non-Play apps far more than Google's original proposal.
I hadn't installed a non-Play Store app for something like 5 years until this year. I don't see why I should have been forced to factory reset my phone then.
Forgive my bluntness, but I hope you are never allowed on the Android team or near any significant UX decisions on any devices or apps I use or will use.
When using F-Droid, I don't think of myself as a "sideloader". I'm using an app store (F-Droid), not installing some random APKs.
(Yes, the F-Droid store app had to be "sideloaded". Once. It updates itself. If or when Google allows alternate store apps in their store app, even that would no longer be necessary.)
EU digital markets mandates that you can install apps through f-droid... but doesn't mandate that those apps don't to comply with Google's signing policy.
This is misleading though. There is simply no other choice if you want to use mainstream apps. It could be argued (successfully in my view) that any agreement is null and void due to its acceptance under duress.
Users have an inherent legal right to unconditionally access the full advertised functionality of devices they purchase. Any agreement after that is inherently suspect and I wouldn't be surprised to find out it was ruled unconscionable by some court if it came to that.
This isn't misleading in any way. It's unfortunate and we should be pissed about it, but this is exactly the legal arrangement that Google and Apple came up with.
> I wouldn't be surprised to find out it was ruled unconscionable by some court
Last US court battle, Apple told the court it needed the money from the kids casino to keep its profits, and the court just nodded.
Apple had to be held in comptempt of a court order after 4 years and a deluge of evidence, for us to see any significant move.
Too many people are in denial about what they actually own, and seem to refuse to accept this battle isn't starting or coming up, we're already in the process of losing it.
Clinging to material ownership feels great on the moment, but that's absolutely not what we need to deal with right now. It's kinda like being so proud to be the registered owner of your car, while it's getting impounded and you'll be spending the next 10 years trying to get it back.
Which is an unacceptable loophole in our legal system that should be closed immediately as far as I'm concerned. If I buy a product, even if that product is software, then I own it, and I should have ultimate control my copy of it.
The idea that we allow companies to go "Yes, you paid for this product, but it's not really yours. We still control it and can do whatever we want with it regardless of what you want." is asinine.
8 days ago Google and Epic announced a proposed settlement and modification of a permanent injunction that Epic won, I believe this proposed settlement would likely have prohibited Google's plan to forbid installation of third party apps (excluding app stores from the definition of apps) unless those app developers had paid google a registration fee. The proposed settlement is here [1], the relevant portion is
> 13. For a period beginning on the Effective Date through June 30, 2032, Google will [...] and will continue
to permit the direct downloading of apps from developer websites and third-party stores without
any fees being imposed for those downloads unless the downloads originate from linkouts from
apps installed/updated by Google Play (excluding web browsers).
6 days ago the court expressed skepticism as to the proposal and announced that they'd have a hearing, with testimony from expert witnesses, as to whether it would prevent the market harms that the original injunction was trying to cure [2].
Today Google announces this, effectively confirming that they're backing down from their requirement that third party app developers pay google prior to distributing their apps.
Nothing (yet) is explicitly tying these together, but I can't help but suspect that this move is in large part being made to convince the court that they're actually intending to honour this portion of the proposed injunction even though Epic would have little reason to enforce it.
Did we read the same thing? I think Google here said there would be a $25 fee per developer (for those who can't fit in their limited distribution category). I suppose it's much better than a fee per paid install but it's not nothing.
They announced the $25 "verification" plan awhile ago. The new part in this article is that they're going to have it remain possible to install software that didn't do that "verification".
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
In the end when supporting the non tech people in the family, what I would really like is to setup their device so they can install anything on Fdroid but nothing from the play store (unless approved by me) nor direct from an apk.
We really need to banish the term "sideloading". Installing apps on a terminal is just that, and for as long as I remember on windows, Linux it has always been just that.
Google mentions about being on a call, and being tricked into handing over codes. So why not use signals and huristics to decide?
If user is on a call, block any ability to install a shady app. Implement a cool down before that functionality is restored (say 24 hours). It can also detect where the user is based to add additional protection (such as mandating the use of play protect to scan the app before it's activated and add another cool down regardless).
There's lots of ways to help protect the user but it's wrong to ultimately control them. The real world is full of scary dangers that technology is trying to solve but is actively making things worse (such as computerized safety systems in cars).
Ultimately, the user is responsible and whilst it's palpable Google would want to reduce harm in this specific way, we know authoritarian governments would also love to be able to dictate what software people can run. The harm to democracy is simply too great in favor of saving a few people's money.
They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed.
You will not be able to use any of your banking apps without first removing all of those...
We need alternatives, this will not work and is a risk to freedom/democracy for all of us.
Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. However Google and Apple can just remove it, what then?
Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices?
I just can't see any good reason for it but my banking app has invested more work into detecting any possible hint of rooting than into its UX. It's absurd.
> Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices?
As an early cyanogen mod adopter I really don’t want to lose ability to side load etc. but to answer your question this is probably for the lowest common denominators safety.
Anecdotal example - a scammer tricked my parents into sideloading an apk which automatically forwarded all sms messages to the said scammer. This lead to 2FA code from bank go through and allowed them to perform some transactions.
There were many red flags during this ‘call from a bank’ and I’d say some blame lies on my parents here, I guess this is the only way to lock down bad actors? I am not entirely sure it is.
Banks have stupid rules probably made by people who don't understand the matter. A relative recently got victim to phishing and gave away some of his banking details (fake e-banking login screen on a website). After locking the account, the bank said it would only unlock it after the phone got wiped, which obviously doesn't add anything in this situation.
Another pet peeve is that they prevent screenshots simply because they can, and it feels safer. I know, 3rd-party apps which can do screenshots etc., but this is fighting the threat the wrong way. And yes, it's partially the fault of the platform, which could just allow user-initiated screenshots. Or at least make it configurable.
For example, my bank here in Hungary, Erste Bank has announced that the central bank requested that they stop allowing their android app to run on "modified" devices.
They even have a workaround: switch to SMS-based 2FA and use their website (which works well on any screen and has all the features of the app except 2FA)
Is this is something small regional banks in the US do? I'd actually be very interested to know about who is providing, and who is taking such coverage if this is being (re)insured. If you have any market data/news, I would love to know.
If you run a pentest, allowing rooted devices will almost certainly show up as a vulnerability. It'll be marked "low risk", but you'll also be told that you don't want to "accept risk" for too many "low risk" vulnerabilities.
So somebody then needs to say that this is not something they worry about rather than doing the easy thing and remediating it.
At most banks, the absolute control belongs to risk and regulation department. A bank must safeguard their license above all else, and it is very easy for them to loose it if the bank is found doing something it should not (though for the big ones, they sometimes operate in a gray zone, which means they manage to keep their licenses despite relatively steep fines). Even for the simplest ui/ux change, risk department has the final say.
Source: I’ve been working 15+ years in the banking industry.
Probably because it makes it easier to observe and/or intercept API calls and other data exchange between the client and the server. It's trivial to disable things like SSL cert pinning, etc. on rooted devices.
… and then the return argument is that those who actually want to do this nefariously are already going to be able to hide device modifications/rooting.
> They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed.
Sincere question: do you have any evidence for this?
I don't see anything in the article that backs it up, and your asserion seems to be at odds with the description of a side load capability for "risk tolerant" users. What you describe would certainly break much of the usefulness of side loading for me.
I certainly don't trust Google, or underestimate their capacity for duplicity. I'm just not sure about the outcome you describe.
It a projection of what they could do. ie. logical step
The whole SafetyNet and "secure chain" things are PITA, eg. ChatGPT app wouldn't work if the phone bootloader isn't signed by Google. Lots of banking app wouldn't work, HSBC banking app for instance wouldn't allow login if Android developer mode is enabled.
Some apps do this because of some minor audit crap with relation to screenshots (the devmode part) afaik. Others just always blank the screen image and tell the auditor to [insert crude metaphor].
Same none sense with root enabled. You must have a check, doesn't specify which one and as long as you can show it works once you are fine.
Of course, it wouldn't be HN if the previous claim that "the sky is falling" wasn't followed up with "well, it's not falling, but I saw some heavy rainfall!"
The digital ID e.g. eID is for example if you want to order a government document online. At the current time you need to print out your request and send a copy of your ID in the mail or go to the counter and show it. Same if you get a bank account or new phone contract although those usually let you scan your ID with your phone. A eID would make that more secure although people are already being tricked into doing face validations[1]...
Offline it would make it possible to verify your age at the self-checkout registers without having someone have to check in person.
In the future (if the law allows it, which it currently does not) it should be possible for you to purchase an item online completely anonymously, at least to the vendor. There would no longer be a possibility of leaked address, etc. as the vendor would not have it. All the vendor has are signed tokens. When they send a package they send it with a token to the post office and only the post office knows your address.
They removed the "ICE" app and if the US government has an issue with other Apps they bend over and do it.
Switzerland is currently dealing with a 39% and Brazil with a 50% tariff because Trump has a personal problem with them. It would not be far fetched for an administration to have another states app removed.
I just want to preface that I am not in support of Apple or Google in their closed ecosystem.
I was specifically referring to you saying "Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. However Google and Apple can just remove it, what then?"
It seemed like you were saying that because it is open source, it will be removed. I simply disagreed with that. Plenty of opensource software exists in the app store.
I'm not disagreeing that they have the ability to remove software from their app stores. They have done that before as you mention. That is a fact.
> It seemed like you were saying that because it is open source, it will be removed. I simply disagreed with that. Plenty of opensource software exists in the app store.
Sorry if it came across that way. It is not what I meant, I just mentioned that it is open source. ESL...
The current US administration is not acting with logic nor reason. Switzerland is currently dealing with a 39% tariff for no reason. We are the 7th largest investor[1] in the United States with thousands of jobs and we are the worlds 3rd largest holder of US dollars[2].
It's not "sideloading". It is "installing". Just installing the software you want, on the device you own.
I am not "sideloading" applications on Windows, either. I download and install them. And before the internet, you got your software on CDs or floppies and ... installed them. This is nothing new. The term "sideloading" somehow implies you are circumventing or side stepping some mechanisms or protections in a non-sanctioned / nefarious manner. I am not. I just install software on my phone.
* Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)
* Search for "termux-adb" in "Motorola moto g play 2024 Smartphone, Android 14 Operating System, Termux, And cryptsetup: Linux Unified Key Setup (LUKS) Encryption/Decryption And The ext4 Filesystem Without Using root Access, Without Using proot-distro, And Without Using QEMU": https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot... (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)
You don't need two phones to use ADB with Termux. Just put the ADB settings app on a split screen and it will work just fine. I used it several months ago.
I'm already annoyed by the fact that when I upgrade my own apps, self-developed and only used by me, which are installed either from Android Studio or by letting the app itself download the update from my server (with the app installation permission) and me then installing it, that I must send the app to Google for them to make a security check.
It's not an option, even if they pretend it to be one: if I click the text "install without scanning", nothing happens. I must accept the big button that uploads the app for a scan. It's none of their business.
ADB is no alternative for me, because it's easier for me to send a websocket command to my 9 devices (mostly dashboards) so that they download the file and start the upgrade process, so that I then only need to press the "upgrade" button manually on each device. Remove the dashboards from the walls, just to plug an USB cable in them, to upgrade the apps?
So there was the very concrete problem that F-Droid could not continue to function with the verification requirements, because they rebuild every app and so would have to know every key.
That would at least be an improvement to the current situation, were they wouldn't be able to operate at all.
If the flow is designed such the you only have to do it once for F-Droid and then the unsigned apps would be installable from there without friction, it wouldn't even be that bad.
Ancedotal: I used to believe in this "freedom to install". Than my Father got scammed (~$1000) in the name of Electricity recharge. The APK was sent over WhatsApp. Now I am not so sure how to implement this freedom. At the bare minimum there has to be big red warnings.
One thing which can immediately improve security is forbidding SMS read access forever. Just like Apple does. No App should be able to read SMS.
So your father:
1. Downloaded a weird file from a stranger
2. Went to the settings and about pyone sceeen
3. Tapped the thing 5 times to activate developer mode
4. Activated installing from third party sources despite the warning there
5. Installed the APK
May I suggest the problem is not that this is possible, but a lack of education? If your father is the type that would jump into the bathtub with a toaster because someone on whatsapp told them to do so, I am afraid it is not the existence of toasters that is the issue.
Yes, education around these scams and their methods could be better, but there is also a reason they target the elderly and vulnerable. Unless something else terrible happens, I assume I will count in one or both of those groups eventually. I feel like when I get there, I would appreciate empathy rather than disdain, if I were ever taken advantage of.
Regardless, you do not actually need to enable developer settings to install APKs from unknown sources (at least, not on my Samsung). When you open an APK from within another app (e.g. Google Drive or WhatsApp), Android "helpfully" forwards you straight to the relevant security settings page, allowing you to immediately toggle the "Install unknown apps" permission for that specific app. It's a streamlined flow, only a couple of taps, no scrolling/searching/reading, therefore likely easy to coach a victim into performing.
So, I expect what the Android team is alluding to in the original post is to enable additional friction like you describe.
eh, think this is a bit much to ask. Are we going to educate a majority of the baby boomers who just never got a feel for how technology works? Yeah, my Dad also just got scammed by a phishing scheme on his PC (and if a scammer had walked him through how to install an apk on his phone, he'd probably do that too).
In my humble opinion, in the design of a UI or any type of system, kind of have to go where the users take you to some degree. And Android, being an OS for consumer devices, should be geared toward the masses and the mistakes they'll make.
Should we ban refilling your own cars oil because some idots keep filling coolant into it?
I worked in IT support and I am deeply aware with the issues people are having. Some issues are systemic (aka bad design) and those should be fixed. Other issues are human.
It may not seem like it, but I have the patience of an angel, because I remember when computers where new to me. I like people to understand. Understanding is power. But when I did work in IT support I saw some things. Grown adults repeatedly clicking away error messages without reading them while I stand and watch over their shoulder. When I ask them what their error message read they say they don't know. Then we read it together and they go: "Ohhh".
Yeah. Ohhh. You have a weird error that prevents you from working and there is a red error message and you don't bother to read it. That isn't a technological problem that is a educational problem.
I stand by what I said, we cannot dumb down our system because people don't care, are lazy and act dumb. Because that leads to a cycle where it gets ever dumber and lazier all while making life hell for people who are not dumb or lazy.
If you want to use a car you need to know certain things. Same is true for digital systems, the internet, a smartphone, a toaster, a hair dryer, a knife, a simple plastic bag, etc. The solution is education, not dumbing down the world.
Well, yeah, everything has limits and this issue seems like a very practical one. Seems like it depends on how much work would be needed to teach the user base, which, at least to me, feels out of reach. As your being in IT, you may agree that teaching a large majority of 60+ year-olds standard things on something like Windows is difficult and extremely slow. Feels like it would take at least a month of dedicated training, where they are full on board. Having helped my older friends out, don't see that happening anytime soon (a half hour here and there is all they seem willing to do).
But you know, if there is a method that you know that can teach the masses these skills, then am all for it (maybe barrage them with youtube commercials teaching basic tech skills?:)
Shouldn't the logical conclusion be that if it's too much/hard to teach these people how to operate a device safely, they operate the devices in an unsafe way, bare the cost of it by being scammed, learn that it's not safe for them to operate the device for certain use-cases due to the experience, they tell others about it and it's in media -> people who do not feel confident operating such a device securely are scared away from using it due to the potential consequences they heard about -> problem solved (from a banking security perspective)
(except now the bank needs more staff behind the counter)
Not 100% sure if you mean this genuinely or joking around a bit. Will assume the former
Well, think just letting the knowledge of user failure expand organically is definite a method of deterrence, and some amount of this probably going to happen to some of the users. But to me, seems like it's a question of what percentage of your user base would be exposed to being scammed. Of course you'd want his to be zero, but if it's significant, yeah, probably should put measures in place to reduce the amount of scamming. Even on a purely practical level, it's bad for the reputation of your product...
...Am thinking, since there is so much resistence to locking down android, one problem might be was it was initially billed as a more open OS that tech people could enhance in whatever way they wanted. But yeah, times have changed, it's now a product that is used by the masses, and guessing the masses are now their most important users. Not saying this is wrong or right, but probably why there is so much push back as compared to say if iOS did the same thing (which they may have already done).
I wrote a longer post about that elsewhere but there is morally no good justification to restrict everyone else's devices just because a small minority falls for scams. This is a very principal issue in a free society and in most societies we allow all kinds of individual risk taking because we believe that adults should make their own choices even if that means that some people sometimes make mistakes.
On a side note, it is technically very feasible to help antivirus and security software makers to lock down phones for people who would benefit from it. For example, you could have a strict whitelisting approach for vulnerable users (e.g. elderly, bitcoin entrepreneurs, annoying kids, Google engineers) who prefer it that way, making installation of arbitrary software impossible. Giving up choices voluntarily is fine, taking away choices by force is not fine.
Why did your father enable installing APK packages from third party sources? That's a setting buried deep inside the developer settings, which themselves have to be activated with a very arcane manipulation
I believe this only works this way on some android forks, iirc you are talking about Samsung. Stock android would show a warning "do you want to install apk from this app?" and lead you to a settings page that enables apk installs from this particular app. No need to separately enable the ability to install apks in general.
I always thought this is a very weird flow, it adds hoops yet accomplishes nothing because the hoops are all trivial and the same for every app.
I have definitely seen this "you need to go deep in the settings to enable 3rd party installs at all" flow before, but I don't remember which device it was. (Just saying that the commenter above is not just inventing something, I was surprised when I saw it as well)
Hah, yes, this is also how S21 works. But to still refute the OP's point: (1) it is in stock settings, you do not need to enable the developer settings menu via any arcane method. (2) When you tap on an APK in e.g. Google Drive or WhatsApp, Android "helpfully" forwards you straight to this settings page, allowing you to immediately toggle the "Install unknown apps" and installation will begin (there may be another "do you want to install this app" confirmation).
The point being that there is not a whole lot of friction in this flow -- one or two taps -- likely making it easy for scammers to coach victims to perform.
I agree that activating the developer settings menu is substantially more friction, and may arouse more suspicion in a victim, but [on many/most devices] is not currently required. I guess the original article is alluding to putting this kind of friction in place.
I disagree - one feature in KDE Connect that is super useful is being able to forward your notifications, including your text messages. This would also harm non Android smartwatches, such as the recently revived Pebble.
There seems to be a whole market of Google Play developer accounts and apps for sale, developers like myself regularly get emailed by scammy companies offering to buy the account or to publish an app, and malware is regularly found on Google Play[0]. There's no reason to believe that bad actors would be stopped by install restrictions if their scam is effective enough to overcome the financial hurdles
The built in Android SMS app seems to be horrible in every incarnation I've seen. The one that comes with the Pixel, the one Samsung has. Some may like it, but I can't stand them. I tend to install my own SMS app in each case, and I don't use computers to be locked into something I don't prefer.
It's my tool. Mine. I'll do with it as I please.
I agree there are issues. But preventing installs aren't the answer, just like removing all windows and doors from a house isn't the answer to neighbourhood crime.
I'd be more inclined to say the problem is allowing apps to be funded by advertising. If all apps were paid apps, and using personal data in any way was immensely, "thrown in jail" illegal, then you'd find yourself approving access to contacts, SMS, Pii quite rarely.
It would really stand out in such a case.
"What?! I've been using my phone for 10 years, and some app wants to see my contacts. Why?? No one reputable asks for that, ever!"
So much of the problem with the internet is that Pii is paying the way.
On GrapheneOS, when I install anything, it flat out asks me if I want to give it internet access at all. SMS could be the same way. Off by default, try to grant it, big warnings.
At a certain point, if you have big warnings saying "Are you serious?!" and people turn it on, it entirely ends up being the end user's fault.
Genuinely curious: would you mind telling more about how your father got scammed and how the adversary managed to get your father to install an app from WhatsApp?
I receive all my SMS messages through a separate app, because my SMS provider is not my TelCo. Please propose solutions that will not harm people like me.
Freedom and protecting tech illiterate people are not mutually exclusive.
Our right to choose install software on our own devices should not be encroached because over-trusting elderly follower scammers instructions.
We can protect people like your dad with an opt-in system like parental controls. Have a responsible family member lock the system down however you deem fit.
Damn. I was excited by the prospect of Google shooting themselves in the foot, inspiring people to make Android replacements that aren't privacy and process nightmares. With this (partial) capitulation, the path of least resistance will remain a proprietary, corporate-controlled, bloated walled garden.
I don't understand the title, it's exactly the reverse, they will force verification for sideloading, even if they say they would have lighter requirements for hobby apps with low install number
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
There are many real-world sideloading abuse cases in China. Attackers often trick victims with plausible stories—e.g., claiming a flight is delayed—and ask them to sideload an app (a remote‑meeting or remote‑control tool) to share their screen. Once installed, the attacker can view the victim’s screen and intercept SMS 2FA codes for online banking or other sensitive accounts.
Other schemes include impersonating sex workers to lure victims into nude video chats, then persuading them to install an app that harvests private content and contacts for blackmail.
Why should that mean anyone else should lose control of their device? Maybe at some point you have to accept that it's the user's responsibility? Maybe empower users to be aware of what the apps they install are doing, without take their control away?
This is how loss of autonomy always happens in every sphere: make an argument that it's for their own safety that individuals are losing autonomy, and the entity gaining control is superior in knowing what's best, and is taking control only out of the goodness of their heart.
These unfortunately gullible people would be tricked in many different other ways throughout their daily lives even if it wasn't for the ability to install something on a device that you paid for and outright own.
What's the Android situation there? Last I heard Google didn't license Android there and they were using Chinese app stores with forked AOSP Android. Which would seem to put the sideloading decision in the hands of the forked OS.
If by necessity you need to leave the door unlocked more, then you can expect more bandits to pass through. The frequency is a result of China's banning of all Google services, and the mess of Google Play alternatives making the universal option to request users to just install the APK off of a sketchy cloud link.
That doesn't seem to have anything to do with what apps you have installed, just whether you have Play Protect enabled. I have Play Protect enabled, and I can still install apps without having to scan them first.
Are there any entities on earth with resources to compete with a complicit global duopoly?
If Android is open source, why can't/won't a community fork it? Graphene OS exists but many folks claim Netflix and banking apps do not work with it (despite allowing logins from any common desktop browser)?
If all widely-accepted phone operating systems are de-facto proprietary, what does this say about the current phase of society?
What choice do non-billionaire/millionaire humans have for living in a single-planet society where technology is so highly integrated (and the inherent non-consensual compromises)?
What If the little people are going to get squeezed even more?
LineageOS is based on AOSP and works well. I don't understand the banking app thing either. I suspect it's a regional issue. I can log in to my credit union account via any browser, and if something needs MFA it should be able to use TOTP which works on anything.
Android in practice is full of proprietary blobs, stuck on old kernel versions, and the hardware is barely supported. Lots of downstream crap from the vendors not playing nice. Most devices running Android are instantly doomed to be e-waste. You can look through devices postmarketOS supports, and anything without mainline kernel support and most stuff working is basically e-waste unless someone puts in a lot of work for that particular device. It's a little bit like how modern GPUs don't work without blobs in the kernel anymore and you have to go back to Haswell era or older for things to work with all free software, but the state of smartphones is a few steps worse than that due to their locked down nature.
Pretty much any OnePlus device (other than ones still too new) seems to be a good bet for decent software support (both LineageOS and pmOS). Though annoyingly stuff like the 3G shutdown makes a lot of the earlier models unusable as actual phones these days. At least they can still be computers. Not quite e-waste.
Yes we have banking websites but they are increasingly moving to an auth model where you have to enter an otp generated in the app but the app refuses to work on non-verified devices.
I had been Android fan from the start. When first Android phones went out I was astonished by the amount of possibilities. There were linux phones available, my colleagues used to set up ssh servers and more. Samsung had Baidu at that time which at least to me appeared more closed than Android.
Things have been going bad since then. Closing of root access, closing of software, youtube not working in split screen etc. All the changes make me think of Android as more and more repulsing. Recent changes like removing old software from the store because they didn't update API and now this... Google stop being evil
Glad to see Google come to their senses on this. Disabling it entirely would have basically guaranteed an exodus of power users over to iOS. If your only choices are walled gardens, you might as well pick the easiest, prettiest one.
Google still hasn't changed anything but took the opportunity to again insult their customers within the first headline, titled "Why verification is important".
Google goes on to say how taking away one of your last remaining rights is good for you, if you like it or not.
It is clear to everyone why Google is partnering with governments around the world to remove our rights to installing apps. Laws are not on your side and must be reevaluated on an individual level to move forward. You decide your own terms, you have the power.
What prohibits Google from offering a way to register your long-term app signing key without identity verification, publishing apps that are still verified by their automated tooling and then opting in to the usual denylisting/app store banning methods if those apps are malicious? This identity verification requirement is basically just an easy way for illiberal governments to find ways to crack down on apps they do not like (such as say, ICEBlock or whatever)
Banning all apps signed by the same key is already possible. Requiring signing keys to be anonymously registered with Google would add some friction to simply rotating your signing keys when you get caught doing something naughty (depending on how much Google account creation and key registration can be automated against Google’s anti-bot protection, though), but definitely not as much as full identity verification and payment of 25 USD (even if that isn't foolproof, either, and has the annoying side effect of unfortunately slowing down small-scale freeware developers at the same time, too).
So an interesting intellectual exercise is to try to figure out how you would create a power user toggle that is coercion resistant. The best I've been able to come up with is a timed lockout that is random in how long it takes to allow you to finally move into power user mode. So like a random value between 1 hour and 24 hours and you say I want to be a power user and then it says you have to wait 3 hours and 27 minutes before you can become a power user. Randomness because a scammer could optimize around a particular time period that was predictable.
Other thoughts on how you could make a coercion resistant power user toggle? I'm very excited that Google's thinking about offering this because it gives me faith that just because I chose to be in a minority, I won't be relegated.
On the flip side, I was so shaken by the original announcement that would kill off F-Droid that I've been very actively looking into building my own mobile device that runs Linux. I purchased the components for a Hackberry Pi that I'm hoping to build in the next couple of months, but knowing that Android won't kill off F-Droid entirely is heartening.
That could be done by requiring the use of ADB. Normal users would found it troublesome to setup a phone through command line.
To make it even harder, they could also require a verification code from your phone manufacturer, or the package of your device, which makes it impossible to automate the switch into power-user mode.
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.
I don't agree that this is something that should be restricted to "advanced" users, even. One of the basic freedoms that protects users from the unilateral control of the developers, is other developers (like me) being able to patch apps and distribute them to friends and family, without making a public fork or meeting play store requirements. Take for example, youtube revanced. If I want to help my friends by making a private f-droid or obtainium repository, to save them the trouble of going through the (legal!) process of patching and updating the app themselves, right now I can do this. If this requires going through a lengthy process instead, that may or may not be detectable by apps that will then choose to cease to function (this has happened with rooting), my ability to help friends and family as someone with the know-how and experience gets reduced significantly. There's many things that don't fly on the play store, such as the completely legal NewPipe, AdAway, and Termux applications, and while I can sign up for the developer verification, it's not clear to me under what circumstances the verification can be terminated.
That's by far not good enough. Google's reasoning is principally flawed.
First of all, there is principally no good reason why adult people should be patronized by Google or other companies and kept from installing the software they want to install. Limitation of numbers just means that I cannot publish my .apk and let users install it freely. However, anyone who is allowed to smoke, drink alcohol, or get a motorcycle, should also be allowed to install whatever application they want. It's a matter of basic individual freedom.
Second, the majority of reasonable users cannot be restricted from using their device as they wish just because a small minority falls for scams. A minority of people also drink themselves to death, die in motorcycle accidents, or smoke. There is nothing wrong with taking risks and taking responsibility for one's own life. We don't need for-profit corporations to hold our hands.
Third, if they believed their own arguments, then they'd make certain functions such as intercepting SMS messages and installing a custom keyboard subject to stricter requirements with potential developer verification and keep the OS open and free otherwise. This would be a piece of cake since the technical infrastructure is already there on Android. The fact that they don't clearly indicates they're hypocrites and want to control users and developers, make 3rd party app stores harder or impossible, control which apps they "allow" as part of anti-competitive behavior, and possibly extract some extra cash from developers in the future.
It's a pity how private computing is destroyed and that's the reason we all have to use inferior web apps until browsers are closed down in the same way in the name of security theater.
If adb is unrestricted and can work with the Linux command shell (something I seem to remember I had read about before; you will need to enable the developer mode to use it), which is aparently a separate system but runs on the same device, although if it has the ability to communicate with the main Android system using adb (which it might be reasonable to require that to be explicitly enabled with another setting, for additional security in case you do not use adb), then this would help since you do not require another computer that would be compatible with adb in order to do it.
However, I think there are other things they should do as well (in addition to the other things) if they want to improve the safety, such as looking at the apps in Google Play to check that they are not malware (since apparently some are; however, it says they do have some safeguards, so hopefully that would help), and to make the permission system to work better (e.g. to make it clear that it can intercept notificatinos; there are legitimate reasons to do this but it should require an explicit permission setting to make this clear).
Sorry, really confused user here, so can someone ELI5 for me? I was looking to go to GrapheneOS, will this effect that at all? The title now says they will allow side-loading and it sounds like good news but everyone in here is still complaining. I do not mind this extra step and I think it is way better than what my POS iPhone 16e with Liquid@ss is offing me.
"Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months. "
This is the last moment we can use to move out of this platform. We've already given basically all the control on our lives to two companies. They will decide one day that government will know our each move, our WiFi password, number of appliances, our body temperature and chemical compounds of our bodily fluids - every sensor that is connected to the system. 1984 all over again but this time IRL
This is old rule: you don't need to take over control of all the people, you just need to take over those two-three suppliers that are covering all the people. If for example new politician Tronald Dump will take seat in 2035 in USA and they will try to push their agenda to other countries, they will take over the LLM, phone and OS providers, namely OpenAI, MS, Apple, Google. That's all to control to have the souls ruled all over the world. If something must vanish, will vanish. Like in the Ministry of Truth
> That seems like a severe security bug in Android APIs or sandboxing or something else.
No, this is the permissioned API that makes KDE Connect work, which makes Apple's Continuity look like a toy and that also lets me programmatically filter notifications.
As soon as a platform gives control to the fullscreen, harmful apps are possible.
See for example Apple detecting if a user is typing on a keyboard while in a fullscreen website, and then blocking the website. Yes it's as crazy as it's sounds.
It's a permission the app can have. Android asks the user whether to allow it when you launch the app. It's a very useful permission for some apps that I use. But a scammer can just tell the user to accept the permission.
Super obvious move. It will probably make you type "I understand I am Gonna get haxxored" while clicking a moving dot 5 times and promising you are super power user. This would have been the end of android as a phone OS.
>we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
This is exactly the right thing to do and the best possible outcome. Google is correct that arbitrary Software installation can be harmful to users, especially those with limited technical knowledge. At the same time there are many users who want to install software freely and should be able to do so.
The compromise of a clear and unambiguous warning of the potential dangers, which the user is then allowed to accept, seems very good and the right thing to do.
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands.
Interesting. Did Google submit due to pressure? I have no idea. But if so then it shows the power people have. Perhaps we can make Google less evil if we complain a lot about things they do.
> Keeping users safe on Android is our top priority.
I'm really over third parties telling me that my safety is their priority. Unless you're transporting my body (ie, airline, ride share, etc), then I really don't need you to be looking out for my safety. See the problem is: when you do look out for my safety, you do it by giving yourself control over my life that is not healthy for either of us.
Let my safety be my concern, and the functionality of your product can be your top priority.
>This is why we announced this change early: to gather input and ensure our solutions are balanced.
Sounds like just trying to save face, they didn't have a language of "we're only _MAYBE_ stopping everyone from installing non-verified apps" back then. They were quite adamant.
But happy that they're dropping the craziest part of this in any case. Won't stop me from investigating Graphene OS and other options when getting my next handset though, the previous move surely caused a jolt in my interest.
"We have realised that boiling the frog this fast will result in it jumping out of the water. Therefore we have slowed down, but remain steadfastly devoted to seeing this frog boiled"
Actual title is "Android developer verification: Early access starts now as we continue to build with your feedback"
Two key announcements:
> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
> We are using your input to shape a dedicated account type for students and hobbyists. This will allow you to distribute your creations to a limited number of devices without going through the full verification requirements.
The student/hobbyist account type will most likely literally only be useful for that strict purpose, i.e. very small-scale distribution to a known quantity of people.
I think it was mentioned somewhere else that that account type would require manually authorising each individual installation, so it'd still be useless for small freeware developers, who are only in it for the fun, too, but want to give away their software to everybody who might find it useful.
Doesn't it mean Google will collect the app ids of all installs on all devices whether they are signed into an account or not.
I'm not naive to think its not happening today, whats probably new is them admitting to it.
How long does it take them to use that info to drop ban hammer on the user accountd for using apps like newpipe and hide behind reasons like violation of TnCs.
Bold move from Google — finally admitting the Play Store has a trust problem.
Verification sounds great on paper, but if this turns into “prove you’re a real dev by jumping through 12 forms of bureaucracy,” it’ll just push more talent to sideloading and open platforms.
Still, if Google actually nails this — transparent, fair, and fast — it could be the first time in years Android feels safer without feeling locked down. That’d be a plot twist I’d love to see.
If 90% of passengers were scamming the drivers or hijacking the car for some nefarious purpose that affects other cars, you definitely wouldn't find that silly.
I would think it is pretty silly if I needed some sort of verification to drive people I personally know around because other people were getting their car hijacked after choosing to pick up strangers they found on the highway.
Security by obscurity. That's my device, that's my decision to install whatever I want.
I see here and there some comments about someone was scammed, etc… Lack of knowledge of users is not a good reason. They still will get scammed, in a different way, but outcome will be the same.
On PC one can install whatever want - and nobody is blaming OS for it.
Google is about to find out the next step of this chain - give access to everyone, don't gatekeep / do checks, and yet take responsibility for anything that goes wrong.
"You should open up the tool, put no restrictions, and yet ensure that it is safe and secure" is an impossible task for anyone.
because they put restrictions. now they cannot. because all the restrictions meant saying no to some legit things as well - inevitably. but then they got sued, laws got passed, to not be monopolistic, and still secure the users. this is the aspect of tech saying no when the thing being asked is impossible but people assume because they dont want to do it for whatever reason.
"Keeping users safe on Android is our top priority." This is propaganda. It is a statement made to dissuade people from the real issue. The top priority is to make money.
It is hard to to trust anyone who starts communication with an obvious falsehood. Users beware.
If it doesn't require a Google account and just means jumping through a bunch of hoops the first time, maybe requiring a USB cable, OK. If it does require a Google account, or won't let you give permission to F-Droid to install stuff, I call foul.
"Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months."
So they haven't actually changed anything yet, but they say that they will "in the coming months."
Good job everybody, just don’t start complaining when your family members installed malware, their banking and health information is leaked, and you have to fix this for them.
I can access any website or webapp without verification. I can install any app on my PC without verification.
I assume the results of my actions and I accept that if something bad is going to happen, it's my fault. I am fine with that.
I want the same kind of freedom on my phone, a device I own and I payed for with my own money. I am not smarter when using the PC and dumber when using the phone. I want to be able to opt out of verification and install whatever I want.
They didn't say no changes. They are just saying we'll address the concerns of hobbyists and students.
Lets not celebrate prematurely and let us wait for more details on whats actually changing both technically and process wise. We should demand more clarity and should not wait to discover it after the implementation at which point it is hard and nearly impossible to push back against.
We don't want to be in a situation where they technically make it possible but make it practically impossible to install apps outside playstore.
I think you are correct. Clearly, they got spooked, but not enough to make full reversal. I am actually mildly optimistic. It has been a while since I saw a minority ( not that many people are aware of it outside HN circles ) shake a bigger company to a hesitation.
While we are at it, please also reject the framing of "sideloaded" apps. This framing pushes the use of legitimately installed, often high-quality, software to the periphery. This framing is an essential step in extinguishing our computing freedoms, as "sideloaded" apps are easily cast aside.
Recently I wanted to find a good app to manage my shopping lists as well as keep an ordering of this list so that I could run through the supermarket more efficiently. I really hate backtracking the supermarket to get some item on my list that I forgot was in a spot I'd already been. Of course, it had to work offline-first and I didn't mind a bit of configuration.
Everything on Google Play Store was some cloud-integrated garbage app. The only app that came even close was an app on F-droid called Aisleron, which lets you manage both your home stock and supermarkets in terms of "aisles" of products, flipping easily between what is in stock and what is needed and then managing an aisle-based sorting of these products per supermarket that I frequent.
Great App! However, I worry that this app would never have been released had Google considered actively blocking the author from creating legitimate and highly useful pieces of software like Aisleron.
Tying app distribution to a verified identity definitely raises the cost for scammers. But the devil's in the implementation. If "verification" ends up being too bureaucratic or expensive, it risks pushing legit indie devs and hobbyists away from the ecosystem entirely
This monopolist dictates its demands. It's pretty outrageous behaviour from a company that has grown by parasitizing Internet infrastructure built with taxpayer money. That's how far you get by bribing every US politician. It's a banana republic, a fucking shit show.
> his will allow you to distribute your creations to a limited number of devices without going through the full verification requirements.
Sorry, *allow*? ALLOW?
I'm sorry. My device. My software. My customer or friend.
You don't have the right to insert yourself into the process. Very kind of you to ALLOW me to do something you have no involvement in whatsoever.
Like everything google do the real reason for the plan is to let google insert themselves unwanted into someone elses business so they can extract money from other people's work.
I would bin my android phone now if the alternatives weren't even worse,
I have been an Android fan-boy since 2010 (hello HTC Evo!). Blackberry until that. Never owned an iPhone until a month ago.
There really is not a benefit to owning an Android smartphone anymore if they are going to knee-cap F-Droid.
If they had gone ahead and blocked local installs, and forced every apk to be signed by a registered developer, I'm assuming there would have been a strong push for a viable Linux on these devices.
I worry that the overton window has shifted so much after over a decade and a half of most downloads being mediated by "app stores" that most people don't realize or have the means to vocalize or understand what they're missing.
That blog post really downplays the issue that people have with the verification requirement and is tone-deaf. The resistance to get Google's blessing for app distribution is definitely not limited to students and hobbyists - and I don't think that's even the biggest affected group.
Great! Based on this, I would like to sign up to get early access to Android Developer Console (to distribute apps ONLY outside the Play store). The article explains that they will start sending out invitations to people on the waiting list.
But it does not say (or I can't find it) how to JOIN the waiting list. Does anyone know how?
I have to admit I couldn't even understand this problem, because for me the "stock OS" is already unbearable and I'd simply never be able to use it - I've never used it for more than a hour..
The issue is that of network effects. Making it harder to sideload for example f-droid makes the already small market for it even smaller, leading to less apps. It also forces people developing Apps that they don't want to reveal to be developing for completly valid reasons (Imagine developing a porn app in saudi arabia or an abortion support app in the USA) to validate against google aka the US Government.
I'm just presenting my exotic point of view - since that developer verification would only be needed to run apps on the "stock OS" (which I consider bad), then deliberately excluding it could promote using LineageOS/GrapheneOS which would be a good thing.
But of course I'm talking about non-commercial apps, but commercial app developers would already be on Google Play.
As to relevance to the article - I'm not cheering that much because if Google made "stock OS" even worse then maybe more users would flock to LineageOS/GrapheneOS which would be a great thing and make it harder to push Play Integrity.
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=38505229), the new owner was able to push any user-hostile changes they wanted to all users who had installed the original app through Google Play (that's the very reason why the initial app could be sold in the first place, to exploit a large, preexisting user base that had the initial version installed).
That was not the case on F-Droid, which blocked the new user-hostile version and recommended the open source fork (Fossify Apps). (see also this comment: 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.
Perhaps because Apple never “promised” to be open, Google instead built itself by playing the good guy and started to switch when money called so those who chose them for that reason feel betrayed.
I guess they are going to say whatever to prove the case. The legislation system is highly...closed and shun of laymen.
It's the JUDGE that came up with that reasoning.
Because that's the law, like it or not. Apple doesn't have a problem because the rules were the rules from day 1. Google did a bait and switch, legally.
What does antitrust law have to do with "day 1"? So if Ford and GM are both already in all 50 states and then they try to divide up territory between them, that's illegal, but at the point when there were still areas one of them wasn't in, they could publicly announce a contractual agreement to not enter into the other's territory? That seems not just questionable but actively bad policy with an enormous perverse incentive.
And if you're going to say this:
> Because that's the law, like it or not.
I would ask you to point me to the text in the statute requiring the courts to do that.
Yeah it's the judge.
I think you missed the point that judges aren't part of the legislative branch. They're in the judicial branch.
Please allow me to correct my bad English and replace it with "the law circle".
[dead]
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.
> But the ruling is correct. You can't have it both ways, if you invite competition you're not allowed to be anti-competitive
That's just stupid, because being anti-competitive is an emergent outcome, rather than anything specific.
Apple is definitely anti-competitive, but they exploited such a ruling so that they can skirt it. Owning a platform that no other entrants are allowed is anti-competitive - whether you're small or large. It's only when you're large that you should become a target to purge via anti-competitive laws. This allows small players to grow, but always face the threat of purging - this makes them wary of trying to take advantage too much, which results in better consumer outcomes.
That's like Karcher opening a megamall to sell all their offering, vacuums, pressure washers, floor washers, you name it .. and then you, Bosch, complaining you can't sell your vacuum in Karcher's megamall where all the people go.
What are you even saying?
Whereas google was letting Bosch sell vacuums in their megamall, but only if it uses Google dust filters and people buy only Google made dust filters and Bosch isn't allowed to sell their own dust filters in the megamall.
It's like a company buying all the land within a 100 mile radius and then nominally "selling" plots to people but with terms of service attached that restrict what you can do with the land you bought and that allow the company to change the terms at any time. And then, after people have moved in, most of them having not even read the terms or realized it wasn't an ordinary sale, they start enforcing the terms against competitors. Which most people don't notice because they aren't competitors, and because the terms also prohibited anyone in the city from telling people what's going on[1]. Then people eventually notice and start to ask whether terms locking out competitors like that are an antitrust violation, and someone says that they're not because the people there agreed to them.
[1] https://som.yale.edu/sites/default/files/2022-01/DTH-Apple-n...
But how is an agreement prohibiting people from patronizing competitors not an antitrust violation? It's not a matter of who agreed to it, it's matter of what they're requiring you to agree to.
> nominally "selling" plots to people but with terms of service attached that restrict what you can do with the land you bought and that allow the company to change the terms at any time.
So, a lease.
That's, to begin with, not even how a lease generally works. A lease isn't where you pay once up front to take permanent possession of something.
Moreover, did people buying iPhones on "day 1" think they were buying them or leasing them? Did Apple call it a sale or a rental agreement?
> Karcher opening a megamall to sell all their offering
And their mall is monopolistic if it is only for Karcher products. However, because a competitor can easily open a mall next door, it means this Karcher mall is small, and so the enforcers should leave it be. Until the day Karcher buys up all the mall space, in which case, they (regulators) start purging their mall monopoly.
The threat of being purged because you've acquired a large enough monopoly should _always_ be there. It's part of doing business in a fair environment.
> You can be Nintendo, offer a single store, only allow first party hardware, and exercise total control over your product.
How is this not even more anti-competitive?
It's fine to be mad at Google for being duplicitous, but treachery is in the nature of false advertising or breach of contract. Antitrust is something else.
"You can monopolize the market as long as you commit to it from the start" seems like the text of the law a supervillain would be trying pass in order to destroy the world.
You can't monopolize a market where there is no market. Nintendo can be anticompetitive in the wider games industry, but there is no market for software that runs on a Switch.
I didn't say I liked the ruling, just that it's correct. The opposite conclusion would be absurd, that you can invent a market where there isn't one and claim a company has a monopoly over it. You would be asking the court to declare that every computing device is a de facto marketplace for software that could run on it and that you can't privilege any specific software vendor. I would love if that were true but you can hopefully agree that such a thing would be a huge stretch legally.
> You can't monopolize a market where there is no market. The opposite conclusion would be absurd, that you can invent a market where there isn't one and claim a company has a monopoly over it.
There is no such thing as "there is no market". There is always a market. The question is, what's in the market? The typical strategy is to do the opposite -- have Nintendo claim that they're competing with Sony and Microsoft in the same market to try to claim that it isn't a monopoly.
But then the question is, are they the same market? So to take some traditional examples, third party software that could run on MS-DOS could also run on non-Microsoft flavors of DOS. OS/2 could run software for Windows. The various POSIX-compliant versions of Unix and Linux could run the same software as one another. Samsung phones can run the same apps as Pixel phones. Which puts these things in the same market as each other, because they're actually substitutes, even though they're made by different companies.
Conversely, you can't run iOS apps on Android or get iOS apps from Google Play or vice versa. It's not because they're different companies -- both of them could support both if they wanted to -- it's that they choose not to and choices have consequences.
If you intentionally avoid competing in the same market as another company then you're not competing in the same market as that company and the absurdity is trying to have it both ways by doing that and then still wanting to claim them as a competitor.
You avoided the important part, there is no market for hardware that can play Nintendo Switch games and there is no market for software providers on Nintendo Switch. And they are legally allowed to do that. You can sell appliances that are bound to a single vendor and you are allowed to not license your hardware or software to 3rd parties.
Since that is a legally permissible action it would be an odd thing for a court to declare that doing such a thing is anticompetitive. If they did they would be declaring all locked down hardware effectively illegal. And while that might be nice it's a bit of a pipedream. Where Google fucked up is that they did license their software to 3rd parties—good for them. But then Google had some regrets and didn't like the fact that they didn't have control over those 3rd parties. But they did have some leverage in the form of Google Play and GSM because users expect it to be there on every Android phone. And then they used that leverage. That's the fuckup. They used Google Play and GSM access to make 3rd parties preinstall Chrome and kill 3rd party Android forks. They used anticompetitive practices on their competitors—other Android device manufacturers.
This situation can't occur for Apple or Nintendo because there aren't other iOS/Switch device manufacturers and they don't have to allow them to exist. They can be anticompetitive for other reasons but not this.
> You avoided the important part, there is no market for hardware that can play Nintendo Switch games and there is no market for software providers on Nintendo Switch.
There is a market for these things. Nintendo sells hardware that can play Nintendo Switch games and people buy it. That's a market.
It seems like you're trying to claim that a monopoly isn't a market, but how can that possibly be how antitrust laws work? Your argument is that they don't apply to something if it is a monopoly?
> And they are legally allowed to do that.
That's just assuming the conclusion. Why should it be legal for them to exclude competitors from selling software to their customers? The obviously anti-competitive thing should obviously be a violation of any sane laws prohibiting anti-competitive practices. The insanity is the number of people trying to defend the practice.
Consider what it implies. 20th century GE could have gone around buying houses, installing a GE electrical panel and then selling the houses with a covenant that no one could use a non-GE appliance in that house ever again, or plug in any device that runs on electricity without their permission. They could buy and sell half of all the housing stock in the country and Westinghouse the other half and each add that covenant and you're claiming it wouldn't be an antitrust violation.
Apple wouldn't have been able to get their start because they'd have needed permission from GE or Westinghouse for customers to plug in an Apple II or charge an iPhone and they wouldn't get it because those companies were selling mainframes or flip phones and wouldn't want the competition. If that's not an antitrust violation then we don't have antitrust laws.
> If they did they would be declaring all locked down hardware effectively illegal.
It's fine for hardware to be locked down by and with the specific permission of the person who owns it. But how is it even controversial for the manufacturer locking down hardware for the purpose of excluding competitors to be a violation of the laws against inhibiting competition? It's exactly the thing those laws are supposed to be prohibiting.
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.
We'll have to initiate solid self defense protocol though. I think the first thing we should do is get a new logical fallacy term officially coined.
Stallman/StallManned Abusing the principles of the Slippery Slope to discredit perfectly rational predictions
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.
That's true. The whole point of an open ecosystem is that you get to decide who you get your software from. You can decide on the official F-Droid repository and get the benefits and drawbacks of a strict open source rule with the F-Droid organization's curation if that's your preference. You can add other repositories with different curation if you prefer that.
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.
Anyone determined enough can break into any house. If not through ingenuitiy, then by a brick to your window. Doesn't mean we shouldn't lock our doors, turn off our lights, and close our curtains anyway.
The fortunate thing is that 99% of people won't bother trying to break your app if it's not dead simple. Advanved security mechanisms to check for backdoors is probably something only billionaire tech companies need to worry about.
You totally misunderstand the threat model. It's not about anybody breaking your app. It's about people making their own apps do things they're not supposed to do.
... and there's always a tradeoff in terms of how much of a deterrent anything is. The app store checks are barely measurable.
The app store checks are barely measureable, yes. Hence why being open source is the best check for any undocumented changes. Even if it's not discovered on FDoid, reports will come out for those who dig. Much easier to view source code than decompiling an APK to analyze.
But at some point there needs to be some level of trust in anything you install. You can't rely on institutions to make sure everything is squeaky clean. They can't even do that on content platforms (or at least, they choose not to afford it).
> 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.
Can you give some examples? I've heard that's a thing, but I'm not familiar with any apps that actually pull it off (reproducible builds are difficult to achieve)
Reproducible builds may be hard to achieve, but that doesn't mean you don't have a list of such builds long enough to crash your browser: https://verification.f-droid.org/verified.html
Weird to have a page like that if a human can't use it. Needs some pagination, f-droid!
It's like we're supposed to save the page and grep it or something. Doesn't work in my Firefox.
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/
I trust them, at least a lot more than I do Google, which is a known bad actor, and collaborator with "TLAs". F-Droid has been around for a very long time, if you didn't know. They've built and earned the trust people have in them today.
> Didn’t F-Droid have 20 or so apps that contained known vulnerabilities back in 2022?
Idk what specific incident you're referring to, but since they build apks themselves in an automated way, if a security patch to an app breaks the build, that needs to be fixed before the update can go out (by F-Droid volunteers, usually). In that case, F-Droid will warn about the app having known unpatched vulnerabilities.
Again, this is above and beyond what Google does in their store. Google Play probably has more malware apps than F-Droid has lines of code in its entire catalog.
This incident
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11496
Right, that's literally the team marking 12 apps as having known vulnerabilities (seems like it was because of a WebRTC vulnerability that was discovered). It's the F-Droid system working as intended to inform users about what they're installing.
You're calling it an incident like it was an attack or something, but it just seems like everyday software development. Google Play and the App Store don't let me know when apps have known vulnerabilities. I think F-Droid is coming out way ahead here.
So Google and Apple are already known to work with US government agencies. This was revealed in the Snowden leaks in 2013, and confirmed on multiple occasions since. Neither Google nor Apple tell you when apps you're downloading from the store contain known vulnerabilities. We know for a fact that both Google Play and the App Store are filled with scams and malware: it's widely documented.
So to my reading F-Droid comes out ahead on every metric you've listed: It has no known associations with US government agencies. They do inform you when your apps have known vulnerabilities. I'm not aware of any cases of scams or malware being distributed through F-Droid.
I highly recommend it. It's the main store I've been using on my phone for probably more than a decade now.
Because you can literally verify every single step of what they do. That's the reason you can trust them.
You cannot apply this logic to almost anyone else. Apple, Google, etc. can only give you empty promises.
I understand your concern, though your suspicion is a little shortsighted. It can be personally dangerous to volunteer for projects that directly circumvent the control of the establishment.
> Who is F-Droid? Why should I trust them?
For the same reason you trust many things. They have a long track record of doing the right thing. As gaining reputation for doing the wrong thing would more or less destroy them, it's a fair incentive to continue doing the right thing. It's a much better incentive that many random developers of small apps in Google's play store have.
However, that's not the only reason to trust them. They also follow a set of processes, starting with a long list of criteria saying what app's they will accept https://f-droid.org/docs/Inclusion_Policy/ That doesn't mean malware won't slip past them on occasion, but if you look at the amount of malware that slips past F-Droid and projects with similar policies like Debian and compare them to other app stores like Google's, Apple and Microsoft there is no comparison. Some malware slips past Debian's defences once every few years. I would not be surprised if new malware isn't uploaded to Google app store every few minutes. The others aren't much better.
The net outcome of all that is the open source distribution platforms like F-Droid and Debian, that have procedures in place like tight acceptance policies and reproducible builds are by a huge margin the most reliable and trustworthy on the planet right now. That isn't saying they are perfect, but rather if Google's goal is to keep their users safe they should be doing everything in their power to protect and promote F-Droid.
> How do I know they aren’t infiltrated by TLAs? (Three Letter Agencies), or outright bad-actors.
You don't know for sure, but F-Droid policies make it possible to detect if the TLA did something nefarious. The combination of reproducible builds, open source and open source's tendency to use source code management systems that provide to audit trail showing who changed every line shine a lot of sunlight into the area. Sunlight those TLA's your so paranoid about hate.
This is the one thing that puzzles me about F-Droid opposition in particular. Google is taking a small step here towards increasing accountability of app developers. But a single person signing an app is in reality a very small step. There are likely tens if not hundreds of libraries underpinning it, developed by thousands of people. That single developer can't monitor them all, and consequently libraries with malware inserted from upstream repositories like NPM or PyPi regularly slips through. Transparency the open source movement mostly enforces is far greater. You can't even modify the amount of whitespace in a line without it being picked up by some version control system that records who did it, why they did it, and when. So F-Droid is complaining about a small increase in enforced transparency from Google, when they demand far, far more from their contributors.
I get that Google's change probably creates some paper-cuts for F-Droid, but I doubt it's something that can't be worked around if both sides collaborate. This blog post sounds like Google is moving in that direction. Hear, hear!
> They also follow a set of processes, starting with a long list of criteria saying what app's they will accept
How is this an argument in favour of being able to run whatever software you want on hardware you own?
You can run any software you like on Android, if it's open source. You just compile it yourself, and sign it with the limited distribution signature the blog post mentions. Hell, I've never done it, but re-signing any APK with your own signature sounds like it should be feasible. If it is, you can run any APK you want on your own hardware.
Get a grip. Yes it might be possible the world is out to get you. But it's also possible Google is trying to do exactly what they say on the tin - make the world a safer place for people who don't know shit from clay. In this particular case, if they are trying to restrict what an person with a modicum of skillz can do on their own phone it's a piss poor effort, so I'm inclined to think it's the latter. They aren't even removing the adb app upload hole.
>> 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.
No I didn't. Finish reading the rest of the comment.
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.
See that's what the intent system was originally designed to prevent.
Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
Similarly for the camera.
And in fact, it should have no network access whatsoever (and network should be a user controllable permission, as it used to be — the only reason that was removed is that people would block network access to block ads)
> And in fact, it should have no network access whatsoever (and network should be a user controllable permission, as it used to be — the only reason that was removed is that people would block network access to block ads)
Sure, a QR code scanner can work fine without network. E.g. it could use the network to check a scanned URL against the "safe browsing API" or to pre-fetch the URL and show me a nice OG preview. You are correct to say you may not need nor want this. But I and others may like such features.
Point is not to discuss wether a QR scanner should have network-access, but to say that once a permission is there for obvious or correct reasons, it can in future easily get abused for other reasons. Without changing the permissions.
My mail-app needs network. Nothing prohibits it from abusing this after an update to pull in ads, or send telemetry to third parties. My sound record app needs microphone permissions. Nothing prohibits it from "secretly" recording my conversations after an update (detectable since a LED and icon will light up).
If you want to solve "app becoming malicious after an update", permissions aren't the tool. They are a tiny piece of that puzzle, but "better permissions" aren't the solution either. Nor is "better awareness of permissions by users".
> See that's what the intent system was originally designed to prevent.
> Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
On the one hand, yes, good point, but it runs into the usual problem with strict sandboxing – it works for the simple default use case, but as soon as you want to do more advanced stuff, offer a nicer UI, etc. etc. it breaks down.
E.g. barcode scanners – yes, technically you could send a media capture intent to ask the camera app to capture a single photo without needing the camera permission yourself, but then you run into the problem that maybe the photo isn't suitable enough for successful barcode detection, so you have to ask the user to take another picture, and perhaps another, and another, and…
So much nicer to request the camera permission after all and then capture a live image stream and automatically re-run the detection algorithm until a code has been found.
>...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.
It's weird because GrapheneOS does have this. Networking is a permission on Android, but stock Android doesn't give you the setting.
I believe that permission is currently "leaky". The app can't access the network but it can use Google Play services to display ads.
I believe that would theoretically allow exfiltration of data but I don't understand all of the details behind this behavior and how far it goes.
Google wants 0 friction for apps to display ads.
So does Apple apparently.
What incentive is there for OEMs to not add this option though? Does Google refuse to veriy their firmware if they offer this feature?
The network permission was displayed in the first versions of Android, then removed. I heard (hearsay alert) at the time that it was because so many apps needed it, and they wanted to get rid of always-yes questions. IIRC this happened before the rise of in-app advertising.
If people always answer yes, they grow tired and eventually don't notice the question. I've seen it happen with "do you want to overwrite the previous version of the document you're editing, which you saved two minutes ago?" At that point your question is just poisoning the well. Makes sense, but still, hearsay alert.
As far as I'm concerned they can grant this permission by default. I just want the power to disable it.
A while ago I wanted to scan the NFC chip in my passport. Obviously, I didn't want this information to leave my device.
There are many small utility apps and games that have no reason to require network access. So "need" is not quite the right word here. They _want_ network access and they _want_ to be able to bully users into granting it.
That's a weird justification for granting it by default. But I wouldn't care if I could disable it.
Android doesn't grant this by default, strictly speaking. Rather, an application can enable it by listing it in the application manifest. Most permissions require a question to to the user.
Did you find a suitable app? I don't really remember, but https://play.google.com/store/apps/details?id=com.nxp.taginf... might suit you.
I did find one but it was years ago so I don't remember.
Could have been easily solved by granting it by default, but I doubt that was original intent.
Well, the original intent was to ask the user for permission at installation time, which turned out to be a poor idea after a while. Perhaps you mean that it would have been simple to change the API in some particular way, while retaining compatibility with existing apps? If I remember the timeline correctly, which is far from certain, this happened around the same time as Android passed 100k apps, so a fairly strong compatibility requirement.
I mean, just make it "Granted" by default and give user ability to control it. Permissions API was already broken few times(i.e. Location for bluetooth and granular Files permissions)
> Does Google refuse to veriy their firmware if they offer this feature?
If a manufacturer doesn't follow the Android CDD (https://source.android.com/docs/compatibility/cdd), Google will not allow them to bundle Google's closed source apps (which include the Google Play store). It was originally a measure to prevent fragmentation. I don't know whether this particular detail (not exposing this particular permission) is part of the CDD.
It's not explicitly part of the CDD, but implicitly. The device must support the Android permissions model and is only allowed to extend this implementation using OWN permissions (in a different namespace than 'android'), but not allowed to deviate from it.
INTERNET is a "normal permission", automatically granted at install time if declared in the manifest. OEMs cannot change the grant behavior without breaking compatibility because:
The CDD explicitly states that the Android security model must remain intact. Any deviation would fail CTS (Compatibility Test Suite) and prevent Play certification.
Well, apart from the OEM violating the Android Compatibility Definition Document (CDD), failing the Compatibility Test Suite (CTS) and thus not getting their device Play-certified (so not being able to preload all the Google services, there is an economical impact as well:
As OEM you want Carriers to sell your device above everything else, because they are able to sell large volumes.
Carriers make money using network traffic, Google is paying Revenue-Share for ads to Carriers (and OEMs of certain size). Carriers measure this as part of the average revenue per user (ARPU).
--> The device would be designed to create less ARPU for the Carrier and Google and thus be less attractive for the entire ecosystem.
It is solvable from user space.
E.g. TrackerControl https://github.com/TrackerControl/tracker-control-android can do it, it is a local vpn which sees which application is making a request and blocks it.
You can write your own version of it if you don't trust them.
I've been using a similar VPN solution. It works great for apps that absolutely should not be connected, like my keyboard. But it has an obvious downside: you can't use a VPN on your phone while you're using that.
Some apps would use this for loopback addresses, which as far as I know will then need network permission. The problem here is the permission system itself because ironically Google Play is full of malicious software.
And neither Android nor iOS a safer than modern Desktop systems. On the contrary because leaking data is its own security issue.
Wasn't the loopback address recently used maliciously?
Yes. Facebook/Meta was using a locally hosted proxy to get info smuggled back without using routes that are increasingly obstructed by things like ad blockers if I recall correctly.
https://securityonline.info/androids-secret-tracking-meta-ya...
Search string for DDG: Meta proxy localhost data exfiltration
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.
Same for Play Store. I have 2 games and I keep getting offers all the time. The last one offered $2000 for the developer account or a $100 monthly rent.
From their email pitch:
> We’re now offering from $500 to $2000 for a one-time purchase of a developer account that includes apps, or a rental deal starting from $100.
> No hidden conditions — quick process, secure agreement, and immediate payment upon verification.
> We’re simply looking for reliable accounts to publish our client apps quickly, and yours could be a perfect match.
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.
> Indeed, an update can't be more malicious than the permissions allow it to be.
...in the absence of sandbox escape bugs.
> 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]
From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.) The “Why verification is important” section of this blog post goes into a bit more detail (see also the We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer), but ultimately the point is:
there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I don't buy this argument at all that this specific implementation is under pressure from the government - if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps in the first place! Why should apps have access to a user's SMS / RCS? (Yeah, I know it makes onboarding / verification easy and all, if an app can access your OTP. But that's a minor convenience that can be sacrificed if it's also being used for scams by malware apps).
But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy. And that's why they have come with such convoluted implementation that further give them control over a user's device. Obviously some government's too may favour such an approach as they too can then use Google or Apple to exert control over their citizens (through censorship or denial of services).
Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them. This is just the "boil the frog slowly" approach. Once this is normalised, they will make a move to prevent sideloading completely, again, in the future.
> Why should apps have access to a user's SMS / RCS?
It could be an alternative SMS app like TextSecure. One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
It could also be a SMS backup application (which can also be used to transfer the whole SMS history to a new phone).
Or it could be something like KDE Connect making SMS notifications show up on the user's computer.
That's all indeed valid.
> One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
When sideloading is barred all that can easily change. If you are forced to install everything from the Google Play Store, Google can easily bar such things, again in the name of "security" - alternate keyboards can steal your password, alternate browsers can have adware / malware, alternate launcher can do many naughty things etc. etc.
And note that if indeed giving apps access to SMS / RCS data is really such a desirable feature, Google could have introduced gate-keeping on that to make it more secure, rather than gate-keeping sideloading. For example, their current proposal says that they will allow sideloading with special Google Accounts. Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
The point is that they want to avoid adding any barriers where a user's private data can't be easily accessed.
> Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
Because then you still need a special Google Account to install your app when it needs to access SMS / RCS.
How about solving this problem in a way that doesn't involve Google rather than the owner of the device making decisions about what they can do with it? Like don't let the app request certain permissions by default, instead require the user to manually go into settings to turn them on, but if they do then it's still possible. Meanwhile apps that are installed from an app store can request that permission when the store allows it, so then users have an easy way to install apps like that, but in that case the app has been approved by Google or F-Droid etc. And the "be an app store" permission works the same way, so you have to do it once when you install F-Droid but then it can set those permissions the same as Google Play.
It's not Google's job to say no for you. It's only their job to make sure you know what you're saying yes to when you make the decision yourself.
>instead require the user to manually go into settings to turn them on, but if they do then it's still possible
They clearly addressed this option in the post, under sufficient social engineering pressure these settings will easily be circumvented. You'd need at least a 24h timeout or similar to mitigate the social pressure.
> They clearly addressed this option in the post, under sufficient social engineering pressure these settings will easily be circumvented. You'd need at least a 24h timeout or similar to mitigate the social pressure.
"Under sufficient social engineering pressure" is the thing that proves too much. A 24h timeout can't withstand that either. Nor can the ability for the user to use their phone to send money, or access their car or home, or read their private documents, or post to their social media account. What if someone convinces them to do any of those things? The only way to stop it is for the phone to never let them do it.
By the time you're done the phone is a brick that can't do anything useful. At some point you have to admit that adults are responsible for the choices they make.
>By the time you're done the phone is a brick that can't do anything useful. At some point you have to admit that adults are responsible for the choices they make.
Absolutely this! It's just nanny state all over again.
This is somehow even worse. It's strictly enforced with no regard for context, you don't have the constitutional rights you have against the government and you can't vote them out.
Markets are supposed to be better because you can switch to a competitor but that only applies when there is actually competition. Two companies both doing the same thing is not a competitive market.
It'd just devolve into security whack a mole about what permissions need those special account or not, ending with basically all of them making it the same as just needing dev verification anyway for anything remotely useful.
And despite that, you assuming that dev verification means no malware. The Play Store requires developers to register with the same verification measures we're talkingand malware is hardly unheard of there.
> alternate keyboards can steal your password, alternate browsers can have adware / malware, alternate launcher can do many naughty things etc. etc.
It's plausible that Google is done some of these things, like doing some sort of data mining on everything that you type for example (steal your password), and many official google apps have ads if you don't pay them
Definitely. All mobile keyboards become keyloggers if you enable the spellcheck feature or autocomplete / suggestion feature or any AI feature on it (because they need to collect data to "improve service"). Apple also has made changes to its mobile OS when it helps data collection. E.g Allowing messenger apps like WhatsApp to integrate with the Phone app ensures that Apple now knows who you call (voice / video) on WhatsApp.
I'm not sure it's entirely fair to say this is just Google flexing control
Last year Australians reported losing AU$20 million to phishing attacks, and AU$318 million to scams of all types.
It stands to reason that financial service industry peak bodies are in conversation with governments and digital service providers, including data providers, to try to better protect users.
There are obvious conflicting goals, and the banks / governments can’t really appear to be doing nothing.
And technical users are probably most certainly lacking a representative at the table, and are the group that has the least at stake. Whacko fringe software-freedom extremists, they probably call us.
Does that mean that the Google and the government are taking full legal liability for protecting me from scams?
Yeah. I mean the irony is that the one advantage of having a controlled and monitored app store would be that the entity monitoring it enforces certain standards. Games don't need access to your contacts, ever. If Google Play would just straight up block games that requested unnecessary permissions, it might have value. Instead we have 10,000 match-three games that want to use your camera and read all your data and Google is just fine with that. If the issue was access to personal data, a large proportion of existing apps should just be banned.
I really think all permissions systems need what we had back in xposed/appops days:
Permissions should ~always be "accept (with optional filters)", "deny", and "lie". If the game wants contacts access and won't take no for an answer, I should be able to feed it a lie: empty and/or fake and/or sandboxed data. It's my phone and my data, not the app's.
We had it over a decade ago, xposed supported filtered and fake data for many permissions. It's strictly user-hostile that Android itself doesn't have this capability.
re OTPs, there's a special permission-less way to request sms codes, with a special hash in the content so it's clearly an opt-in by both app and sender: https://developers.google.com/identity/sms-retriever/overvie...
so no, it's not necessary at all. and many apps identify OTPs and give you an easy "copy to clipboard" button in the notification.
but that isn't all super widely known and expected (partly because not all apps or messages follow it), so it's not something you can rely on users denying access to.
Playstore is the one that contains majority of the malware and people get it only that way. I rarely know of people side-loading that have issues.
https://www.google.com/search?q=ars+technica+playstore+malwa...
Installing apps from sources that are not the Play Store requires a bit of technical knowledge anyway. My grandma is not going to download a random APK and give all the necessary permissions to install it and run it.
It’s been a few months since I used an Android device.
What was the process? Enable developer mode and grant ’can install apps’ to a browser or file browser?
Am I remembering this correctly?
The only other step is to download a file from the internet, or otherwise receive one. That’s not a technical-knowledge step though
no, that is not done via developer mode. When You download or try to open an apk from any app, it asks you if you want to allow it to install apps and send you to the configuration dialog. You still have to validate the app installation manually tbrough another dialog. In that case I usually leave the config dialog open while the app is installed, then disable the app permission right after install because that option is usually not easy to find. I usually only do it once on a new smartphone to install f-droid from a browser then allow f-droid and aurora store permanently.
I think that is the part that should be fixed, users should be able to allow a one time exception to avoid letting that permission activated by mistake. I don't need to allow permanently a web browser to install apps.
Point being: it’s easier than my middle aged blue collar tradesman’s brain remembered it.
The comment I replied to tried to tell us some technical knowledge required.
Doesn’t sound like it?
Because Tasker is fundamental for some. Those arguments are similar to "think of children".
> Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them.
This blog post is specifically saying there will be a way to bypass the gatekeeping on Google-blessed Android builds, just as we wanted.
> But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy.
Despite this, they sell some of the most privacy-capable phones available, with the Pixels having unlockable bootloaders. Even without unlocking the bootloader to install something like GrapheneOS, they support better privacy than the other mass market mobile phones by Samsung and Apple, which both admittedly set a low bar.
I concur.
If they are concerned about malware then one of the obvious solutions would be safe guarding their play store. There is significant less scam on iphone because apple polices their app store. Meanwhile scam apps that i reported are still up on google play store.
>Why should apps have access to a user's SMS / RCS?
can you imagine the outrage from all the exact same people who are currently outraged about develeloper verification if google said they were cutting off any third-party app access to SMS/RCS?
> if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps
Then you'd have the other "screaming minority" on HN show up, the "antitrust all the things" folks.
The "let's actually enforce antitrust laws" people are in the majority:
https://today.yougov.com/economy/articles/47798-most-america...
https://www.antitrustinstitute.org/wp-content/uploads/2024/1...
Your first link shows a graph that indicates more than 50% of Americans believe there is at least some competition, or a lot of competition; and that less than 1/3rd believe there is not enough, or no, competition in every sector of the economy that would be relevant to this discussion.
And that most Americans believe that bigger companies tend to have lower prices than smaller ones.
It’s not particularly clear then that there should be a lot of motivation to change things.
You're choosing the questions that have framing issues:
> more than 50% of Americans believe there is at least some competition, or a lot of competition in every sector of the economy that would be relevant to this discussion.
We're talking about Google and Apple but the relevant category would be "technology companies". Do phone platforms or mobile app distribution stores have "a lot of competition"? It's hard to see how anybody could think that. Do games and AI and web hosting? Sure they do. But they're lumping them all together.
They're also using "some competition" as the second-to-highest amount of competition even though that term could reasonably apply to a market where one company has 90% market share but not 100%, and it's confusingly similar to "not much competition". And they're somehow showing oil and gas as having less competition than telecommunications when oil and gas is a textbook fungible commodity and telecommunications is Comcast. That question has issues.
> And that most Americans believe that bigger companies tend to have lower prices than smaller ones.
This is the thing where Walmart has lower prices than the mom and pop. That doesn't imply that Walmart has better quality or service than a smaller company, and it doesn't imply that Walmart is operating in a consolidated market. Retail is objectively competitive in most areas.
Whereas when a big company is in a consolidated market, "big companies tend to have lower prices" doesn't hold and you get Google and Apple extracting 30%.
Moreover, the relevant part of that link was this part: More than two thirds of people, including the majority of both parties, support antitrust laws, six times as many people think they're not strict enough than think they're too strict and significantly more people agree with "the government should break up big tech" than disagree.
On the other hand, maybe if the railways weren’t broken up the USA might have been crisscrossed with high speed rail by now.
Then we could argue how high speed rail would have been cheaper if the railways had been broken up.
PS I appreciate your thoughtful response, and your contributions to HN more generally.
> On the other hand, maybe if the railways weren’t broken up the USA might have been crisscrossed with high speed rail by now.
Eh. The rails themselves are a natural monopoly in the same way roads are. It's one of the few things it makes sense to have the government build, or at least contract to have someone build, and then provide to everyone without restriction.
Meanwhile train cars and freight hauling and passenger service aren't any more of a natural monopoly than taxis or trucks. They get monopolized if someone is allowed to leverage a monopoly over the tracks into a monopoly over the rest of it, but that's unnecessary and undesirable. Separating them out allows the market that can be competitive to be competitive. Which is the same reason you don't want a tech monopoly leveraging it into control over ancillary markets that could otherwise be competitive.
There are two main reasons train service in the US is a shambles. The first is that the population density is too low, especially in the west. How many people do you expect to be riding a train from Boise to Des Moines on a regular basis? And the second is that truck drivers don't like freight rail, car companies don't like passenger rail and oil companies don't like either one, and they all lobby against anything that would make it better in the parts of the country where it could actually work. It's hard to make something good when there are millions of voters and billions of dollars trying to get it to suck.
Its a fact even if you dont buy this
Google have their own reasons too. They would love to kill off YouTube ReVanced and other haxx0red clients that give features for free which Google would rather sell you on subscription.
Just look at everything they've done to break yt-dlp over and over again. In fact their newest countermeasure is a frontpage story right beside this one: https://news.ycombinator.com/item?id=45898407
I can easily believe that Google's YouTube team would love to kill off such apps, if they can make a significant (say ≥1%) impact on revenue. (After all, being able to make money from views is an actual part of the YouTube product features that they promise to “creators”, which would be undermined if they made it too easy to circumvent.)
But having seen how things work at large companies including Google, I find it less likely for Google's Android team to be allocating resources or making major policy decisions by considering the YouTube team. :-) (Of course if Android happened to make a change that negatively affected YouTube revenue, things may get escalated and the change may get rolled back as in the infamous Chrome-vs-Ads case, but those situations are very rare.) Taking their explanation at face value (their anti-malware team couldn't keep up: bad actors can spin up new harmful apps instantly. It becomes an endless game of whack-a-mole. Verification changes the math by forcing them to use a real identity) seems justified in this case.
My point though was that whatever the ultimate stable equilibrium becomes, it will be one in which the set of apps that the average person can easily install is limited in some way — I think Google's proposed solution here (hobbyists can make apps having not many users, and “experienced users” can opt out of the security measures) is actually a “least bad” compromise, but still not a happy outcome for those who would like a world where anyone can write apps that anyone can install.
I would like a world where buying something means you get final say over how it operates even if you might do something dangerous/harmful/illegal.
I would like a world where I have the final say over whether I should have a final say.
One way to achieve this is to only allow sideloading in "developer mode", which could only be activated from the setup / onboarding screen. That way, power users who know they'll want to sideload could still sideload. The rest could enjoy the benefits of an ecosystem where somebody more competent than their 80-year-old nontechnical self can worry about cybersecurity.
Another way to do this would be to enforce a 48-hour cooldown on enabling sideloading, perhaps waived if enabled within 48 hrs of device setup. This would be enough time for most people to literally "cool off" and realize they're being scammed, while not much of an obstacle for power users.
You can sideload, I mean INSTALL, software on any linux desktop. Yet there are still tons of people saying that desktop linux has gotten good enough for most of everyone's grandma to daily-drive.
When everyone's Grandma is running Linux then the Indian scammers will know how to trick Grandma into thinking dmesg spam is "a virus" and just install this totally-not-malware, just like they do with the windows event viewer.
In other words, it's not any quality of Linux other than how niche it is.
It's an excellent example of the fruitlessness of technical solutions to people problems. Some people are just destined to get scammed, and it isn't worth throwing away General Purpose Computing to try to help them. Be present in Grandma's life and she won't be desperate to trust the nice man on the phone just to have someone to talk to. If it weren't this it would be iTunes gift cards, or Your Vehicle's Extended Warranty, or any number of other avenues.
The actual stopping power here is that any grandma who uses a Linux desktop has a family member (or other contact) who helps with technical matters. They've been educated about internet & phone scams, and will immediately call their technical contact when anything is suspicious.
This becomes a problem when someone asks me for help with their phone and I want to point them to some apps from F-Droid to reduce their exposure to surveillance marketing.
Of course that's a side effect Google probably wouldn't be sad about.
These two solutions wouldn't work for me. My phone is covered, I use a custom ROM, but I like being able to help people install cool stuff that's not necessarily on the Play store, organically, without planning.
I'm not sure I like the idea of "you have to wait 48 hours now for sideloading in case you are an idiot". Most idiots will then have sideloading on after 48 hours and still get hit with the next scam anyway.
> more competent than their 80-year-old nontechnical self can worry about cybersecurity
80-year-old nontechnical self can easily operate machines and devices that are much more complex and easily more dangerous than a smartphone.
And yet we're here pretending that those same people will install apps without even thinking about it.
Careless people are careless, we know that, we don't make them safer by treating everyone else like toddlers with a gun in their hands.
> which could only be activated from the setup / onboarding screen
Yea no. Now companies have to supply two phones, one for dev and one for calling. It is hard enough to get one...
You’re still proving the point above, which is ignoring the fact that the restriction is specifically targeted at a small number of countries. Google is also rolling out processes for advanced users to install apps. It’s all in the linked post (which apparently isn’t being read by the people injecting their own assumptions)
Google is not rolling this out to protect against YouTube ReVanced but only in a small number of countries. That’s an illogical conclusion to draw from the facts.
Its my device. Not google's. Imagine telling you which NPM/PIP packages you can install from your terminal.
Also, its not SIDE loading. Its installing an app.
Well... it would be good if this was true, but read the ToS and it looks more like a licence to use than "ownership" sadly :(
"Android" is really a lot of different code but most of it is the Apache license or the GPL. Google Play has its own ToS, but why should that have to do with anything when you're not using it?
Google doesn't own AOSP. We don't need any google apps on an andoid phone for it to function.
I agree, but I don't see why Google gets more critical attention than the iPhone or Xbox.
iPhone has always been that way (try installing an .ipa file that's not signed with a valid apple developer certificate). For Google forced app verification is a major change. Xbox I don't know..
Yeah, let's ask the Debian team about installing packages from third party repos.
I'm not on the side of locking people out, but this is a poor argument.
> Yeah, let's ask the Debian team about installing packages from third party repos.
Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows.
Hence you don't realize how good of an argument it is, because you even bamboozled yourself without realizing it.
It gets a worse argument if we want to discuss Qubes and other distributions that are actually focused on security, e.g. via firejail, hardened kernels or user namespaces to sandbox apps.
"Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows."
This is only true if you use Secure boot. It is already not needed and insecure so should be turned off. Then any OS can be installed.
> This is only true if you use Secure boot. [...] so should be turned off. Then any OS can be installed.
You can only turn off Secure Boot because Microsoft allows it. In the same way Android has its CDD with rules all OEMs must follow (otherwise they won't get Google's apps), Windows has a set of hardware certification requirements (otherwise the OEM won't be able to get Windows pre-installed), and it's these certification requirements that say "it must be possible to disable Secure Boot". A future version of Windows could easily have in its hardware certification requirements "it must not be possible to disable Secure Boot", and all OEMs would be forced to follow it if they wanted Windows.
And that already happened. Some time ago, Microsoft mandated that it must not be possible to disable Secure Boot on ARM-based devices (while keeping the rule that it must be possible to disable it on x86-based devices). I think this rule was changed later, but for ARM-based Windows laptops of that era, it's AFAIK not possible to disable Secure Boot to install an alternate OS.
I agree with you and run with it disabled myself, but some anti-cheat software will block you if you do this. Battlefield 6 and Valorant both require it.
This is the real malware that people should be protected from.
Now tell me how
Turning off UEFI secure boot on a PC to install another "unsecure distribution"
vs.
Unlocking fastboot bootloader on Android to install another "unsecure ROM"
... is not the exact same language, which isn"t really about security but about absolute control of the device.
The parallels are astounding, given that Microsoft's signing process of binaries also meanwhile depends on WHQL and the Microsoft Store. Unsigned binaries can't be installed unless you "disable security features".
My point is that it has absolutely nothing to do with actual security improvements.
Google could've invested that money instead into building an EDR and called it Android Defender or something. Everyone worried about security would've installed that Antivirus. And on top of it, all the fake Anti Viruses in the Google Play Store (that haven't been removed by Google btw) would have no scamming business model anymore either.
"... is not the exact same language, which isn"t really about security but about absolute control of the device.
The parallels are astounding, given that Microsoft's signing process of binaries also meanwhile depends on WHQL and the Microsoft Store. Unsigned binaries can't be installed unless you "disable security features".
My point is that it has absolutely nothing to do with actual security improvements."
I agree. It is the same type of language.
While it's possible to install and use Windows 11 without Secure Boot enabled, it is not a supported configuration by Microsoft and doesn't meet the minimum system requirements. Thus it could negatively affect the ability to get updates and support.
> It is already not needed and insecure so should be turned off.
You know what's even less secure? Having it off.
The name “Secure Boot” is such an effective way for them to guide well-meaning but naïve people's thought process to their desired outcome. Microsoft's idea of Security is security from me, not security for me. They use this overloaded language because it's so hard to argue against. It's a thought-terminating cliché.
Oh, you don't use <thing literally named ‘Secure [Verb]’>?? You must not care about being secure, huh???
Dear Microsoft: fuck off; I refuse to seek your permission-via-signing-key to run my own software on my own computer.
Agreed.
Also Secure boot is vulnerable to many types of exploits. Having it enabled can be a danger in its self as it can be used to infect the OS that relies on it.
Could you elaborate? This is news to me?
> Dear Microsoft: fuck off; I refuse to seek your permission-via-signing-key to run my own software on my own computer.
No one is stopping you from installing your own keys, though?
I do not want to be in the business of key management. This is not something that needed encryption. More encryption ≠ better than.
I also dual-boot Windows and that's a whole additional can of worms; not sure it would even be possible to self-key that. Microsoft's documentation explicitly mentions OEMs and ODMs and not individual end users: https://learn.microsoft.com/en-us/windows-hardware/manufactu...
> This is not something that needed encryption. More encryption ≠ better than.
Securing the boot chain protects against a whole range of attacks, so yes, it is objectively better from a security POV.
Name a single prevented bootkit that wasn't able to avoid the encryption and signature verification toolchain altogether.
Malware developers know how to avoid this facade of an unlocked door.
Users do not.
That's the problem. It's not about development, it's about user experience. Most users are afraid to open any Terminal window, let alone aren't even capable of typing a command in there.
If you argue about good intent from Microsoft here, think again. It's been 12 years since Stuxnet, and the malware samples still work today. Ask yourself why, if the reason isn't utter incompetence on Microsoft's part. It was never about securing the boot process, otherwise this would've been fixed within a day back in 2013.
Pretty much all other bootkits also still work btw, it's not a singled out example. It's the norm of MS not giving a damn about it.
The countries that go after Google are the first wave, they're applying these restrictions globally not much later.
The linked post is full of fluff and low on detail. Google doesn't seem to have the details themselves; they're continuing with the rollout while still designing the flow that will let experienced users install apps like normal.
A small number of countries now. The rest of the world in 2027 and beyond.
yt-dlp's days are fairly numbered as Google has a trump card they can eventually deploy: all content is gated behind DRM. IIRC the only reason YouTube content is not yet served exclusively through DRM is to maintain compatibility with older hardware like smart TVs.
Youtube already employs DRM on some of their videos (notably their free* commercial movies). if you try to take a screenshot, the frame is blacked out. this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction; detection of DRM protection and applying the bypass is likely trivial for the kinds of people already writing scripts and programs utilizing yt-dlp. the css method of bypass has been widely disseminated for years (over a decade?), but programmers love puzzles, so a sequel to current DRM implementation seems justified. YT could also substantially annoy me by expiring their login cookies more frequently; I think I have to pull them from my workstation every month or two as-is? at some point, they could introduce enough fragility to my scripts where it's such a bother to maintain that I won't bother downloading/watching the 1-3 videos per day I am today -- but otoh, I've been working on a wasm/Rust mp4 demuxer and from-scratch WebGL2 renderer for video and I'm kind of attached to seeing it through (I've had project shelved for ~3 weeks after getting stuck on a video seek issue), so I might be willing to put a lot of effort into getting the videos as a point of personal pride.
the real pain in the butt in my present is Patreon because I can't be arsed to write something separate for it. as-is, I subscribe to people on Patreon and then never bother watching any of the exclusive content because it's too much work. some solutions like Ghost (providing an API for donor content access) get part of the way to a solution, but they are not themselves a video host, and I've never seen anyone use it.
> this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction
That's not real DRM then. The real DRM is sending the content such that it flows down the protected media path (https://en.wikipedia.org/wiki/Protected_Media_Path) or equivalent. Userspace never sees decrypted plaintext content. The programmable part of the GPU never seen plaintext decrypted content. Applying some no-op blur filter would be pointless since anything doing the blur couldn't see the pixels. It's not something you can work around with clever CSS. To compromise it, you need to do an EoP into ordinarily non-programmable scanout of the GPU or find bad cryptography or a side channel that lets you get the private key that can decode the frames. Very hard.
Is this how YT works today? Not on every platform. Could it work this way? Definitely. The only thing stopping them is fear of breaking compatibility with a long tail of legacy devices.
Something I've never understood about DRM is, if the content is ultimately played on my device, what stops me from reverse engineering their code to make an alternative client or downloader? Is it just making it harder to do so? Or is there a theoretical limit to reverse engineering that I'm not getting? Do they have hardware decryption keys in every monitor, inside the LCD controller chip?
in short and simple terms, those parasites colluded with hardware manufacturers and put a special chip in your computer and monitor that runs enslavement software
without opening it up physically there is no way to make it stop or get the raw stream before it's displayed
This. Some ways back I actually purchased bluray recording device only to learn that its firmware is deliberately crippled to accommodate someone's business model. There are people who do the unsung hero work, but those types of skills are not exactly common and a business asshole is a dime a dozen any century you want to pick.
Yes, the decryption happens in hardware. For your OS (and potential capturing software running on it) the place where you see the video is just an empty canvas on which the hardware renders the decrypted image.
All levels of Widevine are cracked, but only the software-exclusive vulnerabilities are publicly available. It's only used for valuable content though (netflix/disney+/primevideo), so it might still work out for YouTube as no one will want to waste a vulnerability on a Mr. Beast slop video.
The reason they have different levels is that the DRM pitchmen got tired of everyone making fun of their ineffective snake oil, so they tried to make a version that was harder to break at the cost of not supporting most devices.
Naturally that got broken too, and even worse, broken when it's only supported by a minority of devices and content, because the more devices and content it's used for the easier it is to break and the larger the incentive to do it.
If you tried to require that for all content then it would have to be supported by all devices, including the bargain bin e-waste with derelict security, and what do you expect to happen then?
Do you have any link? All the things I can find are about the 2019 L3 crack
I don’t have any personal links but know that there is a constant cat-and-mouse game of cracking Widevine devices for their L1 keyboxes and using them on high-value content (as mentioned).
That’s why a lot of low end Android devices often have problems playing DRMed content on the Web: their keyboxes got cracked open and leaked wide enough for piracy that they got revoked and downgraded down to L3.
Too bad that I'm going iPhone if Google removes sideloading and now I know about revanced so they aren't getting any more than the zero dollars that youtube and youtube music are worth from me
If I'm going to live in a walled garden it's going to the fanciest
I still don't get this mindset - all is lost, I am not going to do anything aboit that AND I will punish them by going with the even worse option!
If neither does what you want, you'll use other metrics, which often make ios a better choice. Simple as that
If they're going to reduce me to a user, iOS is the better choice. I had an iPhone before and it's a picture taking, instagram, social media machine with iMessage—bringing the console wars to normies since inception.
Because the hardware is so constrained an iphone lasts forever compared to a similar android. My two year old pixel is slow now, but I know people completely happy with a five year old iphone. Pause, I checked and the oldest iphone that receives updates is an iphone 11, which is the exact model I had before going back to android.
I have multiple generations of pixel phones and could not tell the difference in performance between them in basic tasks. Maybe because i installed GrapheneOS which makes both stock android and ios feel like a bloat and spyware riddled toy.
I have a Pixel 7 and it's ridiculously slow so I've been thinking about GrapheneOS.
The only reason for me to get a pixel is GOS. I never want to get back, it makes other mobile os feel icky.
You would still be able to adb installs them. They wouldn't die.
Developers of these apps would have little motivation if the maximum audience size was cut down to the very few who would use adb. The ecosystem would die.
Or someone comes up with an easy adb wrapper and now it becomes the go-to way to install apps.
Shizuku[0][1] already exists, it would certainly suck but it wouldn't be the end of the world.
Of course I would be much happier if I didn't need to use Shizuku in the first place.
[0]: https://play.google.com/store/apps/details?id=moe.shizuku.pr...
[1]: https://shizuku.rikka.app/
That uses a workaround based on WiFi debugging even though it's all local. It doesn't run if you're not connected to a trusted WiFi network, you have to set it all up when connecting to a new network, etc.
Not only users are not connected to WiFi all the time, but in many developing countries people often have no WiFi at home and rely on mobile data instead. It's a solution, but not a solution for everyone or a solution that works all the time.
And how do you estimate the audience that even cares about those issues?
I think number of people caring about alternative app stores, F-droid or whatever is very similar to the number of people willing to use adb if necessary, so rather small.
But the ecosystem exists, regardless of what the absolute number is, and it would be bad to lose it. If the platform was more open like Windows the ecosystem would grow, if it was less open like iOS it would die.
Somehow I think having to use ADB instead of something like F-Droid with automatic updates would put a damper on things.
how many people ll do this though? i would expect sub 1% conversion from existing users if they had to do that
> Google has hinted
I beg to differ:
> In early discussions about this initiative, we've been encouraged by the supportive initial feedback we've received.
> the Brazilian Federation of Banks (FEBRABAN) sees it as a “significant advancement in protecting users and encouraging accountability.” This support extends to governments as well
> We believe this is how an open system should work
Google isn't "hinting" that they're doing this under pressure, that announcement makes it quite clear that this is Google's initiative which the governments are supportive of because it's another step on a ratcheting mechanism that centralizes power.
> because the governments of countries where such scams are widespread will hold Google responsible
Your comment is normalizing highly problematic behavior. Can we agree that vague "pressure from the government" shouldn't be how policies and laws are enacted? They should make and enforce laws in a constitutional manner.
If you believe that it's normal for these companies and government officials to make shadow deals that bypass the rule of law, legal procedures, separation of powers and the entire constitutional system of governance that our countries have, then please drop the pretense that you stand for democracy and the rule of law (assuming that you haven't already).
Otherwise we need to be treating it for what it is - a dangerous, corrupt, undemocratic shift in our system of governance.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
What, the same way they hold Microsoft responsible for the fact that you can install whatever you want in Windows?
Obviously, there can exist an easy way for a non-technical user to install unverified apps, because there has always been one.
This is actually a good point, and something I've been wondering about too. What changed between the 90s and now, that Microsoft didn't get blamed for malware on Windows, but Google/Apple would be blamed now for malware on their devices? It seems that the environment today is different, in the sense that if (widespread) PCs only came into existence now, the PC makers would be considered responsible for harms therefrom (this is a subjective opinion of course).
Assuming this is true (ignore if you disagree), why is that? Is it that PCs never became as widespread as phones (used by lots of people who are likely targets for scammers and losing their life savings etc), or technology was still new and lawmakers didn't concern themselves with it, or PCs (despite the name) were still to a large extent "office" devices, or the sophistication of scammers was lower then, or…? Even today PCs are being affected by ransomware (for example) but Microsoft doesn't get held responsible, so why are phones different?
What changed is that Apple made the masses familiar with the concept of installing software only from a store with a vetting process. For short, the walled garden. That was mostly an alien thing in the world of software. All of us grew with the possibility of getting an installer and install it whenever we wanted. There were some form of protections against piracy but nothing else.
Once Apple created the walled garden every other company realized how good it could be for their bottom lines and attempted to do the same thing.
So, to answer your question, Microsoft got blamed for viruses and made fun of but there wasn't a better way in the mainstream. There is one now.
PCs will resist this trend for a while because it's also mainstream that they are used to do work. Many people use a PC every day with some native application from a company they have a direct contract with. For example: accounting software. Everybody can add another example from their own experience. Those programs don't come from the Windows store and it will be a long term effort to gatekeep everything into the store or move them into a web browser.
The .NET MAUI technology we had a post about yesterday is one of the bricks that can build the transition.
> So, to answer your question, Microsoft got blamed for viruses and made fun of but there wasn't a better way in the mainstream. There is one now.
I don't think App Store is a better way.
From my point of view, people keep mistaking the actual progress - generalised sandboxing and reduced API surface - with the major regression - controlled distribution. At the beginning of the App Store, when the sandboxing and APIs were poor, they were frequent security issues.
Apple marketing magic is somehow convincing people that it's their questionable veting which made things secure and not the very real security innovations.
I'm with you and personally I boycott Apple because of the walled garden, for what it's worth. However it is a better way (a more convenient way?) for companies to make money and it gave an idea to legislators and regulators. Now they expect that the owner of the OS can decide what runs and what does not run on their OS and be made accountable for it.
Windows 95 (and patronage) had become a shitshow. It’s easy to forget how much time us tech types were spending “fixing” uncle’s PC that somehow got malware on it. How we touted Linux as an escape from the hellscape of crapware.
It was into this void that the “everything seems new” iPhone stepped and ventured out in a different course. I’m neither speaking for or against apples normalization of an App Store as a primary source of updates, just recalling the way things were, and positing that Apple was trying a different approach that initially offered a computing platform that wasn’t the hellscape that MS platform was quickly becoming.
Windows 95 was fundamentally broken as if I recall correctly there was much less security features (accounts, file permissions, etc.). Nowadays there are less problems with it.
Its not that it was broken, its that security was not really a thing. You had your antivirus to protect you from people adding stuff to discs, but thats it. Windows 95 was just an exe file in the windows folder that you could run from DOS.
Windows NT / OS2 did have more security as it was meant for shared environments, but even there, corporations ended up using stuff like Novell NetWare to get the actual networking services.
Windows 2000 was the first version of consumer windows based on the NT kernel instead of the DOS / Windows 95/98/ME based systems. I still remember running around the office updating windows 2000 machines to service pack 4 to protect us against the first real massive virus "ILOVEYOU".
Edit: Still on first coffee, sorry about the ramblings
Sure, my point was that even if iPhone ecosystem is more secure than Windows 95, I do not think this is due mostly to the "walled garden", but because (as you mention) Windows 95 just did not care about security at all. By the time iPhone appeared the security of Windows systems (2000 and later) had already improved (even if not perfect) and there was a possibility to configure it more "locked down", if you wanted.
I always blamed Microsoft for Windows insecurity. But seriously, Windows did not have any vetting process for apps and apps didn't really have access to money. Google's problem is that they claim Android is a secure way to do banking but it isn't.
I bought the hardware, therefore I have the right to modify and repair. Natural right, full stop. That right ends are your nose, as the saying goes.
Consider whether your natural right argument might not stand in several other countries’ legal systems.
The era of United States companies using common sense United States principles for the whole world is coming to an end.
Okay, but currently it's the opposite: an US company is forcing the principles of these few legal systems for the whole world.
Nah, that's the beauty of it. Liberal principles make a much more robust political foundation that post-liberal principles. The US is known for the former despite current flirtations with the latter. However, liberal principles aren't tied to any one country. Fortunately for us!
The era of common sense in the United States came to an end.
Yeah then you have the choice to not buy the locked down hardware, you don't have a right to get open hardware FROM Google.
Of course there are no good options for open hardware, but that is a related but separate problem.
It's not a separate problem, Google are actively suppressing any possibility of open mobile hardware. They force HW manufacturers to keep their specs secret and make them choose between their ecosystem and any other, not both. There's a humongous conflict of interests and they're abusing their dominating position.
> They force HW manufacturers to keep their specs secret
Spoken like someone who has never ever worked with any hardware manufacturers. They do not need reasons for that. They all believe their mundane shit is the most secret-worthy shit ever. They have always done this. This predates google, and will outlive it.
Often it is because they don't know their own devices. We got a dev board from Qualcomm once and the documentation was totally bogus.
Regulating this is the way to not let general computing die to fuel google and apple profits.
People should have the right to run whatever software they like on the computing hardware they own. They should have the right to repair it.
The alternative is that everything ends up like smart-tvs where the options are "buy spyware ridden crap" or "don't have a tv"
Given how antitrust is not really working right now I would say this is debatable. Also monopolies in the past were forced to do various things to keep their status for longer.
> I bought the hardware, therefore I have the right to modify and repair. Natural right, full stop.
There is absolutely nothing "natural" about trading your pile of government promises for the right to call government men with guns and sticks if you are alienated from the option to physically control an object. Your natural right is to control what you can defend.
Rights are what we decide them to be. Or rather, what people in power decide them to be, i.e. people who hold and issue large amounts of government promises, and recruit and direct the most men with guns and sticks.
This is correct. Our natural rights go much further than unnatural prohibitions from the government.
Do what you please and get enough people to do it with you, and no one can stop you.
Oh, so you're good with everyone having the "natural right" to turn handguns into automatic weapons simply because they find themselves in possession of the correct atoms? How about adding a 3rd story on the top of your house without needing a permit or structural evaluation?
Note that adding "full stop" pointlessly to the end of sentences does not strengthen your argument.
The difference is that you can’t kill other people by installing an app.
sorry i thought we were talking about "natural rights" here, not rights conditional on whether the hardware does something you like or not
Guns aren't a natural right by any stretch. Defense is, but you're confusing the US bill of rights with natural rights of all humans.
Now that's just some stupid hyperbole.
I don't think it's illegal to do whatever you want with your phone. That doesn't mean google legally is required to make it easy or even possible. That being said I ethically they should allow it, and considering their near monopoly status they should be forced to keep things open. In fact there should be right to repair laws too.
The way to go from fervently hoping they make the ethical choice to actually protecting the users is to regulate it
I suppose you have the right to do whatever you want with it, including zapping it in the microwave or using it as a rectal probe. I am not sure that right extends are far as forcing companies to deliver a product to your specifications (open software, hardware, or otherwise)
You won't believe it, but many years ago the TVs for sale where required to come with their full schematics and they really did.
Right to repair requires it, thank goodness.
> Natural right, full stop.
You’re still missing the point the comment is making: In countries where governments are dead set on holding Google accountable for what users do on their phones, it doesn’t matter what you believe to be your natural right. The governments of these countries have made declarations about who is accountable and Google has no intention of leaving the door open for that accountability.
You can do whatever you want with the hardware you buy, but don’t confuse that with forcing another company to give you all of the tools to do anything you want easily.
That's deflection, there's Google blocking users from installing apps and there's OP insinuating that it might be because of governments coercion but there's no evidence to support this. Scammers pay Google to show ads to install apps, that's what the governments are holding Google responsible and it won't change with blocking installing apps.
Malicious app delivery goes beyond Google ads. In Singapore, most scam app installs are from social engineering, e.g. install new app to receive payment, install new app to buy something for cheap.
I’m amazed at how gullible some people are but that’s how it is.
That's not how it is, Google helps scammers and make a lot of money from it so they are responsible and should pay for it
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
You can also view this as a "tragedy of the commons" situation. Unverified apps and sideloading is actively abused by scammers right now.
> Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I get that viewpoint and I'm also very glad an opt-out now exists (and the risk that the verification would be abused is also very real), but yeah, more information what to do against scammers then would also be needed.
It's not possible to provide a path for advanced users that a stupid person can't be coerced to use.
Moreover, it's not possible to provide a path for advanced users that a stupid person won't use by accident, either.
These are what drive many instances of completely missing paths for advanced users. It's not possible to stop coercion or accidents. It is literally impossible. Any company that doesn't want to take the risk can only leave advanced users completely out of the picture. There's nothing else they can do.
Google will fail to prevent misuse of this feature, and advanced users will eventually be left in the dust completely as Google learns there's no way to safely provide for them. This is inevitable.
Android could have, for example, a 24 hour "cooling off" period for sideloading approval. Much like some bootloader unlocking - make it subject to a delay.
That immediately takes the pressure off people who are being told that their bank details are at immediate risk.
> Android could have, for example, a 24 hour "cooling off" period for sideloading approval.
And, to prevent the scammer from simply calling back once the 24 hours are gone, make it show a couple of warnings (at random times so they can't be predicted by the scammer) explaining the issue, with rejecting these warnings making the cooling off timer reset (so a new attempt to enable would need another full 24 hours).
The people gullible enough to fall for a scam like that are also gullible enough to follow more instructions 24 hours later. I think if you could force a call to the phone and have an agent or even AI that talks to user and makes sure no scam is involved then gives an unlock code based on deviceID or something. But that would cost money and scammers would work around it anyway.
>It's not possible to provide a path for advanced users that a stupid person can't be coerced to use.
I actually think you might be wrong about this? Imagine if Google forced you to solve a logic puzzle before sideloading. The puzzle could be very visual in nature, so even if a scammer asked the victim to describe the puzzle over the phone, this usually wouldn't allow the scammer to solve it on the victim's behalf. The puzzle could be presented in a special OS mode to prevent screenshots, with phone camera disabled so the puzzle can't be photographed in a mirror, and phone call functionality disabled so a scammer can't talk you through it as easily. Scammers would tell the victim to go find a friend, have the friend photograph the puzzle, and send the photo to the scammer. At which point the friend hopefully says "wait, wtf is going on here?" (Especially if the puzzle has big text at the top like "IF SOMEONE ASKS YOU TO PHOTOGRAPH THIS, THEY ARE LIKELY VICTIM OF AN ONGOING SCAM, YOU SHOULD REFUSE", and consists of multiple stages which need to be solved sequentially.)
In addition to logic puzzles, Google could also make you pass a scam awareness quiz =) You could interleave the quiz questions with logic puzzle stages, to help the friend who's photographing the puzzle figure out what's going on.
I guess this could fail for users who have two devices, e.g. a laptop plus a phone, but presumably those users tend to have a little more technical sophistication. Maybe display a QR code in the middle of the puzzle which opens up scam awareness materials if photographed?
Or, instead of a "scam awareness quiz" you could could give the user an "ongoing scam check", e.g.: "Did a stranger recently call you on the phone and tell you to navigate to this functionality?" If the user answers yes, disable sideloading for the next 48 hours and show them scam education materials.
It would also fail for users who are differently abled. That sounds like an absolute nightmare for accessibility. Good news for preventing scams, but bad news for anyone without full mental and physical faculties.
I'm not sure why you couldn't make the flow I describe just as accessible as anything else in Android? But I'll grant your premise and respond anyways.
If the user lacks full mental faculties, they are part of the userbase we need to protect from scams. Most likely, a user without full mental faculties who is trying to sideload will be a scam victim.
If the user lacks the necessary physical faculties to "solve a puzzle on their phone", they probably get help from friends regularly; a friend should be able to help with sideloading. Enabling sideloading should be a one-time operation right?
Considering phone scammers often convince their victims to:
- install remote desktop software
- run commands in the windows terminal
- withdraw cash from the bank
- lie to the bank teller about their purpose
- insert their cash into a bitcoin ATM at a gas station
- ignore warnings about scams which appear on the screen of the ATM
- insert the scammers bitcoin address into the machine
It isn't a stretch to imagine they could convince the victim to install adb and sideload an app.
A change google made to android earlier this year prevents you from allowing unknown sources and installing apks while you are on a phone call.
I'm surprised they didn't think of doing that sooner.
Notice though that we don't forbid people from withdrawing cash from the bank in order to prevent this.
Warning about scams is fine, as is taking steps to make it harder, but once you start trying to completely remove the agency of mentally sound adults "for their own good" then we have a problem.
It seems to me if you raise the difficulty enough, and lower the success rate enough, at some point a given scam stops being economical. https://news.ycombinator.com/item?id=45913529
It's waaaay more complicated to download ADB and side load a random APK.
This is either a move towards tighter control of the platform or a government request. And somewhat ironic, given that iOS is being pressured to be a bit more open.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
But it is perfectly fine to sell crypto and other complex financial assets to kids and other people that do not know they are from apps in the Play store.
If "safety" takes control from you then it is implemented. If real safety puts profits in danger then it is fight against. Quite a dystopia.
Then let them do that for those countries. Not for everyone. I'm not in any of those autocratic countries. Or offer an opt out in the countries where this isn't a thing. Using adb is not really great for doing updates.
And also, I'm the owner of my device. Not my country.
Once they do it in one country, there will be much more pressure and incentives to do it everywhere.
> I'm not in any of those autocratic countries
Autocratic Albania banned by law ads on YouTube so if you are in Albania (or your VPN is - wink! wink!) you get to watch YouTube without ads legally
I, too, hate those autocratic countries were government act for the good of the people, instead of ruling in favour of greedy billionaires
I'm pretty sure Brazil doesn't have a law saying that Google must forbid sideload. I'm sure that government (be it President, Central Bank etc) doesn't pressure Google about it.
I'm sure some private actors (for example, banks) would love that smartphones are as tight as possible (reason: [0]). Perhaps the same reason applies to Google [1]. But no, "Brazil" isn't demanding that from Google.
[0]: consider that some virus (insecure apps, for example) could somehow steal information from bank apps (even as simple as capture login information). The client might sue the bank and the bank might have to prove that their app is secure and the problem was in the client's smartphone.
[1]: the client, the bank etc might complain to Google that their Android is insecure
Aha - that is a much better explanation than I assumed, aka "the people forced Google to behave". So Google is scared of having to pay fines or having their CEOs end up in jail. I actually think there should be a new rule - easy-jail mode for CEOs globally. Does not have to be long but say, a few days in jail for ignoring the law, and right hold the CEOs responsible for that. You earn a lot of money, so you also gotta take the risk.
> From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.)
In ye goode olde times, the US would have threatened invasion and that would have been the end of it.
Half /s, because it actually used to be the case that the US government exercised its massive influence (and not just militarily) onto other countries for the benefit of its corporations and/or its citizens... these days, the geopolitical influence of the US has been reduced to shreds and the executive's priorities aren't set by doing what's (being perceived as being) right but by whomever pays the biggest bribes.
The tension here is classic: governments want accountability, Google wants plausible deniability, and users want control
...and users want ̶c̶o̶n̶t̶r̶o̶l̶ convenience.
Seems more appropriate.
Why can't they just put up a big, red warning: "Never enable software installation if someone asks you to (over the phone or via message). If you're unsure, check out this article on scams."?
> "Never enable software installation if someone asks you..."
Imagine a situation in which a frightened, stressed user sees such a message on their screen. Meanwhile, a very convincing fake police officer or bank representative is telling them over the phone that they must ignore this message due to specific dangerous emergency situation to save the money in their bank account. Would the user realize at that moment that the message is right and the person on the phone is a thief? I'm not so sure.
What if there is a 12-hour delay to unlock "power user mode", and during that entire 12-hour unlock period, the phone keeps displaying various scam education information to help even an unsophisticated user figure out what's going on? Surely Google can devote a few full-time employees to keeping such educational materials up to date, so they ideally contain detailed descriptions of the most common scams a user is going to be subject to at any given time.
This would help for sure. Ideally, the phone should stay in "expert mode" for a limited time only, like 1 hour.
However, there is still a danger that scammers will call after 12 hours, and they will be more convincing than educational material (or the user may not have read it).
> However, there is still a danger that scammers will call after 12 hours
It is unlikely it will work. Scammers are talking all the time and creating a sense of urgency, people have issues to think and listen at the same time, and they tend to drop thinking completely when in a haste. 12 hours of a break will give the victim time to think at least. Probably it will give time to talk about it with someone, or to google things.
> because the governments of countries where such scams are widespread will hold Google responsible.
How many virus infections and scams was Microsoft held responsible for? What about Red Hat, or Debian?
And at least let Google plainly state this, instead of inventing legal theories based on vague hints from their press releases, to explain why their self-serving user-hostile actions are actually legally mandatory.
> the governments of countries where such scams are widespread will hold Google responsible.
This argument is FUD at this point.
Sovereign governments have ways to make clear what they want: they pass laws, and there needs to be no back deal or veiled threats. If they intend to punish Google for the rampant scams, they'll need a legal framework for that. That's exactly how it went down with the DMA, and how other countries are dealing with Google/Apple.
Otherwise we're just fantasizing on vague rumors, exchanges that might have happened but represent nothing (some politicians telling bullshit isn't a law of the country that will lead to enforcement).
This would be another story if we're discussing exchanges with the mafia and/or private parties, but here you're explicitely mentionning governments.
> they'll need a legal framework for that
Not really. It should, but Google operate in a bunch of contries without proper rule of law.
That's a disingenuous argument though: they are in that position because they chose to make themselves the only way that a 'normal' user is able to install software on these devices. If not for that these governments wouldn't have a point to apply pressure on in the first place.
BTW, Stallman and FSF have been saying this the whole time - if you become the only gatekeeper, don't be surprised when government people show up and force you to ban apps or users from your platform.
This is just lies spread by the very own people that created this system in the first place, if PCs can have apps without "verification" then so can a phone.
Imagine if they tried to hold the entire world to the standards of Russia, China or North Korea. Yet they don't. This is just an excuse from them, or else they would only enable it in those countries. They don't hold the entire world to Chinese standards so why should they hold them to Brazilian standards? The only reasonable answer is: they also like those standards.
Or maybe Google just has empathy for people losing millions to scams?
No, then the results of many google web searches would not put scam sites at the top over the official sites. Google is fine with people being scammed. As long as they get their cut. Large corporations don't have empathy.
Meta ads too. It’s bonkers the type of ads they approve, straight up scams or obvious misinformation (some prominent figure is in jail! Click here to find out!)
From what I've seen, millions lost to scams are with social engineering; through cold calls masquerading as the authorities, phishing, pig butchering; plenty of scam apps on the Play store harvesting data as well, but not a single real life instance of malware installed outside the officially sanctioned platform.
The same scams Google's ad network facilitates and Google in turn profits from?
The Play Store is full of of scam apps so obviouly they don't.
Tell that to their advertising arm.
> because the governments of countries where such scams are widespread will hold Google responsible.
This is the unsurprising consequence of trying to hold big companies accountable for the things people do with their devices: The only reasonable response is to reduce freedoms with those devices, or pull out of those countries entirely.
This happened a lot in the early days of the GDPR regulations when the exact laws were unclear and many companies realized it was safer to block those countries entirely. Despite this playing out over and over again, there are still constant calls on HN to hold companies accountable for user-submitted content, require ID verification, and so on.
Yes. The same goes with payment processing. I hate visa/mastercard as much as the next person. But if the court says they're accountable for people who buy drug/firearm/child porn, then it seems to be a quite reasonable reaction for them to preemptively limit what the users can buy or sell.
The government(s) have to treat the middlemen as middlemen. Otherwise they are forced to act as gatekeepers.
These two things are not the same. The GDPR afforded rights to common people. Those companies that would pull out are the ones that were abusing data that was never theirs and could no longer do so.
Nah. I know of several startups that had nothing but anonymous telemetry and they blocked all Europe because there was no capacity for compliance. I was at an incubator at the time and the decision was unanimous across a dozen or so companies. It’s not like anyone was going to lose out on VC money from that market
> anonymous telemetry
is not covered by GDPR.
And it's a bit hard to believe that these several startups functioned without ever collecting names, emails, IP, phone number, or address of any lead or customer ever.
Maybe they did? Who knows? Never gonna find out because no one had time to look into it. It certainly wasn’t done with malicious intent, perhaps by accident or oversight, which is likely the situation in most small companies.
this is an unresolvable issue
or in this case:Security isn't an absolute and this doesn't notably improve it
If nobody pushed back on anything we'd all be subjected to the laws of the worst country on earth, because big tech companies want to do business there, and putting an if/else around the user's country takes effort.
Excuse me, what exactly is "sideloading"? If I wanted to run third-party code on a system through the means that's supported by the system, then it should be called "running", it's a part of normal operation.
The word "sideload" made it sound like you're smuggle something you shouldn't onto the system. Subtle word tricks like this could sneak poisons into your mind, be watchful.
You can't make people just stop using a word. The best course of action is to reclaim it. Look at us, we're posting on Hacker News. With a sideloaded browser.
They already did! The word was install. Or as GP noted, run. They're actually even now much more conventional and widely understood uses, and if anything it's Google attempting to swim against the stream and normalize sideload as language for software installation. Theirs is an object lesson, I think, in appropriately registering the objection and pushing us back to normal language.
I keep hearing that here, and people have good reasons why they think of that but to me sideloading always meant having your phone physically next to the device you're pulling an apk from, in other words loading the app from the side.
I always thought of it as coming from side-channel. Which (until I searched just now and was only offered side channel attacks as a result) I generally construed it as a good thing because the system was assumed to be broken. Things like track 2 diplomacy or messaging the CEO/minister because customer service/bureaucracy was broken. You can go in the side door of a business if you own it or belong there, only dis-empowered customers are forced to go in the front.
Side loading was getting something to work because it should when the system hadn't caught up to the fact that it should work.
Yeah, that strikes me as a familiar use also. They seem to be using it to mean not only that but any software installation that doesn't happen via the Play Store, so it's rooted in real history but also conveniently re-appropriated to imply it's veering outside of typically intended use cases.
I am not sideloading anything, I am installing apps from f-droid on my device.
The old Indian word for setting up software was in-sta-lin-it. It was so common, anyone with basic tribal knowledge could gather next to their "Pee See" and execute the code.
I'm using sideloaded Firefox right now!
You're about two decades late to the complaint party in this context at least. I can find references on google books back in 2006 referencing sideloading.
https://www.google.com/books/edition/CNET_Do_It_Yourself_IPo...
I'm ready to grant that you found an occurrence in the wild but it takes more than that to demonstrate prevalence, conventional usage, or semantic fidelity to originally intended meanings. Also they are appealing to a usage that's practically as old as the paradigm of personal computing itself, so I don't think they're the one that's out of date.
I happen to remember "sideload" as a term of art for some online file locker sites to mean saving it to your cloud drive instead of downloading it to your computer. A cool usage, but it never caught on.
I think nomenclature as it exists in the PC software universe is closest in spirit on all fronts, in describing running software as, well, running software, and describing installing as installing. While a little conspiratorial in tone they're not wrong that "sideload" pushes the impression that controlling what software you run on your phone should be understood as non-default.
This is an instance of an on target usage though relating to the unofficial loading of software onto the device. And in my eyes finding it in a published work by a major publication means it was likely in wider usage in the same context, at the very least it can be an indicator of the start of that particular usage.
newspeak FTW!
Edit: be sure to read geoffschmidt's reply below /edit
The buried lede:
> a dedicated account type for students and hobbyists. This will allow you to distribute your creations to a limited number of devices without going through the full verification
So a natural limit on how big a hobby project can get. The example they give, where verification would require scammers to burn an identity to build another app instead of just being able to do a new build whenever an app gets detected as malware, shows that apps with few installs are where the danger is. This measure just doesn't add up
But see also the next section ("empowering experienced users"):
> We are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified
Oh! I thought I had found the crucial piece finally after ~500 words, but there's indeed better news in the section after that! Thanks, I can go sleep with a more optimistic feeling now :)
Also this will kill any impetus that was growing on the Linux phone development side, for better or worse. We get to live in this ecosystem a while longer, let's see if people keep damocles' sword in mind and we might see more efforts towards cross-platform builds for example
Let's take the "W". This is pretty good news!
That's like accepting vaders 'altered' deal, and being grateful it hasn't been altered further.
If google wants a walled garden, let it wall off it's own devices, but what right does it have to command other manufactures to bow down as well? At this stage we've got the choice of dictato-potato phone prime, or misc flavour of peasant.
If you want walled garden, go use apple. The option is there. We don't need to bring that here.
i mean, this program is specifically for google verifed devices...
Google Certified Devices is any device that has GMS (Google Mobile Services) installed - ergo almost all of them. It's worth noting that a _lot_ of apps stop functioning when GMS is missing because Google has been purposefully been putting as much functionality in them instead of putting them in AOSP. So you end up in a situation where, to make an Android phone compatible with most apps, you need GMS. Which in turn means you need your phone to be Google Certified, and hence must implement this specification.
I am not english native. Is "The W" a synonym for "A Win", described as a positive outcome after a contest? Is there more nuance or context than that?
The others answered the question, but I wanted to add that this is "new English" to me as well (also non native though). I first saw it in chats with mostly teenagers in ~2021, where I've also learned "let's go" isn't about going anywhere at all (it means the same as w)
This is the first sign we're getting old :) new language features feel new. The language features I picked up in school, that my parents remarked upon, were simply normal to me, not new at all. I notice it pretty strongly nowadays with my grandma, where I keep picking up new terms in Dutch (mainly loan words) but she isn't exposed to them and so I struggle to find what words she knows. Not just new/updated concepts like VR, gender-neutral pronouns, or a new word for messages that are specifically in an online chat, but also old concepts like bias. It's always been there but I'd have no idea what she'd use to describe that concept
Yes, but it's often just "a W" or simply "W" in response to something good or seen as a "win."
There is also the same thing with L for loss/loser. "that's an L take", "L [person]", "take the L here", etc.
They are pretty straightforward in their meaning, basically what you described. I believe it comes from sports but they are used for any good or bad outcome regardless of whether it was a contest.
I think it's from people reporting sports statistics for a player or team as "W:5 L:7" meaning "five wins and seven losses".
https://knowyourmeme.com/memes/l-and-w-slang
I've never seen it in English outside of the USA, but it's very common inside.
This isn't a "W", but I am finding my own "W" from this by seeing others distrust Google, and remembering to continue supporting and looking for open alternatives to Google.
This is not a win. This is having independent distribution shut down and controlled.
We no longer own our devices.
We're in a worse state than we were in before. Google is becoming a dictator like Apple.
It's not being shut down though. The article says that there will be a way to install unverified apps.
Ok, but sideloading is already a thing. What will this way to install unverified apps be? I doubt it will be an extra screen asking "Are you super-duper sure you want to enable sidloading???" after the one already asking the same question.
They talk about doing it under pressure, so my guess is there might be a waiting period before you're allowed free reign, or maybe per-app. Or some level of calling google, listening to 10 minutes of how poor billionaires are going to starve if you have control of your own device before being allowed to unlock it.
You'll have to sign if you wish to distribute. That's an easy way for them to control you.
> We are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified
Sure, they'll keep building it forever — this is just a delay tactic.
That doesn't say that you can just build an APK and distribute it. I suspect this path _still_ requires you to create a developer console account and distribute binaries signed by it... just that that developer account doesn't have to have completed identity verification.
So you will now need a useless and needless account to build and run your own apps? It's like Microsoft forcing online login on pcs.
useless, needless and terminateable at Google's pleasure!
it's probably just gonna be under the Developer Options "secret" menu
Which is totally fine IMO, it was weird to me that they weren't going with this approach when they first announced it.
Macs blocked launching apps from unverified devs, but you can override in settings. I thought they could just do something along those lines.
That's not fine at all. A developer who doesn't want to (or can't) distribute through the Play Store will now need to teach their users how to enable developer mode and toggle a hidden setting. This raises the barrier a bit more than the current method of installing outside the Play Store.
It's not fine. Some apps particularly banking apps have developer mode detection and refuse to work if developer mode is enabled.
I've switched banks for less.
Until there are no banks left to switch to
Maybe this sounds dark but see also how the net is tightening around phones that allow you to run open firmware after you've bought the hardware for the full and fair price. We're slowly being relegated to crappy hobbyist projects once the last major vendors decide on this as well, and I don't even understand what crime it is I'm being locked out for
We're too small a group for commercial vendors to care. Switching away isn't enough, especially when there's no solidarity, not even among hackers. Anyone who uses Apple phones votes with their wallet for locking down the ability to run software of your choice on hardware of your choice. It's as anti-hacker as you can get but it's fairly popular among the HN audience for some reason
If not even we can agree on this internally, what's a bank going to care about the fifty people in the country that can't use a banking app because they're obstinately using dev tools? What are they gonna do, try to live bankless?
Of course, so long as we can switch away: by all means. But it's not a long-term solution
I think pretty soon I'll carry a "normal" phone in my bag for things like communication and banking/ticketing, but I'll carry a device I actually like in my pocket. It'll be the best of both worlds - content I want to see often and easily in my pocket, and the stuff I don't want to be distracted by will be harder to reach on a whim.
Yes, I think I'll have to do the same. I've been in the market for a new phone but the one I had pretty much settled on removed the option to update the boot verification chain so I'm obviously not buying that. Might as well buy apple then
It seems like a finite solution though. Having a second phone is not something most people will do, so the apps that are relegated to run on such devices will become less popular, less maintained, less and less good
Currently, you can run open software alongside e.g. government verification software. I think it's important to keep that option if somehow possible
Let me guess, a warning box that requires me to give permission to the app to install from third-party sources? Is that not clear enough confirmation that I know what I'm doing? /s
So.. all this drama over an alert(yes/no) box?
Wow, this really pulls back the veil. This Vendor (google) is only looking out for numero uno.
> So.. all this drama over an alert(yes/no) box?
A simple yes/no alert box is not "[...] specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer". In fact, AFAIK we already have exactly that alert box.
No, what they want is something so complicated that no muggle could possibly enable it, either by accident or by being guided on the phone.
I imagine what they're going to do involves a time delay so a scammer cannot wait on the phone with a victim while they do it.
I agree. Waiting to see for how long. Has to be 24 hours at a minimum I'd guess.
They could make us fill capchas to pass the time...
> So.. all this drama over an alert(yes/no) box?
The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
It’s been fairly clear from the start that this wasn’t the end of sideloading, period. However that doesn’t get as many clicks and shares as writing a headline claiming that Google is taking away your rights.
> The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
No, until this post, Google had said that it wouldn't be possible to install an app from a developer who hadn't been blessed by Google completely on your device. That is unacceptable. This blog post contains a policy change from Google.
> The angry social media narratives have been running wild from people who insert their own assumptions
There may have been exaggerations in some cases but these hand wavy responses like "you can still do X but you just can't do Y and Z is now mandatory" or "you can always use Y" is how we got to this situation in the first place.
This is just the next evolution of SafetyNet & play integrity API. Remember how many said use alternatives. Not saying safetynet is bad but I don't believe their intentions were to stop at just that.
Sorry what? Their original plan absolutely was the end of sideloading on-device outside of Google's say so. That's what the angry social media narratives were that you seem upset about. Anyone being pedantic and pointing out that adb install is still an option therefore sideloading still exists can fuck off at this point.
I don't think this section is actually the same as the present state just with a new alert box.
I suspect they mean you have to create a android developer account and sign the binaries, this new policy just allows you to proceed without completing the identity verification on that account.
What are you talking about? This change for "experienced users" was only just announced and not part of any previous announcement. It has not been clear from the start at all.
Have you missed the plot entirely? This is absurd
And of course: you need an account, rather than simply allowing you to tell your OS that yes, you know what you're doing.
You're right: if the logic is that low-install apps are the most dangerous (because they can fly under the radar), then making it easier for unverified apps to reach a "small" audience doesn't really solve the problem
> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands.
As long as this is a one-time flow: Good, great, yes, I'll gladly scroll through as many prompts as you want to enable sideloading. I understand the risks!
But I fear this will be no better than Apple's flow for installing unsigned binaries in macOS.
Please do better.
I also think we should stop calling it "sideloading". We need a better word. Sideloading has a negative vibe, as if it's a dangerous thing to install apps from sources other than the Play Store.
Sideloading should be called installing, and installing from the play store should be called jailloading.
I call it installing. If it's from play store I'd say "Install from Play Store".
>Sideloading has a negative vibe
Maybe you've just been drinking the propaganda? "Sideloading" to me rolls off the tongue no worse than "hotswapping" or "overclocking".
We've always called it "install".
There is a distinction between installing something via the primary or a secondary mechanism. If someone said I just had to "install" a windows program and it turned out I had to compile it from scratch and set all the registry entries myself, I would be "astonished"(as in: The Principle Of Least Astonishment).
I fully understand that language matters and if this was an attempt by Google to de-legitimize this way of installing, that's no good. But for Christ's sake, having different names for different things is not inherently malicious.
I don't see why you'd be astonished here. The Play Store downloads the APK and installs the APK. If you've downloaded it already (eg with a browser), you just install the APK. How is that comparable to compiling from scratch and setting the registry entries yourself?
About five clicks more(than a single click) and a scary safety setting to turn off. But I didn't mean that installing an apk was as involved as my windows example. That was meant to illustrate that there are two completely different lines of action, two completely different levels of user competence at play.
Installing from the play store involves exactly zero knowledge of what an apk even is.
I want to flip the question around and ask you: How are you not seeing that there is a distinction?
Does this allow unsigned binaries like today? Or is this now requiring you have a binary signed by a android developer account but just one without full identity verification.
All Android devices require signed binaries and have done so since 1.0.
Red herring. Self-signed certificates have always been accepted, and generating a certificate is a one-liner:
The public testkey certificate is also accepted so you don’t even need to generate one.Yes, but then when you update the app, it has to be signed with the same certificate. Android effectively uses TOFU for apk signatures.
What if it imposed a longish (one time) cooldown period? A day?
Exactly, this would greatly reduce the ability for scammers in "urgent" situations, but for power users who flip the switch on day one it would rarely be a problem. What would be terrible though ... is if Google made it require a network connection or Google approval.
1 day is not longish. That would greatly harm apps like F-Droid. You'd have to go through it every time you want to update your apps.
He said one-time.
Yeah, just to turn on the mode.
Perhaps make you do it again after each major OS update, or once a year or something.
The key will be whether they treat experienced users like adults after the initial opt-in
> Keeping users safe on Android is our top priority.
I highly doubt this is your "top" priority. Or if it is then you're gotten there by completely ignoring Google account security.
> intercepts the victim's notifications
And who controls these notifications and forces application developers to use a specific service?
> bad actors can spin up new harmful apps instantly.
Like banking applications that use push or SMS for two factor authentication. You seem to approve those without hesitation. I guess their "top" priority is dependent on the situation.
> > intercepts the victim's notifications
> And who controls these notifications and forces application developers to use a specific service?
Am I alone in being alarmed by this? Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps? And they must instead rely on centralized control to disable those apps after the crime? So.. what’s the point of the sandboxing - if this is just desktop level lack of isolation?
Glossing over this ”detail” is not confidence inspiring. Either it’s a social engineering attack, in which case an app should have no meaningful advantage over traditional comms like web/email/social media impersonation. Or, it’s an issue of exploits not being patched properly, in which case it’s Google and/or vendor responsibility to push fixes quickly before mass malware distribution.
The only legit point for Google, to me, is apps that require very sensitive privileges, like packet inspection or OS control. You could make an argument that some special apps probably could benefit from verification or special approvals. But every random app?
> Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps?
An app can read the content of notifications if the appropriate permissions are granted, which includes 2FA codes sent by SMS or email. That those are bad ways to provide 2FA codes is its own issue.
I want that permission to exist. I use KDE Connect to display notifications on my laptop, for example. Despite the name, it's not just for KDE or Linux - there are Windows and Mac versions too.
> An app can read the content of notifications if the appropriate permissions are granted, which includes 2FA codes sent by SMS or email.
Do apps generally do this? I've never run into one that doesn't expect me to type in the number sent via SMS or email, rather than grabbing it themselves.
I don't use a lot of apps on my android phone, though, so maybe this is a dumb question to those who do.
Most apps don't read notifications for that purpose, and I'm not sure they'd be allowed in the Play Store if they wanted the permission just for that. It's mainly used for automation and sending notifications to other devices like PCs and maybe smartwatches.
Yes, but see my last paragraph. Reading notifications doesn’t apply to the majority of apps. It’s not a binary choice. On iOS, you need special entitlements for certain high level privileges. Isn’t it already the same on Android?
It's similar. I think there's a difference in that special entitlements have to be approved by Apple. Read/manage notifications is under "special app access", which has a different prompt where the user has to pick the app from a list and flip a toggle to grant the permission rather than just tapping OK.
yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.
powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.
(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)
You may be overthinking it. Verification of some sort isn’t the end of the world, it’s arguably an acceptable damage control stop-gap that has precedent on other platforms like special entitlements on iOS and kernel extensions on Windows.
Googles proposal was to require everyone to verify to publish any app through any channel. That would be the equivalent of a web browser enforcing a whitelist of websites, because one scam site asked for access to something bad.
If scam apps use an API designed by Google to steal user data, then they should fix that, without throwing the baby out with the bathwater.
might have meant to reply to someone else? I haven't said anything about verification here
I mean the solution really is a comprehensive permissions system, for an accessibility system that needs to read notifications you should be able to deny it network permissions and whitelist which app's notifications it's allowed to read
entirely agreed, but in the context of this thread that means you just have to convince someone to enable it for the one app, rather than the phone as a whole. which doesn't seem to help at all with the coercion scenario (if anything that might make it safer-sounding and therefore easier), just under normal use / to limit possibly-malicious apps.
> Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps?
It's not news, both iOS and Android sandboxing are Swiss cheese compared to a browser.
People should only install apps from trusted publishers (and not everything from the store is trusted as the store just gors very basic checks)
browsers are really not much better. on an absolute level, I definitely agree they're better (e.g. they have per-url and only-after-click permissions for some things), but they've all got huge gaps still once you start touching extensions. and beyond that it remains to be seen, since OS-level permissions are significantly broader-possibility than in-browser due to being able to touch far more sensitive data.
Only a few things in life are for sure. Death, taxes, and corpospeak.
Hey, sometimes the dumbest people it works on are also the ones with the decision making ability. What a world to live in.
Their top priority is making money.
Making money and complying with the law. They are obligated to do both. In many countries laws are still enforced.
Protecting their app store revenues from competition exposes them to scrutiny from competition regulators and might be counter productive.
Many governments are moving towards requiring tech companies to enforce verification of users and limit access to some types of software and services or impose conditions requiring software to limit certain features such as end to end encryption. Some prominent people in big tech believe very strongly in a surveillance state and we are seeing a lot of buy in across the political spectrum, possibly due to industry lobbying efforts. Allowing people to install unapproved software limits the effectiveness of surveillance technologies and the revenues of those selling them. If legal compliance risks are pushing this then it is a job for voters, not Google to fix.
Complying with the law is just another way of protecting your money. I have no doubt if they would break laws if they judged it better for the bottom line --- in fact I have little doubt they're already doing so. On the flip side, if there were ruinous penalties for their anticompetitive behaviors (i.e., in the tens or hundreds of billions of dollars) they might change course.
Certainly voters need to have their say, but often their message is muffled by the layers of political and administrative material it passes through.
BINGO! Google doesn't care at all about user security.
- Just yesterday there was a story on here about how Google found esoteric bugs in FFMPEG, and told volunteers to fix it.
- Another classic example, about how Google doesn't give a stuff about their user's security is the scam ads they allow on youtube. Google knows these are scams, but don't care because they there isn't regulation requiring oversight.
> Just yesterday there was a story on here about how Google found [a security vulnerability that anyone running `ffmpeg -i <untrusted file> ...` was vulnerable to] in FFMPEG, and told [the world about it so that everyone could take appropriate action before hackers found the same thing and exploited it, having first told the ffmpeg developers about it in case they wanted to fix it before it was announced publicly]
Fixed that for you. Google's public service was both entirely appropriate and highly appreciated.
> and highly appreciated.
Not by the maintainers it wasn't Mr. Google.
Yes, but it was a public service not a service for the maintainers, and as a member of the public who like anyone who had run `ffmpeg -i <thing I downloaded from the internet>` was previously exposed to the vulnerability I highly appreciate their service.
I'd highly appreciate even if the maintainers never did anything with the report, because in that case I would know to stop using ffmpeg on untrusted files.
So you were using untrusted video files that required the LucasArts Smush codec?
Again, if YOU highly appreciate their service, that's great, but FFMPEG isn't fixing a codec for a decades old game studio, so all Google has done is tell cyber criminals how to infect your Rebel Assault 2. I'm glad you find that useful.
No, I was running on normal untrusted video files. The standard ffmpeg command line would happily attempt to parse those with the LucasArts Smush codec even though I'd never heard of it before.
See the POC in the report by google, the command they run is just `./ffmpeg -i crash.anim -f null /dev/null -loglevel repeat+trace -threads 1` and the only relevant part of that for being vulnerable is that crash.anim is untrusted.
Edit: And to be clear, it doesn't care about the extension. You can name it kittens.mp4 instead of crash.anim and the vulnerability works the same way.
Their top priority is preventing people from using YouTube ReVanced or uBlock Origin on Firefox. That's their top priority.
this is an absurd rant. they invest, like, billions into security. It's not as perfect as you want it to be but "completely ignoring" is a joke. if you've got actual grievances you should say what they are so that we can actually get on your side instead of rolling our eyes
They absolutely eo completely ignore many security and privacy things because they're very selective in what they focus on, particularly around how those things might impact their ad revenue.
How much they spend is no indicator of how and where they spend it, so is hardly a compelling argument.
I'm not the OP but we know that SMS is not secure. Google should try banning that first.
Some security is better than no security. It already took years to even get some of these backwards-thinking companies and services to adopt SMS OTP and it's simple for non-technical users to intuit. Also, believe it or not, some people don't have smartphones, and they will riot if you try to make them switch to any other MFA method...
Of course, I'm not saying we shouldn't push to improve things, but I don't think this is the right reaction either.
This is the worst of both worlds, you can spread your malware as a sideloaded apk just fine, but when it's so big that you're probably burned anyways, then you need to verify your account.
I think a better compromise would have been for google to require developer verification, but also allow third party appstores like f-droid that don't require verification but still are required to "sign" the apks, instead of users enabling wide-open apk sideloading. that way, hobbyists can still publish apps in third party stores, and it is a couple of more steps harder for users to fall for social engineering,because they now have to install/enable f-droid, and then find the right malicious app and download it. The apk downloaded straight from the malicious site won't be loaded no matter what.
Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores, and maybe even require an inconsistent set of steps to search and find apps to make it harder to social engineer people (like names of buttons, ux arrangements, number of clicks,etc.. randomize it all).
What frustrated me on this topic from the beginning is that solutions like what I'm proposing (and better ones) are possible. But the HN prevailing sentiment (and elsewhere) is pitchforks and torches. Ok, disagree with google, but let's discuss about how to solve the android malware problem that is hurting real people, it is irresponsible to do otherwise.
It's not super clear from the post, but if I read it correctly there are two modifications suggested.
What you describe as "worst of both worlds" is about point 1. I'm not sure point 2 is powerful enough to suppor things like f-droid, but again, we'll see.malware are good at getting users to click past scare screens unfortunately. this isn't a solved problem, even with desktop browsers.
If you don't look both ways when you cross the road, then you may get hit by a car. The solution is to pay attention.
It's acceptable to build a system where human error can lead to catastrophic consequences, even death. Every time you go outside you encounter many of these systems.
Not everything in life can be made 100% safe, but that's no reason to stop living.
> The solution is to pay attention.
Swindlers work by that is a story as old as time. Even snakeoil salesmen were good at distracting people from obvious signs of false promises and warnings. People often overestimate their own capabilities greatly, same as there are no bad drivers on the road when you ask people about themselves.
I'm afraid the solution is to learn from mistakes. Which can be painful, takes effort, and at which some people will fail.
Society must be aware we are balancing "protection" and "responsibility". If you want some freedom you must have some responsibility.
I do not mind offering to some people more "protection" if it is clear they give up some "freedom". Some might accept the risks, some will not.
There are definitely things you could do to improve it though. E.g. you can't activate "I know what I'm doing" mode while on the phone or for 1 hour after a phone call. Someone else suggested a one-day cooldown.
Also for the specific scam they mentioned, why do apps even have permission to intercept all notifications?? Just fix that!
> why do apps even have permission to intercept all notifications?? Just fix that!
I fear "fixing" it would mean removing the feature entirely, which breaks many workflows. Primarily this is used for accessibility (and is controlled in the accessibility settings), but applications such as KDE Connect also make good use of it.
> Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores
F-droid doesn't want to track number of installs because that is an invasion of privacy.
> require developer verification, but also allow third party appstores like f-droid that don't require verification
Now you've moved the problem from Google gatekeeping apps to Google gatekeeping app stores. We don't want either.
Then i guess you can't publish apps? One of those issues where i should be "writing to my congressman" or whatever I guess. the problem is real and people like you are being obtuse, unwilling to find a solution or a compromise. Something as simple as number of installs is an invasion of privacy? how? it's a number, you increment a counter when someone hits download, that's it.
Yeah, if google gets to have rules over what happens by apps that have their seal of approval. that's how seals of approvals work. you're not entitled to these things. you don't have the right to publish to the android platform, if Google, wary of anti-trust suits allows a 3rd party app store, it can institute reasonable requirements.
If an appstore is willingly hosting malware, should Google still provide their seal of approval? That was supposed to be rhetoric, but I wouldn't be surprised if you told me that they should.
This is willful ignorance, I only hope you educate yourself on the harms caused by malware and malicious actors and consider taking a practical approach to finding solutions instead of dying on every single hill.
> Then i guess you can't publish apps?
I want to distribute apps (someone might also want to simply sell them), not publish them
I don't need a publisher, internet is a publishing media already
> you don't have the right to publish to the android platform
then let me install an alternative OS on the HW i legally bought and own or pay me back.
> the harms caused by malware and malicious actors
life is full of people doing harms and malicious actors, but we don't let Google or any other company gatekeep our lives
> life is full of people doing harms and malicious actors, but we don't let Google or any other company gatekeep our lives
Yeah, you're certainly not speaking for malware victims here. android is not your life, so google gatekeeping android (actually only google approved builds) is not gatekeeping your life.
You certainly should be able to load an alternative OS. isn't that what lineage and other android distributions do already?
Not when google lobbies your government and banks to require "play integrity" in order to use government apps and bank apps
Not device integrity (locked bootloader, signed image, which can be done with alternative OS) but "play integrity" so approved by google. In other words, you can't run android without Google's services, google's builtin ads.
And the alternative is iOS.
Loading alternative OSes is not an option anymore because play store attestation is now mandatory to live a normal life in society.
[dead]
How about the harms of fascist authoritarian governments that will use this functionality to ban any apps they don't like? Why do you people only care about malware and not essential fundamental freedoms that affect us every fucking day?
I guess it's because propaganda and scare tactics work.
talk about a straw man. "fascist authoritarian" is rich, governments don't need that to ban apps. Google can ban apk's on all android phones with a play store any time they want. Microsoft can do this on any windows machine with windows update turned (they have in the past), apple can do that with their OS's too.
Your freedoms are not the subject of this topic, not even remotely. Google isn't even banning you from doing anything on android phone, this is strictly about approving android builds by phone vendors, you're not even the subject here. Google doesn't want to approve android builds that allow sideloading. You can still install lineage.
Your argument here is actually "fascist authoritarian", you want to impose your views on the general public, that sideloading should be enabled. Having an option for yourself and other willing people to just not just vendor built android is not enough, you want the public to also leave the gates open so you can sideload your random apk's.
Oh, and for the record, my post was about finding a compromise, not a false dichotomy as you presented. If you made a car without a seatbelt it won't be allowed on the roads, if a phone vendor also builds an unsafe android where random devs an sideload apks, that shouldn't be allowed. Forget Google, governments should be enforcing the sideload ban lol.
You don't appreciate your freedoms and insist on abusing them, so actual freedoms end up being taken away!
> people like you are being obtuse, unwilling to find a solution or a compromise.
How are people being obtuse for refusing to compromise for solutions on a problem which doesn’t exist?
You can’t misrepresent the situation, establish that one American company having absolute control on what people do with their devices is somehow the norm and then complain that people won’t meet you halfway.
> How are people being obtuse for refusing to compromise for solutions on a problem which doesn’t exist?
I'll give you the benefit of doubt and assume you're just not well informed.
Millions of people are losing billions of dollars. Women are having their private media published to the masses. People are getting divorces, fired from jobs,etc.. because of android malware. The problem is nearly non-existent on iPhones to the most part, because they lock that down (but now thanks to "my freedom" type of freedom abusers are changing that too).
Apple already does this. You can't publish a driver for Windows without verifying your identity and buying an expensive code signing cert. Google isn't doing anything new, matter of fact, they're not doing enough! this still permits things like lineageos and other android builds to be installed -- that's your freedom. But since the prevailing sentiment is to resist a more secure way of doing things, the outcome will be that all smartphones will only load signed kernels/firmware in the future, and all signers will be required to id themselves, this will kill a lot of android builds.
This is why compromise is important. Your liberties are important to you, but you can't just dismiss the harm to the masses like that and refuse to find a compromise or a solution, that's how you lose what little freedom you have.
This is why things like "chat control" keep creeping up, and they will succeed down the road.
> hobbyists can still publish apps in third party stores
I shouldn't need an internet connection just to make an app for a device I own.
Why do I need a store to install something on my phone that I own?
In light of Google's recent push to eliminate this, I went and installed F-Droid to see what we'd be losing. I had thought about it for years, but always held off on doing it on my daily driver phone because I simply didn't want to open the floodgates on allowing apps to start randomly installing on my phone.
But having done it, I'm actually pretty impressed with the existing security. At least on my S24, you have to both enable sideloading at the system level, and enable each specific app to be allowed to "Install other apps" (e.g. when I first tried to launch the APK that I had downloaded from Firefox, I received a notification that I would need to whitelist Firefox to be allowed to install apps. I decided no, and instead whitelisted my File Manager app and then opened the APK through that).
I then installed F-Droid, allowed it to install other apps, installed NewPipe, and then toggled back off the system-level sideloading setting. NewPipe still works, and I don't think anything else can install. This satisfies my security paranoia that once the door to sideloading is opened that apps can install other apps willy-nilly. Not so.
So I really don't see what this new initiative by Google solves, other than, as others have said, control. The idea that somehow all user security woes come from sideloading apps and they would somehow be safe if they simply stuck strictly to the Play Store is patently untrue, given the number of malware-laden apps currently lurking in the Play Store.
You can also de-whitelist your file manager app from installing apps after you install F-Droid.
Sounds like they're rolling back the mandatory verification flow:
Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.
I'm a little nervous about what this advanced flow is going to look like, given that sideloading already requires jumping through a bunch of hoops to enable and even that apparently wasn't enough to satisfy Google.
I'm cautiously optimistic though. I'm generally okay with nanny features as long as there's a way to turn them off and it sounds like that's what this "advanced flow" does.
> Sounds like they're rolling back the mandatory verification flow
absolutely no. this is for the user side. but if you're a developer who is planning to publish the app in alternative play store/from your website, you have to do verification flow. please read the full text.
That's only if you don't want your users to have to jump through whatever hoops are needed to bypass the verification requirement.
But it's not mandatory anymore because people can install it without it being verified.
I feel like if safety was really their top priority, they would have done this long ago and not bothered with this mandatory signing nonsense to begin with...
Still, it seems like good news, so I'll take it.
"Allow". This is the entirety of the problem. They are allowing things on my machine that I purchased with monies that I leased my soul for.
Anyway, I am already planning for a future in which Google does not feature as prominently as did until now. Small steps so far ( grapheneOS ), but to me the writing the wall is unmistakable. Google got cold feet over feedback and now they can allow things.
When negative publicity ends, they will start working towards further locking it in again. I am personally done with passively accepting it. It might be annoying, but it degoogling is a simple necessity.
> I am already planning for a future in which Google does not feature
This. Currently I am still a paying Google customer for a few things running my freelance side business. I am in the process of migrating my data out of Google Drive and migrating my photos out as well.
Next step is taking back control over my email infrastructure. Especially as google nowadays sorts quite a relevant number of important mail to spam, while allowing more and more crap to pass into my inbox.
Also they one sidedly raised the price because they now have AI included. Fuck them - I am not using their shitty AI and I did not buy that. I am using AI daily - just not the crap product Google shoved down my throat.
garpheneOS/postmarketOS are next on my list. As I have a tertiary device around, I will during the dark months ahead set this up and see if it fits my needs.
With Arch now my daily driver (except for the main job), I plan to use way less US tech vendor crap. There are so many beautiful and not to difficult to use OS solutions out there, easily hostable on servers inside a more sensible jurisdiction.
Also currently working on a solution to get around the enshittified YouTube experience. Without it becoming an unreasonable effort to still watch the interesting things on my big screen in the living room. But automated AI audio translations did this in for me. I already find the automated title translations to be abhorrent - now, having had the absolute shit experience of starting a video and having it dubbed by an awful AI voice was just a bit too much for me.
Consider UbuntuTouch, really nice ecosystem and community, you can run many Android apks.
Ironic suggestion in this context considering how hard Ubuntu has pushed snaps over competing solutions. Canonical is the Google of the Linux ecosystem.
The key question for me is whether this "advanced flow" will allow the practical use of entirely separate app stores (like F-Droid) or if they're going to throw up tons of barriers for every individual app install.
There's a second path, whereby F-Droid registers as an "alternative app store", which is a new category of app created in the fallout of Epic Games v. Google [0]. This is interesting because it applies to all regions and will necessarily need more elevated permissions than the typical REQUEST_INSTALL_PACKAGES permission used today. No idea what requirements Google will impose on such apps.
[0]: https://en.wikipedia.org/wiki/Epic_Games_v._Google
What would they have to offer Google in return for being granted this status? Would they have to ban NewPipe, for example?
Up to what a committee of 3 people (or in the alternate district court judge James Donato) believes this means, assuming the judge approves the proposed modification to the injunction in the first place
> Google may create reasonable requirements for certification as a Registered App Store, including but not limited to review of the app store by Google’s Android team and the payment of reasonable fees to cover the operational costs associated with the review and certification process. Such fees may not be revenue proportionate.
One appointed by Google, one by Epic, one appointed by the other two. All three will be barred from private communications about any of this with any parties.
Considering this is an anti-trust suit I suspect the judge would be extremely unamused if the committee members found that "must ban NewPipe" was a reasonable requirement.
That sounds reasonable, but I doubt F-Droid can cough up the required US$1 million to pay 12 Google L7 SWEs to spend a month reviewing F-Droid once they get enough free time. I wonder if they'd require F-Droid to comply with PCI-DSS? That seems to be the trendy thing in review and certification processes, and naturally it's important for an "App Store" to have secure payments, isn't it? (Never mind that F-Droid doesn't accept payment except donations via liberapay.)
Yes, that possibility has occurred to me as well, and is potentially a reasonable compromise (depending on those requirements).
If I were designing the advanced flow, I'd require the decision to be made at phone setup time. Changing your mind later requires a factory reset.
Real sideloaders (F-Droid users, etc.) know at setup time that that's how they'll be using their phone, so it works for them. But ordinary users who are targets for sideloading malware will become a lot less attractive if attackers must convince them to wipe their phone to complete the coercive instructions.
Aliexpress has a similar approach to protect their accounts from takeovers. If you change or forget your password, all your saved payment methods are erased. This makes the account less valuable to an attacker, at the cost of a little pain to authentic account holders.
No, that's ridiculous. If I want to send an app to someone, now they have to wipe their phone to install it? That would kill installing non-Play apps far more than Google's original proposal.
I hadn't installed a non-Play Store app for something like 5 years until this year. I don't see why I should have been forced to factory reset my phone then.
Forgive my bluntness, but I hope you are never allowed on the Android team or near any significant UX decisions on any devices or apps I use or will use.
Great, at phone setup when many people don't know anything about the implications of the choice.
And factory reset when it's impossible to backup and restore everything, or anything at all without a Google account
But wiping your phone isn't "a little pain"
> Real sideloaders (F-Droid users, etc.)
When using F-Droid, I don't think of myself as a "sideloader". I'm using an app store (F-Droid), not installing some random APKs.
(Yes, the F-Droid store app had to be "sideloaded". Once. It updates itself. If or when Google allows alternate store apps in their store app, even that would no longer be necessary.)
If F-Droid is no longer part of the android community, then neither will I.
I'm not too worried. My employer should be, though.
It all depends on how the flow is implemented.
If it's a one time unlock, eg like developer mode then hopefully it'll just work.
If it's a big long flow per install... Yikes, that's not much better than adb install
Correct me if I'm wrong but doesn't the EU digital markets act mandate this?
EU digital markets mandates that you can install apps through f-droid... but doesn't mandate that those apps don't to comply with Google's signing policy.
Isn't Apple technically complying with this even while forcing notarization? Seems like Google could get away with the same scheme.
Apple says they are. The EU says they aren't. They're fighting over it.
I don’t like to see the word “allow” in the same sentence with a device I own.
It's a device you own, sure. But you've licensed the software.
This is misleading though. There is simply no other choice if you want to use mainstream apps. It could be argued (successfully in my view) that any agreement is null and void due to its acceptance under duress.
Users have an inherent legal right to unconditionally access the full advertised functionality of devices they purchase. Any agreement after that is inherently suspect and I wouldn't be surprised to find out it was ruled unconscionable by some court if it came to that.
> This is misleading though.
This isn't misleading in any way. It's unfortunate and we should be pissed about it, but this is exactly the legal arrangement that Google and Apple came up with.
> I wouldn't be surprised to find out it was ruled unconscionable by some court
Last US court battle, Apple told the court it needed the money from the kids casino to keep its profits, and the court just nodded.
Apple had to be held in comptempt of a court order after 4 years and a deluge of evidence, for us to see any significant move.
I agree it's not awesome, or even good. Unfortunately, it's what we've got today. A fact HN seems to dislike.
If there is an alternative software that can run on the device without going through extraordinary hoops, I may agree that it is licensed.
If there is no other alternative, buying hardware and licensing software are not two different steps. Its just buying a device.
Let's not shoot the messenger (edoceo)
Too many people are in denial about what they actually own, and seem to refuse to accept this battle isn't starting or coming up, we're already in the process of losing it.
Clinging to material ownership feels great on the moment, but that's absolutely not what we need to deal with right now. It's kinda like being so proud to be the registered owner of your car, while it's getting impounded and you'll be spending the next 10 years trying to get it back.
We need a free-as-in-freedom version of Android.
GrapheneOS
Google is suppressing freedom.
"Go, give money to Google, to reclaim freedom"
What's Google profit/margin on Pixel phones nowadays (hardware only)?
GrapheneOS is also in danger.
Already exists. LineageOS, /e/OS, GrapheneOS, to name a few.
Which is an unacceptable loophole in our legal system that should be closed immediately as far as I'm concerned. If I buy a product, even if that product is software, then I own it, and I should have ultimate control my copy of it.
The idea that we allow companies to go "Yes, you paid for this product, but it's not really yours. We still control it and can do whatever we want with it regardless of what you want." is asinine.
Then let me put my own software on the hardware I own then.
Well you can. But then it has to be completely your own software (i.e. OS).
8 days ago Google and Epic announced a proposed settlement and modification of a permanent injunction that Epic won, I believe this proposed settlement would likely have prohibited Google's plan to forbid installation of third party apps (excluding app stores from the definition of apps) unless those app developers had paid google a registration fee. The proposed settlement is here [1], the relevant portion is
> 13. For a period beginning on the Effective Date through June 30, 2032, Google will [...] and will continue to permit the direct downloading of apps from developer websites and third-party stores without any fees being imposed for those downloads unless the downloads originate from linkouts from apps installed/updated by Google Play (excluding web browsers).
6 days ago the court expressed skepticism as to the proposal and announced that they'd have a hearing, with testimony from expert witnesses, as to whether it would prevent the market harms that the original injunction was trying to cure [2].
Today Google announces this, effectively confirming that they're backing down from their requirement that third party app developers pay google prior to distributing their apps.
Nothing (yet) is explicitly tying these together, but I can't help but suspect that this move is in large part being made to convince the court that they're actually intending to honour this portion of the proposed injunction even though Epic would have little reason to enforce it.
[1] https://storage.courtlistener.com/recap/gov.uscourts.cand.36...
[2] https://storage.courtlistener.com/recap/gov.uscourts.cand.36...
Did we read the same thing? I think Google here said there would be a $25 fee per developer (for those who can't fit in their limited distribution category). I suppose it's much better than a fee per paid install but it's not nothing.
See the "Empowering experienced users" section.
They announced the $25 "verification" plan awhile ago. The new part in this article is that they're going to have it remain possible to install software that didn't do that "verification".
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
That quote doesn't say anything about the hoops "experienced users" have to go through in order to install said software.
It says that there will exist a working set of hoops though. Which wasn't the plan before.
In the end when supporting the non tech people in the family, what I would really like is to setup their device so they can install anything on Fdroid but nothing from the play store (unless approved by me) nor direct from an apk.
This is exactly what I do. Works pretty well. I've never needed to restrict the play store. I just tell them not to use it.
I wonder if MDM can do that.
We really need to banish the term "sideloading". Installing apps on a terminal is just that, and for as long as I remember on windows, Linux it has always been just that.
Google mentions about being on a call, and being tricked into handing over codes. So why not use signals and huristics to decide?
If user is on a call, block any ability to install a shady app. Implement a cool down before that functionality is restored (say 24 hours). It can also detect where the user is based to add additional protection (such as mandating the use of play protect to scan the app before it's activated and add another cool down regardless).
There's lots of ways to help protect the user but it's wrong to ultimately control them. The real world is full of scary dangers that technology is trying to solve but is actively making things worse (such as computerized safety systems in cars).
Ultimately, the user is responsible and whilst it's palpable Google would want to reduce harm in this specific way, we know authoritarian governments would also love to be able to dictate what software people can run. The harm to democracy is simply too great in favor of saving a few people's money.
They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed.
You will not be able to use any of your banking apps without first removing all of those...
We need alternatives, this will not work and is a risk to freedom/democracy for all of us.
Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. However Google and Apple can just remove it, what then?
[1] https://github.com/swiyu-admin-ch
Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices?
I just can't see any good reason for it but my banking app has invested more work into detecting any possible hint of rooting than into its UX. It's absurd.
> Seriously though, can anyone tell me why the fuck banking apps try so hard to find any possible excuse to not run on customised devices?
As an early cyanogen mod adopter I really don’t want to lose ability to side load etc. but to answer your question this is probably for the lowest common denominators safety. Anecdotal example - a scammer tricked my parents into sideloading an apk which automatically forwarded all sms messages to the said scammer. This lead to 2FA code from bank go through and allowed them to perform some transactions. There were many red flags during this ‘call from a bank’ and I’d say some blame lies on my parents here, I guess this is the only way to lock down bad actors? I am not entirely sure it is.
Banks have stupid rules probably made by people who don't understand the matter. A relative recently got victim to phishing and gave away some of his banking details (fake e-banking login screen on a website). After locking the account, the bank said it would only unlock it after the phone got wiped, which obviously doesn't add anything in this situation.
Another pet peeve is that they prevent screenshots simply because they can, and it feels safer. I know, 3rd-party apps which can do screenshots etc., but this is fighting the threat the wrong way. And yes, it's partially the fault of the platform, which could just allow user-initiated screenshots. Or at least make it configurable.
> Banks have stupid rules probably made by people who don't understand the matter.
Their insurance policies, if I had to guess.
Unlikely, banks do not reimburse this kind of fraud in most of the world.
This is most likely the bank just being genuinely nice and taking care of customers who range between very stupid and momentarily distracted.
>After locking the account, the bank said it would only unlock it after the phone got wiped, which obviously doesn't add anything in this situation.
How is that supposed to be a stupid rule? Do you have any idea how much fraud this stops?
It may not be banks themselves doing this.
For example, my bank here in Hungary, Erste Bank has announced that the central bank requested that they stop allowing their android app to run on "modified" devices.
They even have a workaround: switch to SMS-based 2FA and use their website (which works well on any screen and has all the features of the app except 2FA)
> the central bank requested
That's the answer, it's regulatory bodies causing this.
In 90% it's insurance compliance.
Is this is something small regional banks in the US do? I'd actually be very interested to know about who is providing, and who is taking such coverage if this is being (re)insured. If you have any market data/news, I would love to know.
If you run a pentest, allowing rooted devices will almost certainly show up as a vulnerability. It'll be marked "low risk", but you'll also be told that you don't want to "accept risk" for too many "low risk" vulnerabilities.
So somebody then needs to say that this is not something they worry about rather than doing the easy thing and remediating it.
At most banks, the absolute control belongs to risk and regulation department. A bank must safeguard their license above all else, and it is very easy for them to loose it if the bank is found doing something it should not (though for the big ones, they sometimes operate in a gray zone, which means they manage to keep their licenses despite relatively steep fines). Even for the simplest ui/ux change, risk department has the final say. Source: I’ve been working 15+ years in the banking industry.
Probably because it makes it easier to observe and/or intercept API calls and other data exchange between the client and the server. It's trivial to disable things like SSL cert pinning, etc. on rooted devices.
… and then the return argument is that those who actually want to do this nefariously are already going to be able to hide device modifications/rooting.
Insurance, they don't want to be on the hook if you get robbed.
How useful is it to have a unique global ID, that the target willingly carries and manages, but doesn't have any meaningful control over?
> They will just add a flag in the SafetyNet service to let other apps know if non "verified" apps have been installed.
Sincere question: do you have any evidence for this?
I don't see anything in the article that backs it up, and your asserion seems to be at odds with the description of a side load capability for "risk tolerant" users. What you describe would certainly break much of the usefulness of side loading for me.
I certainly don't trust Google, or underestimate their capacity for duplicity. I'm just not sure about the outcome you describe.
It a projection of what they could do. ie. logical step
The whole SafetyNet and "secure chain" things are PITA, eg. ChatGPT app wouldn't work if the phone bootloader isn't signed by Google. Lots of banking app wouldn't work, HSBC banking app for instance wouldn't allow login if Android developer mode is enabled.
Some apps do this because of some minor audit crap with relation to screenshots (the devmode part) afaik. Others just always blank the screen image and tell the auditor to [insert crude metaphor].
Same none sense with root enabled. You must have a check, doesn't specify which one and as long as you can show it works once you are fine.
Of course, it wouldn't be HN if the previous claim that "the sky is falling" wasn't followed up with "well, it's not falling, but I saw some heavy rainfall!"
Is the digital ID just to identify yourself online? Because I've never had to do that. Kind of seems like a solution in search of a problem.
The digital ID e.g. eID is for example if you want to order a government document online. At the current time you need to print out your request and send a copy of your ID in the mail or go to the counter and show it. Same if you get a bank account or new phone contract although those usually let you scan your ID with your phone. A eID would make that more secure although people are already being tricked into doing face validations[1]...
Offline it would make it possible to verify your age at the self-checkout registers without having someone have to check in person.
In the future (if the law allows it, which it currently does not) it should be possible for you to purchase an item online completely anonymously, at least to the vendor. There would no longer be a possibility of leaked address, etc. as the vendor would not have it. All the vendor has are signed tokens. When they send a package they send it with a token to the post office and only the post office knows your address.
[1] https://www.srf.ch/sendungen/kassensturz-espresso/espresso/m...
They won’t remove it if its been installed from their app stores.
They removed the "ICE" app and if the US government has an issue with other Apps they bend over and do it.
Switzerland is currently dealing with a 39% and Brazil with a 50% tariff because Trump has a personal problem with them. It would not be far fetched for an administration to have another states app removed.
I just want to preface that I am not in support of Apple or Google in their closed ecosystem.
I was specifically referring to you saying "Switzerland is implementing a digital ID[1]. It will be made available to the most common devices and is open source. However Google and Apple can just remove it, what then?"
It seemed like you were saying that because it is open source, it will be removed. I simply disagreed with that. Plenty of opensource software exists in the app store.
I'm not disagreeing that they have the ability to remove software from their app stores. They have done that before as you mention. That is a fact.
> It seemed like you were saying that because it is open source, it will be removed. I simply disagreed with that. Plenty of opensource software exists in the app store.
Sorry if it came across that way. It is not what I meant, I just mentioned that it is open source. ESL...
Why do you think that will happen?
Paranoia.
The current US administration is not acting with logic nor reason. Switzerland is currently dealing with a 39% tariff for no reason. We are the 7th largest investor[1] in the United States with thousands of jobs and we are the worlds 3rd largest holder of US dollars[2].
[1] https://globalbusiness.org/foreign-direct-investment-in-the-...
[2] https://en.wikipedia.org/wiki/List_of_countries_by_foreign_e...
It's not "sideloading". It is "installing". Just installing the software you want, on the device you own. I am not "sideloading" applications on Windows, either. I download and install them. And before the internet, you got your software on CDs or floppies and ... installed them. This is nothing new. The term "sideloading" somehow implies you are circumventing or side stepping some mechanisms or protections in a non-sanctioned / nefarious manner. I am not. I just install software on my phone.
* "Android Developer Verification Discourse" by agnostic-apollo (https://github.com/agnostic-apollo), Termux app (https://github.com/termux/termux-app) developer: https://gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a... (gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a6bef53d417a6) and https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (old.reddit.com/r/termux/comments/1ourtxj/android_developer_verification_discourse/)
* "Android Developer Verification Proposed Changes" by agnostic-apollo (https://github.com/agnostic-apollo), Termux app (https://github.com/termux/termux-app) developer: https://issuetracker.google.com/issues/459832198 via https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (old.reddit.com/r/termux/comments/1ourtxj/android_developer_verification_discourse/)
Android Debug Bridge (https://developer.android.com/tools/adb) using two Android smartphones and Termux (https://github.com/termux/termux-app):
* Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)
* Search for "termux-adb" in "Motorola moto g play 2024 Smartphone, Android 14 Operating System, Termux, And cryptsetup: Linux Unified Key Setup (LUKS) Encryption/Decryption And The ext4 Filesystem Without Using root Access, Without Using proot-distro, And Without Using QEMU": https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot... (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)
You don't need two phones to use ADB with Termux. Just put the ADB settings app on a split screen and it will work just fine. I used it several months ago.
I'm already annoyed by the fact that when I upgrade my own apps, self-developed and only used by me, which are installed either from Android Studio or by letting the app itself download the update from my server (with the app installation permission) and me then installing it, that I must send the app to Google for them to make a security check.
It's not an option, even if they pretend it to be one: if I click the text "install without scanning", nothing happens. I must accept the big button that uploads the app for a scan. It's none of their business.
ADB is no alternative for me, because it's easier for me to send a websocket command to my 9 devices (mostly dashboards) so that they download the file and start the upgrade process, so that I then only need to press the "upgrade" button manually on each device. Remove the dashboards from the walls, just to plug an USB cable in them, to upgrade the apps?
Is ADB over wifi also a non-starter?
Yes
So there was the very concrete problem that F-Droid could not continue to function with the verification requirements, because they rebuild every app and so would have to know every key.
Do the changes here do anything for F-Droid?
What this probably means: to use F-Droid on your phone, you will have to first go through the new unverified app flow
That would at least be an improvement to the current situation, were they wouldn't be able to operate at all.
If the flow is designed such the you only have to do it once for F-Droid and then the unsigned apps would be installable from there without friction, it wouldn't even be that bad.
Ancedotal: I used to believe in this "freedom to install". Than my Father got scammed (~$1000) in the name of Electricity recharge. The APK was sent over WhatsApp. Now I am not so sure how to implement this freedom. At the bare minimum there has to be big red warnings.
One thing which can immediately improve security is forbidding SMS read access forever. Just like Apple does. No App should be able to read SMS.
So your father: 1. Downloaded a weird file from a stranger
2. Went to the settings and about pyone sceeen
3. Tapped the thing 5 times to activate developer mode
4. Activated installing from third party sources despite the warning there
5. Installed the APK
May I suggest the problem is not that this is possible, but a lack of education? If your father is the type that would jump into the bathtub with a toaster because someone on whatsapp told them to do so, I am afraid it is not the existence of toasters that is the issue.
Yes, education around these scams and their methods could be better, but there is also a reason they target the elderly and vulnerable. Unless something else terrible happens, I assume I will count in one or both of those groups eventually. I feel like when I get there, I would appreciate empathy rather than disdain, if I were ever taken advantage of.
Regardless, you do not actually need to enable developer settings to install APKs from unknown sources (at least, not on my Samsung). When you open an APK from within another app (e.g. Google Drive or WhatsApp), Android "helpfully" forwards you straight to the relevant security settings page, allowing you to immediately toggle the "Install unknown apps" permission for that specific app. It's a streamlined flow, only a couple of taps, no scrolling/searching/reading, therefore likely easy to coach a victim into performing.
So, I expect what the Android team is alluding to in the original post is to enable additional friction like you describe.
One does not need to enable developer mode to install a 3rd party APK.
eh, think this is a bit much to ask. Are we going to educate a majority of the baby boomers who just never got a feel for how technology works? Yeah, my Dad also just got scammed by a phishing scheme on his PC (and if a scammer had walked him through how to install an apk on his phone, he'd probably do that too).
In my humble opinion, in the design of a UI or any type of system, kind of have to go where the users take you to some degree. And Android, being an OS for consumer devices, should be geared toward the masses and the mistakes they'll make.
Should we ban refilling your own cars oil because some idots keep filling coolant into it?
I worked in IT support and I am deeply aware with the issues people are having. Some issues are systemic (aka bad design) and those should be fixed. Other issues are human.
It may not seem like it, but I have the patience of an angel, because I remember when computers where new to me. I like people to understand. Understanding is power. But when I did work in IT support I saw some things. Grown adults repeatedly clicking away error messages without reading them while I stand and watch over their shoulder. When I ask them what their error message read they say they don't know. Then we read it together and they go: "Ohhh".
Yeah. Ohhh. You have a weird error that prevents you from working and there is a red error message and you don't bother to read it. That isn't a technological problem that is a educational problem.
I stand by what I said, we cannot dumb down our system because people don't care, are lazy and act dumb. Because that leads to a cycle where it gets ever dumber and lazier all while making life hell for people who are not dumb or lazy.
If you want to use a car you need to know certain things. Same is true for digital systems, the internet, a smartphone, a toaster, a hair dryer, a knife, a simple plastic bag, etc. The solution is education, not dumbing down the world.
Well, yeah, everything has limits and this issue seems like a very practical one. Seems like it depends on how much work would be needed to teach the user base, which, at least to me, feels out of reach. As your being in IT, you may agree that teaching a large majority of 60+ year-olds standard things on something like Windows is difficult and extremely slow. Feels like it would take at least a month of dedicated training, where they are full on board. Having helped my older friends out, don't see that happening anytime soon (a half hour here and there is all they seem willing to do).
But you know, if there is a method that you know that can teach the masses these skills, then am all for it (maybe barrage them with youtube commercials teaching basic tech skills?:)
Shouldn't the logical conclusion be that if it's too much/hard to teach these people how to operate a device safely, they operate the devices in an unsafe way, bare the cost of it by being scammed, learn that it's not safe for them to operate the device for certain use-cases due to the experience, they tell others about it and it's in media -> people who do not feel confident operating such a device securely are scared away from using it due to the potential consequences they heard about -> problem solved (from a banking security perspective)
(except now the bank needs more staff behind the counter)
Not 100% sure if you mean this genuinely or joking around a bit. Will assume the former
Well, think just letting the knowledge of user failure expand organically is definite a method of deterrence, and some amount of this probably going to happen to some of the users. But to me, seems like it's a question of what percentage of your user base would be exposed to being scammed. Of course you'd want his to be zero, but if it's significant, yeah, probably should put measures in place to reduce the amount of scamming. Even on a purely practical level, it's bad for the reputation of your product...
...Am thinking, since there is so much resistence to locking down android, one problem might be was it was initially billed as a more open OS that tech people could enhance in whatever way they wanted. But yeah, times have changed, it's now a product that is used by the masses, and guessing the masses are now their most important users. Not saying this is wrong or right, but probably why there is so much push back as compared to say if iOS did the same thing (which they may have already done).
I wrote a longer post about that elsewhere but there is morally no good justification to restrict everyone else's devices just because a small minority falls for scams. This is a very principal issue in a free society and in most societies we allow all kinds of individual risk taking because we believe that adults should make their own choices even if that means that some people sometimes make mistakes.
On a side note, it is technically very feasible to help antivirus and security software makers to lock down phones for people who would benefit from it. For example, you could have a strict whitelisting approach for vulnerable users (e.g. elderly, bitcoin entrepreneurs, annoying kids, Google engineers) who prefer it that way, making installation of arbitrary software impossible. Giving up choices voluntarily is fine, taking away choices by force is not fine.
> The APK was sent over WhatsApp.
Why did your father enable installing APK packages from third party sources? That's a setting buried deep inside the developer settings, which themselves have to be activated with a very arcane manipulation
I believe this only works this way on some android forks, iirc you are talking about Samsung. Stock android would show a warning "do you want to install apk from this app?" and lead you to a settings page that enables apk installs from this particular app. No need to separately enable the ability to install apks in general.
I always thought this is a very weird flow, it adds hoops yet accomplishes nothing because the hoops are all trivial and the same for every app.
This is also how it works on my Samsung Galaxy S21. There's no need to enable developer settings.
I have definitely seen this "you need to go deep in the settings to enable 3rd party installs at all" flow before, but I don't remember which device it was. (Just saying that the commenter above is not just inventing something, I was surprised when I saw it as well)
There definitely is such setting, but I have no idea when it was introduced. S21 is an old phone (not to disparage it in any way).
https://www.samsung.com/ae/support/mobile-devices/how-to-ena...Hah, yes, this is also how S21 works. But to still refute the OP's point: (1) it is in stock settings, you do not need to enable the developer settings menu via any arcane method. (2) When you tap on an APK in e.g. Google Drive or WhatsApp, Android "helpfully" forwards you straight to this settings page, allowing you to immediately toggle the "Install unknown apps" and installation will begin (there may be another "do you want to install this app" confirmation).
The point being that there is not a whole lot of friction in this flow -- one or two taps -- likely making it easy for scammers to coach victims to perform.
I agree that activating the developer settings menu is substantially more friction, and may arouse more suspicion in a victim, but [on many/most devices] is not currently required. I guess the original article is alluding to putting this kind of friction in place.
> No App should be able to read SMS.
I disagree - one feature in KDE Connect that is super useful is being able to forward your notifications, including your text messages. This would also harm non Android smartwatches, such as the recently revived Pebble.
There seems to be a whole market of Google Play developer accounts and apps for sale, developers like myself regularly get emailed by scammy companies offering to buy the account or to publish an app, and malware is regularly found on Google Play[0]. There's no reason to believe that bad actors would be stopped by install restrictions if their scam is effective enough to overcome the financial hurdles
[0] https://www.bleepingcomputer.com/news/security/malicious-and...
The built in Android SMS app seems to be horrible in every incarnation I've seen. The one that comes with the Pixel, the one Samsung has. Some may like it, but I can't stand them. I tend to install my own SMS app in each case, and I don't use computers to be locked into something I don't prefer.
It's my tool. Mine. I'll do with it as I please.
I agree there are issues. But preventing installs aren't the answer, just like removing all windows and doors from a house isn't the answer to neighbourhood crime.
I'd be more inclined to say the problem is allowing apps to be funded by advertising. If all apps were paid apps, and using personal data in any way was immensely, "thrown in jail" illegal, then you'd find yourself approving access to contacts, SMS, Pii quite rarely.
It would really stand out in such a case.
"What?! I've been using my phone for 10 years, and some app wants to see my contacts. Why?? No one reputable asks for that, ever!"
So much of the problem with the internet is that Pii is paying the way.
On GrapheneOS, when I install anything, it flat out asks me if I want to give it internet access at all. SMS could be the same way. Off by default, try to grant it, big warnings.
At a certain point, if you have big warnings saying "Are you serious?!" and people turn it on, it entirely ends up being the end user's fault.
- warning - SMS read access
So you do know - inform users, increase privacy,...?
Genuinely curious: would you mind telling more about how your father got scammed and how the adversary managed to get your father to install an app from WhatsApp?
I receive all my SMS messages through a separate app, because my SMS provider is not my TelCo. Please propose solutions that will not harm people like me.
For real? No, thanks I'd like to keep my SMS app
Freedom and protecting tech illiterate people are not mutually exclusive.
Our right to choose install software on our own devices should not be encroached because over-trusting elderly follower scammers instructions.
We can protect people like your dad with an opt-in system like parental controls. Have a responsible family member lock the system down however you deem fit.
Sounds like an iPhone is the better option for your dad.
Damn. I was excited by the prospect of Google shooting themselves in the foot, inspiring people to make Android replacements that aren't privacy and process nightmares. With this (partial) capitulation, the path of least resistance will remain a proprietary, corporate-controlled, bloated walled garden.
> Keeping users safe on Android is our top priority.
Then let me decide which apps can access the internet, and which app can access which domain names / IP addresses.
Because it feels like there are a lot of DATA THIEVES out there, selling my data to companies you work with.
We call them Firewalls on the PC.
I don't understand the title, it's exactly the reverse, they will force verification for sideloading, even if they say they would have lighter requirements for hobby apps with low install number
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
aka "Trust us bros"
@dang this post title was editorialized against the rules, and is highly misleading. Should we revert it ?
Reverted now, thanks!
There are many real-world sideloading abuse cases in China. Attackers often trick victims with plausible stories—e.g., claiming a flight is delayed—and ask them to sideload an app (a remote‑meeting or remote‑control tool) to share their screen. Once installed, the attacker can view the victim’s screen and intercept SMS 2FA codes for online banking or other sensitive accounts.
Other schemes include impersonating sex workers to lure victims into nude video chats, then persuading them to install an app that harvests private content and contacts for blackmail.
Why should that mean anyone else should lose control of their device? Maybe at some point you have to accept that it's the user's responsibility? Maybe empower users to be aware of what the apps they install are doing, without take their control away?
This is how loss of autonomy always happens in every sphere: make an argument that it's for their own safety that individuals are losing autonomy, and the entity gaining control is superior in knowing what's best, and is taking control only out of the goodness of their heart.
Yes, this is called malware and isn't the fault of being able to install software on your device.
If someone tricks you into handing over the keys to the kingdom, the solution isn't to remove your door.
These unfortunately gullible people would be tricked in many different other ways throughout their daily lives even if it wasn't for the ability to install something on a device that you paid for and outright own.
We don't cater the most stupid in society.
What's the Android situation there? Last I heard Google didn't license Android there and they were using Chinese app stores with forked AOSP Android. Which would seem to put the sideloading decision in the hands of the forked OS.
If by necessity you need to leave the door unlocked more, then you can expect more bandits to pass through. The frequency is a result of China's banning of all Google services, and the mess of Google Play alternatives making the universal option to request users to just install the APK off of a sketchy cloud link.
> intercept SMS 2FA codes for online banking
Google should just ban all apps that use SMS 2FA codes for login.
This brings back memories of "sure you can root your phone, but if you do secure apps like payment won't run anymore"
I can only imagine that allowing "unverified" apps to run would also disable payment/banking apps. Just in case, you know. For your own good.
That should be up to the bank to decide, and it already is. https://developer.android.com/privacy-and-security/safetynet...
None of my banks have complained to me because I'm running a patched YouTube app.
That doesn't seem to have anything to do with what apps you have installed, just whether you have Play Protect enabled. I have Play Protect enabled, and I can still install apps without having to scan them first.
See the listHarmfulApps() documentation on that page.
Are there any entities on earth with resources to compete with a complicit global duopoly?
If Android is open source, why can't/won't a community fork it? Graphene OS exists but many folks claim Netflix and banking apps do not work with it (despite allowing logins from any common desktop browser)?
If all widely-accepted phone operating systems are de-facto proprietary, what does this say about the current phase of society?
What choice do non-billionaire/millionaire humans have for living in a single-planet society where technology is so highly integrated (and the inherent non-consensual compromises)?
What If the little people are going to get squeezed even more?
Troubling questions.
LineageOS is based on AOSP and works well. I don't understand the banking app thing either. I suspect it's a regional issue. I can log in to my credit union account via any browser, and if something needs MFA it should be able to use TOTP which works on anything.
Android in practice is full of proprietary blobs, stuck on old kernel versions, and the hardware is barely supported. Lots of downstream crap from the vendors not playing nice. Most devices running Android are instantly doomed to be e-waste. You can look through devices postmarketOS supports, and anything without mainline kernel support and most stuff working is basically e-waste unless someone puts in a lot of work for that particular device. It's a little bit like how modern GPUs don't work without blobs in the kernel anymore and you have to go back to Haswell era or older for things to work with all free software, but the state of smartphones is a few steps worse than that due to their locked down nature.
Pretty much any OnePlus device (other than ones still too new) seems to be a good bet for decent software support (both LineageOS and pmOS). Though annoyingly stuff like the 3G shutdown makes a lot of the earlier models unusable as actual phones these days. At least they can still be computers. Not quite e-waste.
Yes we have banking websites but they are increasingly moving to an auth model where you have to enter an otp generated in the app but the app refuses to work on non-verified devices.
Well, would the community be willing to respond to AI-submitted CVEs without funding?
I had been Android fan from the start. When first Android phones went out I was astonished by the amount of possibilities. There were linux phones available, my colleagues used to set up ssh servers and more. Samsung had Baidu at that time which at least to me appeared more closed than Android.
Things have been going bad since then. Closing of root access, closing of software, youtube not working in split screen etc. All the changes make me think of Android as more and more repulsing. Recent changes like removing old software from the store because they didn't update API and now this... Google stop being evil
> Google stop being evil
You think this is evil? :-)))
Watch what happens as they can't grow by 10% per year and their share price tanks in 5-10 years.
Glad to see Google come to their senses on this. Disabling it entirely would have basically guaranteed an exodus of power users over to iOS. If your only choices are walled gardens, you might as well pick the easiest, prettiest one.
it's not
> "Google come to their senses on this"
it's
> "Google was forced to their senses on this"
"For now."
Google still hasn't changed anything but took the opportunity to again insult their customers within the first headline, titled "Why verification is important".
Google goes on to say how taking away one of your last remaining rights is good for you, if you like it or not.
It is clear to everyone why Google is partnering with governments around the world to remove our rights to installing apps. Laws are not on your side and must be reevaluated on an individual level to move forward. You decide your own terms, you have the power.
Only we can stop this together.
What prohibits Google from offering a way to register your long-term app signing key without identity verification, publishing apps that are still verified by their automated tooling and then opting in to the usual denylisting/app store banning methods if those apps are malicious? This identity verification requirement is basically just an easy way for illiberal governments to find ways to crack down on apps they do not like (such as say, ICEBlock or whatever)
Banning all apps signed by the same key is already possible. Requiring signing keys to be anonymously registered with Google would add some friction to simply rotating your signing keys when you get caught doing something naughty (depending on how much Google account creation and key registration can be automated against Google’s anti-bot protection, though), but definitely not as much as full identity verification and payment of 25 USD (even if that isn't foolproof, either, and has the annoying side effect of unfortunately slowing down small-scale freeware developers at the same time, too).
So an interesting intellectual exercise is to try to figure out how you would create a power user toggle that is coercion resistant. The best I've been able to come up with is a timed lockout that is random in how long it takes to allow you to finally move into power user mode. So like a random value between 1 hour and 24 hours and you say I want to be a power user and then it says you have to wait 3 hours and 27 minutes before you can become a power user. Randomness because a scammer could optimize around a particular time period that was predictable.
Other thoughts on how you could make a coercion resistant power user toggle? I'm very excited that Google's thinking about offering this because it gives me faith that just because I chose to be in a minority, I won't be relegated.
On the flip side, I was so shaken by the original announcement that would kill off F-Droid that I've been very actively looking into building my own mobile device that runs Linux. I purchased the components for a Hackberry Pi that I'm hoping to build in the next couple of months, but knowing that Android won't kill off F-Droid entirely is heartening.
That could be done by requiring the use of ADB. Normal users would found it troublesome to setup a phone through command line.
To make it even harder, they could also require a verification code from your phone manufacturer, or the package of your device, which makes it impossible to automate the switch into power-user mode.
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.
I don't agree that this is something that should be restricted to "advanced" users, even. One of the basic freedoms that protects users from the unilateral control of the developers, is other developers (like me) being able to patch apps and distribute them to friends and family, without making a public fork or meeting play store requirements. Take for example, youtube revanced. If I want to help my friends by making a private f-droid or obtainium repository, to save them the trouble of going through the (legal!) process of patching and updating the app themselves, right now I can do this. If this requires going through a lengthy process instead, that may or may not be detectable by apps that will then choose to cease to function (this has happened with rooting), my ability to help friends and family as someone with the know-how and experience gets reduced significantly. There's many things that don't fly on the play store, such as the completely legal NewPipe, AdAway, and Termux applications, and while I can sign up for the developer verification, it's not clear to me under what circumstances the verification can be terminated.
That's by far not good enough. Google's reasoning is principally flawed.
First of all, there is principally no good reason why adult people should be patronized by Google or other companies and kept from installing the software they want to install. Limitation of numbers just means that I cannot publish my .apk and let users install it freely. However, anyone who is allowed to smoke, drink alcohol, or get a motorcycle, should also be allowed to install whatever application they want. It's a matter of basic individual freedom.
Second, the majority of reasonable users cannot be restricted from using their device as they wish just because a small minority falls for scams. A minority of people also drink themselves to death, die in motorcycle accidents, or smoke. There is nothing wrong with taking risks and taking responsibility for one's own life. We don't need for-profit corporations to hold our hands.
Third, if they believed their own arguments, then they'd make certain functions such as intercepting SMS messages and installing a custom keyboard subject to stricter requirements with potential developer verification and keep the OS open and free otherwise. This would be a piece of cake since the technical infrastructure is already there on Android. The fact that they don't clearly indicates they're hypocrites and want to control users and developers, make 3rd party app stores harder or impossible, control which apps they "allow" as part of anti-competitive behavior, and possibly extract some extra cash from developers in the future.
It's a pity how private computing is destroyed and that's the reason we all have to use inferior web apps until browsers are closed down in the same way in the name of security theater.
If adb is unrestricted and can work with the Linux command shell (something I seem to remember I had read about before; you will need to enable the developer mode to use it), which is aparently a separate system but runs on the same device, although if it has the ability to communicate with the main Android system using adb (which it might be reasonable to require that to be explicitly enabled with another setting, for additional security in case you do not use adb), then this would help since you do not require another computer that would be compatible with adb in order to do it.
However, I think there are other things they should do as well (in addition to the other things) if they want to improve the safety, such as looking at the apps in Google Play to check that they are not malware (since apparently some are; however, it says they do have some safeguards, so hopefully that would help), and to make the permission system to work better (e.g. to make it clear that it can intercept notificatinos; there are legitimate reasons to do this but it should require an explicit permission setting to make this clear).
Sorry, really confused user here, so can someone ELI5 for me? I was looking to go to GrapheneOS, will this effect that at all? The title now says they will allow side-loading and it sounds like good news but everyone in here is still complaining. I do not mind this extra step and I think it is way better than what my POS iPhone 16e with Liquid@ss is offing me.
"Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months. "
This is the last moment we can use to move out of this platform. We've already given basically all the control on our lives to two companies. They will decide one day that government will know our each move, our WiFi password, number of appliances, our body temperature and chemical compounds of our bodily fluids - every sensor that is connected to the system. 1984 all over again but this time IRL
This is old rule: you don't need to take over control of all the people, you just need to take over those two-three suppliers that are covering all the people. If for example new politician Tronald Dump will take seat in 2035 in USA and they will try to push their agenda to other countries, they will take over the LLM, phone and OS providers, namely OpenAI, MS, Apple, Google. That's all to control to have the souls ruled all over the world. If something must vanish, will vanish. Like in the Ministry of Truth
> When the user logs into their real banking app, the malware captures their two-factor authentication codes
That seems like a severe security bug in Android APIs or sandboxing or something else.
> bad actors can spin up new harmful apps instantly
Why are harmful apps possible at all?
> That seems like a severe security bug in Android APIs or sandboxing or something else.
No, this is the permissioned API that makes KDE Connect work, which makes Apple's Continuity look like a toy and that also lets me programmatically filter notifications.
As soon as a platform gives control to the fullscreen, harmful apps are possible.
See for example Apple detecting if a user is typing on a keyboard while in a fullscreen website, and then blocking the website. Yes it's as crazy as it's sounds.
It's a permission the app can have. Android asks the user whether to allow it when you launch the app. It's a very useful permission for some apps that I use. But a scammer can just tell the user to accept the permission.
Super obvious move. It will probably make you type "I understand I am Gonna get haxxored" while clicking a moving dot 5 times and promising you are super power user. This would have been the end of android as a phone OS.
>we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
This is exactly the right thing to do and the best possible outcome. Google is correct that arbitrary Software installation can be harmful to users, especially those with limited technical knowledge. At the same time there are many users who want to install software freely and should be able to do so.
The compromise of a clear and unambiguous warning of the potential dangers, which the user is then allowed to accept, seems very good and the right thing to do.
so still distributing with f-droid is messed up? i now have to pay a fee to develop an open-source app via f-droid to everyone?
this is a misleading title. they only allow side-loading unverified apps only on fewer devices.
Don't know if you read the whole article
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands.
Or am I misreading your comment?
"this is a misleading title"
Marketing at work, I am not giving away my ID to publish an app on an alternative app store, like F-Droid.
Google is abusing their "gatekeeper" status, like Apple does.
Interesting. Did Google submit due to pressure? I have no idea. But if so then it shows the power people have. Perhaps we can make Google less evil if we complain a lot about things they do.
Well, this is the most naive thing I've read all week.
> Keeping users safe on Android is our top priority.
I'm really over third parties telling me that my safety is their priority. Unless you're transporting my body (ie, airline, ride share, etc), then I really don't need you to be looking out for my safety. See the problem is: when you do look out for my safety, you do it by giving yourself control over my life that is not healthy for either of us.
Let my safety be my concern, and the functionality of your product can be your top priority.
>This is why we announced this change early: to gather input and ensure our solutions are balanced.
Sounds like just trying to save face, they didn't have a language of "we're only _MAYBE_ stopping everyone from installing non-verified apps" back then. They were quite adamant.
But happy that they're dropping the craziest part of this in any case. Won't stop me from investigating Graphene OS and other options when getting my next handset though, the previous move surely caused a jolt in my interest.
"We have realised that boiling the frog this fast will result in it jumping out of the water. Therefore we have slowed down, but remain steadfastly devoted to seeing this frog boiled"
Actual title is "Android developer verification: Early access starts now as we continue to build with your feedback"
Two key announcements:
> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
> We are using your input to shape a dedicated account type for students and hobbyists. This will allow you to distribute your creations to a limited number of devices without going through the full verification requirements.
The student/hobbyist account type will most likely literally only be useful for that strict purpose, i.e. very small-scale distribution to a known quantity of people.
I think it was mentioned somewhere else that that account type would require manually authorising each individual installation, so it'd still be useless for small freeware developers, who are only in it for the fun, too, but want to give away their software to everybody who might find it useful.
Doesn't it mean Google will collect the app ids of all installs on all devices whether they are signed into an account or not.
I'm not naive to think its not happening today, whats probably new is them admitting to it.
How long does it take them to use that info to drop ban hammer on the user accountd for using apps like newpipe and hide behind reasons like violation of TnCs.
Bold move from Google — finally admitting the Play Store has a trust problem.
Verification sounds great on paper, but if this turns into “prove you’re a real dev by jumping through 12 forms of bureaucracy,” it’ll just push more talent to sideloading and open platforms.
Still, if Google actually nails this — transparent, fair, and fast — it could be the first time in years Android feels safer without feeling locked down. That’d be a plot twist I’d love to see.
The current title of this submission is
> Google will allow users to sideload Android apps without verification
Which seems to be false. As far as I understand, Google still requires verification.
> Google will allow users to sideload Android apps without verification
Mercedes will allow drivers to carry passengers without verification.
Sounds silly, doesn't it?
> Google will allow users to sideload Android apps without verification
Ford will allow drivers to carry passengers without verification.
Sounds silly, doesn't it?
If 90% of passengers were scamming the drivers or hijacking the car for some nefarious purpose that affects other cars, you definitely wouldn't find that silly.
I would think it is pretty silly if I needed some sort of verification to drive people I personally know around because other people were getting their car hijacked after choosing to pick up strangers they found on the highway.
Security by obscurity. That's my device, that's my decision to install whatever I want.
I see here and there some comments about someone was scammed, etc… Lack of knowledge of users is not a good reason. They still will get scammed, in a different way, but outcome will be the same.
On PC one can install whatever want - and nobody is blaming OS for it.
Google is about to find out the next step of this chain - give access to everyone, don't gatekeep / do checks, and yet take responsibility for anything that goes wrong.
"You should open up the tool, put no restrictions, and yet ensure that it is safe and secure" is an impossible task for anyone.
How it was working till now for so many years, now suddenly can't?
because they put restrictions. now they cannot. because all the restrictions meant saying no to some legit things as well - inevitably. but then they got sued, laws got passed, to not be monopolistic, and still secure the users. this is the aspect of tech saying no when the thing being asked is impossible but people assume because they dont want to do it for whatever reason.
"Keeping users safe on Android is our top priority." This is propaganda. It is a statement made to dissuade people from the real issue. The top priority is to make money.
It is hard to to trust anyone who starts communication with an obvious falsehood. Users beware.
If it doesn't require a Google account and just means jumping through a bunch of hoops the first time, maybe requiring a USB cable, OK. If it does require a Google account, or won't let you give permission to F-Droid to install stuff, I call foul.
I will never use the term 'sideloading' for 'installing'.
"Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months."
So they haven't actually changed anything yet, but they say that they will "in the coming months."
That's because developer verification outside of Google Play isn't required yet.
Good job everybody, just don’t start complaining when your family members installed malware, their banking and health information is leaked, and you have to fix this for them.
> We are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified
I believe they will push responsability onto OEM.
Google's move is very good for the web. By pushing app makers away from walled platforms, you turn them to standardized, open ones such as the web.
Mobile is such a second class operating system platform. I look forward to doing everything with Meta eyewear that also corrects vision impairments.
This is great news to me. I'm going to celebrate it. As evil as everyone thinks they are, they did the right thing here. Thanks google.
Ahh yes,the slow boiling continues.
So if I want to release a free android game my options are.
A: Hope Google doesn't change course again.
B: Give Google a copy of my apartment lease,
Would be too hard for them to ya know actually implement sandboxing which would prevent this.
Anything aside from full bootloader access means I'm renting my device.
Too late now though.
I still remember when I could give my friends an exe of the stupid little games I made, worry free.
I guess that makes me a cybercriminal, doesn't it.
I can access any website or webapp without verification. I can install any app on my PC without verification.
I assume the results of my actions and I accept that if something bad is going to happen, it's my fault. I am fine with that.
I want the same kind of freedom on my phone, a device I own and I payed for with my own money. I am not smarter when using the PC and dumber when using the phone. I want to be able to opt out of verification and install whatever I want.
Don't know if I misunderstood your comment, but that's what the article is saying. You will be able to opt out of unverified app blocking.
how to make people forget about your bad practices
1) announce decision that will make everything even worse
2) wait for negative opinion
3) announce walking back on the decision
4) observe general sense of relief
The only way this can be stopped is to make it costly to even announce "decisions making everything worse"
If I install Android on a Raspberry PI do I still have this restriction?
Can I use FDroid?
You don't own that device you paid >$1000 for because google deems it so
Oh thank goodness, hopefully its implemented in a way thats not annoying for pro users
Southeast Asian scammers - they could've directly said from India/Pakistan.
They didn't say no changes. They are just saying we'll address the concerns of hobbyists and students.
Lets not celebrate prematurely and let us wait for more details on whats actually changing both technically and process wise. We should demand more clarity and should not wait to discover it after the implementation at which point it is hard and nearly impossible to push back against.
We don't want to be in a situation where they technically make it possible but make it practically impossible to install apps outside playstore.
I think you are correct. Clearly, they got spooked, but not enough to make full reversal. I am actually mildly optimistic. It has been a while since I saw a minority ( not that many people are aware of it outside HN circles ) shake a bigger company to a hesitation.
No thanks. When my apps stop working, I stop carrying your phone.
While we are at it, please also reject the framing of "sideloaded" apps. This framing pushes the use of legitimately installed, often high-quality, software to the periphery. This framing is an essential step in extinguishing our computing freedoms, as "sideloaded" apps are easily cast aside.
Recently I wanted to find a good app to manage my shopping lists as well as keep an ordering of this list so that I could run through the supermarket more efficiently. I really hate backtracking the supermarket to get some item on my list that I forgot was in a spot I'd already been. Of course, it had to work offline-first and I didn't mind a bit of configuration.
Everything on Google Play Store was some cloud-integrated garbage app. The only app that came even close was an app on F-droid called Aisleron, which lets you manage both your home stock and supermarkets in terms of "aisles" of products, flipping easily between what is in stock and what is needed and then managing an aisle-based sorting of these products per supermarket that I frequent.
Great App! However, I worry that this app would never have been released had Google considered actively blocking the author from creating legitimate and highly useful pieces of software like Aisleron.
Tying app distribution to a verified identity definitely raises the cost for scammers. But the devil's in the implementation. If "verification" ends up being too bureaucratic or expensive, it risks pushing legit indie devs and hobbyists away from the ecosystem entirely
We need Linux phones stat.
This monopolist dictates its demands. It's pretty outrageous behaviour from a company that has grown by parasitizing Internet infrastructure built with taxpayer money. That's how far you get by bribing every US politician. It's a banana republic, a fucking shit show.
The Tyranny of the Marginal User strikes again.
Over the long run this might help Android a lot
> his will allow you to distribute your creations to a limited number of devices without going through the full verification requirements.
Sorry, *allow*? ALLOW?
I'm sorry. My device. My software. My customer or friend. You don't have the right to insert yourself into the process. Very kind of you to ALLOW me to do something you have no involvement in whatsoever.
Like everything google do the real reason for the plan is to let google insert themselves unwanted into someone elses business so they can extract money from other people's work.
I would bin my android phone now if the alternatives weren't even worse,
I have been an Android fan-boy since 2010 (hello HTC Evo!). Blackberry until that. Never owned an iPhone until a month ago. There really is not a benefit to owning an Android smartphone anymore if they are going to knee-cap F-Droid.
Glad to see them being less evil.
Taking 10 steps in the direction of evil, and taking 1 step back, is not something that should save you from the gallows.
Especially when they're continuing on the next 10 steps ASAP.
So they can be less evil to more people rather than pushing people to a non-evil platform.
What is the non-evil phone platform? Aftermarket Android ROMs?
If they had gone ahead and blocked local installs, and forced every apk to be signed by a registered developer, I'm assuming there would have been a strong push for a viable Linux on these devices.
Sadly, less evil is still evil.
If everything’s completely open, it could lead to a higher rate of malware installs.
Imagine you could do with your hardware what you wanted. Brave. Innovative. Revolutionary.
/Old man laughing at "cloud" that is my baremetal.
I worry that the overton window has shifted so much after over a decade and a half of most downloads being mediated by "app stores" that most people don't realize or have the means to vocalize or understand what they're missing.
Now allow individuals to release apps again.
That blog post really downplays the issue that people have with the verification requirement and is tone-deaf. The resistance to get Google's blessing for app distribution is definitely not limited to students and hobbyists - and I don't think that's even the biggest affected group.
Sideloading? Really? So I'm not installing stuff on my phone, but sideloading... must be something illegal, isn't?
..does Valve wanna make a phone any time soon?
Great! Based on this, I would like to sign up to get early access to Android Developer Console (to distribute apps ONLY outside the Play store). The article explains that they will start sending out invitations to people on the waiting list.
But it does not say (or I can't find it) how to JOIN the waiting list. Does anyone know how?
I don't see in what world you would want to test this and help Google make this feature better, especially if you're doing it for free.
I have to admit I couldn't even understand this problem, because for me the "stock OS" is already unbearable and I'd simply never be able to use it - I've never used it for more than a hour..
The issue is that of network effects. Making it harder to sideload for example f-droid makes the already small market for it even smaller, leading to less apps. It also forces people developing Apps that they don't want to reveal to be developing for completly valid reasons (Imagine developing a porn app in saudi arabia or an abortion support app in the USA) to validate against google aka the US Government.
I'm just presenting my exotic point of view - since that developer verification would only be needed to run apps on the "stock OS" (which I consider bad), then deliberately excluding it could promote using LineageOS/GrapheneOS which would be a good thing.
But of course I'm talking about non-commercial apps, but commercial app developers would already be on Google Play.
Ask yourself how relevant and interesting you'd find this comment if someone else had posted it.
I'd agree because I'd feel the same :)
As to relevance to the article - I'm not cheering that much because if Google made "stock OS" even worse then maybe more users would flock to LineageOS/GrapheneOS which would be a great thing and make it harder to push Play Integrity.
i think your opinion is pretty dated.