The "protective waiting period" of 24h is what kills it. For people like me, who rely more and more every day on OSS apps not necessarily in the Play Store, installing a new phone will mean waiting a full day for almighty Google to allow me to do so. It reminds me of the same annoyance of carrier phone unlocks.
I wonder how this will play out in the phones coming out of the Motorola+GrapheneOS partnership.
I'm genuinely interested in proposals for other ways to differentiate knowledgeable users enabling side loading for reasons like OSS, vs naive users enabling it at the instruction of scammers to install malware.
The one time per device (not per app/install) is annoying, but seems like a reasonable tradeoff between preventing bad installs and allowing legit installs. I can't think of any obviously better ways.
I realise some disagree with the entire premise. I think refusing to accept the reason given doesn't advance the discussion though and I am very interested in what a better experience that is trying to solve the same problems could look like.
If you can get someone to do all these steps, you can get someone to wait 24 hours as well.
We use Android based devices internally with apps which aren't signed. I've had way too much trouble with Google flagging an internal app as problematic and then getting no where with Google "support" when we still used Google play.
The 24 hour wait is especially problematic because we often simply factory reset a device and preload it of there is any form of trouble.
This is just a power grab to lock down the ecosystem more. And ironically this seems to because of the Epic lawsuit. Google is now aligning with the absolute minimum they saw Apple needed to implement.
This was never about safety. It was all about control. Desktop OSes have always allow installing any softwares and the world is still spinning. Not even macos overreach this hard.
There's no solutions because they specifically crafted the problem to not be solvable. No amount of compromises will stop them from advancing further.
There's no way this is really about scammers. I have never heard of scammers pushing sideloaded apps upon their victims in order to carry out their scams.
Would welcome evidence to the contrary. Is this truly a threat model that's seen in the wild?
My gut says no because social engineering is about hijacking legitimate, first-party processes. Scammers attack login credentials, MFA flows, and use first-party apps to maintain access (think remote control software like TeamViewer). These apps come from the Play Store, not from meticulously curated collections like F-Droid, and not from somebody pressuring you to sideload an APK.
And if scammers decide to use sideloading as an attack vector -- then like all the other security gates that can be defeated via social engineering, I expect they will find an end-run around this one as well. Either on a technical basis, or by social-engineering users into bumbling past it and on to the next stage of the scam.
Build an idiot-proof system and society will build a better idiot. And yeah, the rest of us only wind up slightly annoyed, _for now_, until Google tightens their grip further on some other flimsy pretext.
>There's no way this is really about scammers. I have never heard of scammers pushing sideloaded apps upon their victims in order to carry out their scams.
I also never got targeted by pig butchering scams[1], and neither did my immediate friends/family, so I guess those must not exist either?
You don’t need malicious apps for this, it’s common to use real crypto exchanges and get them to send you money. How does google’s approach solve that?
And here are apps straight from the App Store [0] that are outright scams. How dos this protect people from these?
No, it is not. This is moving the goalposts. The original issue is developer verification. No appreciable harm prevention can or will come from forcing devs to identify themselves.
That's because most fraud uses social tactics and LEGITIMATE tools/software.
Impinging on my property rights cannot and will not protect fraud victims.
Although I'm slightly relieved there is a way out of Googles verification system, it's still pretty wild if you compare this to installing software on a Windows pc. I'm sure Microsoft is heading in the same direction with Windows, but today its still "only" a few confirmations to install anything.
This will sadly still put a major damper on adoption of open source apps, while giving a false sense of security that apps from the Play store are safe.
Years down the road, the low usage of apps installed from outside the Play store will be used as an argument for removing the functionality completely.
There's an interesting subset of Windows machines out there running in "S" mode [1]. This mode restricts the customer to only using applications from the Windows Store.
We get occasional support tickets about the popups that come when trying to run a regular installer while in this mode. Luckily, people can disable "S" mode, but there's no way to re-enable "S" mode without a fresh install.
Apple has been doing it for years not allowing "unsigned" software to be installed using the same "for the safety of the user" even against the user's wishes.
Whether it's essential or not is up to the user, who should be able to load whatever operating system they want (enabling them to bypass the restriction) on their bootloader-unlockable device.
Why should the bootloader come locked? That's restricting freedom isn't it by preventing those without a few minutes to unlock it from having true freedom.
I'm not sure how an unlockable bootloader that comes locked and a signed and verified software only that can be unlocked is actually fundamentally different.
It'd be nice if they put a little sticker on the box or a flashing warning when you go to buy the phone noting that you'll be unable to use it as you desire for 24 hours if you are not willing to bend over to your corporate overlord.
Alternatives like GrapheneOS and Lineage are the way to go for right now, but I worry as things get more and more locked down that those options won't work with a lot of apps.
> I worry as things get more and more locked down that those options won't work with a lot of apps
I am increasingly interested in a dual-prong approach of building a parallel world of OSS apps, platforms, etc, plus an adversarial inter-op project for duping and wrapping apps/services from the commercial/normie world. We have some solid bases with Android/Graphene, Linux more broadly, wine, and Android VMs like Waydroid. Even if things don't get a lot of users, if the users it has are highly technical on average things can probably chug along.
Yeah, I do hope that an "inter-op" idea can be possible, otherwise anyone who doesn't want to join the duopoly fully will slowly be unable to interact with more and more aspects of commerce, government, etc. I guess the GrapheneOS method of integrating Play Services but keeping the user in control (e.g., being able to block Play apps' internet connections) is something like that, but ultimately it's controlled by Google and there are problems with Play Integrity, meaning some things just don't work.
People already have the choice between an ecosystem that offers the safety of a walled garden and one that allows the freedom to do anything you like, including shooting yourself in the foot.
Google's decision to walk back the supposed freedom to run anything you like removes user choice from the marketplace and harms consumers.
Maybe if the Jolla folks were serious about making inroads in the market for personal mobile devices that they're ostensibly trying to compete in. But they're just as deluded and as doomed as their Meego/Maemo/Moblin predecessors about the value proposition that the SDKs and system software they ship has with the market segment they're targeting.
The "protective waiting period" of 24h is what kills it. For people like me, who rely more and more every day on OSS apps not necessarily in the Play Store, installing a new phone will mean waiting a full day for almighty Google to allow me to do so. It reminds me of the same annoyance of carrier phone unlocks.
I wonder how this will play out in the phones coming out of the Motorola+GrapheneOS partnership.
I'm genuinely interested in proposals for other ways to differentiate knowledgeable users enabling side loading for reasons like OSS, vs naive users enabling it at the instruction of scammers to install malware.
The one time per device (not per app/install) is annoying, but seems like a reasonable tradeoff between preventing bad installs and allowing legit installs. I can't think of any obviously better ways.
I realise some disagree with the entire premise. I think refusing to accept the reason given doesn't advance the discussion though and I am very interested in what a better experience that is trying to solve the same problems could look like.
If you can get someone to do all these steps, you can get someone to wait 24 hours as well.
We use Android based devices internally with apps which aren't signed. I've had way too much trouble with Google flagging an internal app as problematic and then getting no where with Google "support" when we still used Google play.
The 24 hour wait is especially problematic because we often simply factory reset a device and preload it of there is any form of trouble.
This is just a power grab to lock down the ecosystem more. And ironically this seems to because of the Epic lawsuit. Google is now aligning with the absolute minimum they saw Apple needed to implement.
This was never about safety. It was all about control. Desktop OSes have always allow installing any softwares and the world is still spinning. Not even macos overreach this hard.
There's no solutions because they specifically crafted the problem to not be solvable. No amount of compromises will stop them from advancing further.
A minuscule amount of nerds being slightly annoyed is definitely worth when it hinders scammers from ruining a persons live.
There's no way this is really about scammers. I have never heard of scammers pushing sideloaded apps upon their victims in order to carry out their scams.
Would welcome evidence to the contrary. Is this truly a threat model that's seen in the wild?
My gut says no because social engineering is about hijacking legitimate, first-party processes. Scammers attack login credentials, MFA flows, and use first-party apps to maintain access (think remote control software like TeamViewer). These apps come from the Play Store, not from meticulously curated collections like F-Droid, and not from somebody pressuring you to sideload an APK.
And if scammers decide to use sideloading as an attack vector -- then like all the other security gates that can be defeated via social engineering, I expect they will find an end-run around this one as well. Either on a technical basis, or by social-engineering users into bumbling past it and on to the next stage of the scam.
Build an idiot-proof system and society will build a better idiot. And yeah, the rest of us only wind up slightly annoyed, _for now_, until Google tightens their grip further on some other flimsy pretext.
>There's no way this is really about scammers. I have never heard of scammers pushing sideloaded apps upon their victims in order to carry out their scams.
I also never got targeted by pig butchering scams[1], and neither did my immediate friends/family, so I guess those must not exist either?
[1] https://en.wikipedia.org/wiki/Pig_butchering_scam
You don’t need malicious apps for this, it’s common to use real crypto exchanges and get them to send you money. How does google’s approach solve that?
And here are apps straight from the App Store [0] that are outright scams. How dos this protect people from these?
[0]: https://arstechnica.com/information-technology/2023/02/pig-b...
It won't make a dent in scammers' revenue.
No, it is not. This is moving the goalposts. The original issue is developer verification. No appreciable harm prevention can or will come from forcing devs to identify themselves.
That's because most fraud uses social tactics and LEGITIMATE tools/software.
Impinging on my property rights cannot and will not protect fraud victims.
Although I'm slightly relieved there is a way out of Googles verification system, it's still pretty wild if you compare this to installing software on a Windows pc. I'm sure Microsoft is heading in the same direction with Windows, but today its still "only" a few confirmations to install anything.
This will sadly still put a major damper on adoption of open source apps, while giving a false sense of security that apps from the Play store are safe.
Years down the road, the low usage of apps installed from outside the Play store will be used as an argument for removing the functionality completely.
There's an interesting subset of Windows machines out there running in "S" mode [1]. This mode restricts the customer to only using applications from the Windows Store.
We get occasional support tickets about the popups that come when trying to run a regular installer while in this mode. Luckily, people can disable "S" mode, but there's no way to re-enable "S" mode without a fresh install.
1: https://support.microsoft.com/en-us/windows/switching-out-of...
Apple has been doing it for years not allowing "unsigned" software to be installed using the same "for the safety of the user" even against the user's wishes.
And they should remain the outlier.
Significantly more discussion here: https://news.ycombinator.com/item?id=47442690
'Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.' - Benjamin Franklin
Sure, but what's "essential"?
Being able to decide yourself the software that is allowed to run on the hardware you own.
But you have that ability. There's a one-off 24 hour wait.
You have a similar wait if you get it shipped to you from Amazon.
Is the instant gratification essential?
Whether it's essential or not is up to the user, who should be able to load whatever operating system they want (enabling them to bypass the restriction) on their bootloader-unlockable device.
Why should the bootloader come locked? That's restricting freedom isn't it by preventing those without a few minutes to unlock it from having true freedom.
I'm not sure how an unlockable bootloader that comes locked and a signed and verified software only that can be unlocked is actually fundamentally different.
It'd be nice if they put a little sticker on the box or a flashing warning when you go to buy the phone noting that you'll be unable to use it as you desire for 24 hours if you are not willing to bend over to your corporate overlord.
Alternatives like GrapheneOS and Lineage are the way to go for right now, but I worry as things get more and more locked down that those options won't work with a lot of apps.
> I worry as things get more and more locked down that those options won't work with a lot of apps
I am increasingly interested in a dual-prong approach of building a parallel world of OSS apps, platforms, etc, plus an adversarial inter-op project for duping and wrapping apps/services from the commercial/normie world. We have some solid bases with Android/Graphene, Linux more broadly, wine, and Android VMs like Waydroid. Even if things don't get a lot of users, if the users it has are highly technical on average things can probably chug along.
Yeah, I do hope that an "inter-op" idea can be possible, otherwise anyone who doesn't want to join the duopoly fully will slowly be unable to interact with more and more aspects of commerce, government, etc. I guess the GrapheneOS method of integrating Play Services but keeping the user in control (e.g., being able to block Play apps' internet connections) is something like that, but ultimately it's controlled by Google and there are problems with Play Integrity, meaning some things just don't work.
But you're not balancing anything, just saying that you are
People already have the choice between an ecosystem that offers the safety of a walled garden and one that allows the freedom to do anything you like, including shooting yourself in the foot.
Google's decision to walk back the supposed freedom to run anything you like removes user choice from the marketplace and harms consumers.
SailfishOS / Jolla are unlikely to do this. Time to switch. Google's monopoly power over android is showing, badly.
Maybe if the Jolla folks were serious about making inroads in the market for personal mobile devices that they're ostensibly trying to compete in. But they're just as deluded and as doomed as their Meego/Maemo/Moblin predecessors about the value proposition that the SDKs and system software they ship has with the market segment they're targeting.