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.
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.
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.
I think Google is trying to solve the problem at the wrong level - people do not really understand their computing devices enough to understand the risks, they never had to learn or were taught how to use such devices, they were only told it's easy and to not ask questions. The interfaces are designed in a way that allows them to get by with almost no understanding of anything. Which is why such solutions may also be bypassed by a determined attacker. Such scams only really expose this fact. So there is no good way to differentiate between the two groups.
My solution is educating about smartphones and computers first. Not in an in-depth way, but people need to understand what "application", "verified" means and what are the risks. I think android cleaned up the abstraction enough to make this possible.
Being able to tell if an app came from a trusted company or not is a good thing, but I would rather such a solution be managed in an OS-independent way, not controlled by Google. Applications not authenticated by a company should not be second-tier citizens, but there should be a clear warning (and the users should already know the difference before even seeing this warning).
I think the scams and phishing also expose another important problem that nobody tried to tackle yet - you can't authenticate calls, sms messages or emails. There is no good way of telling if it's actually your bank calling you, or if it's just a scammer.
In the end, we also need to accept that not all scams can be prevented, at some point if someone is calling as a friend of your family member, and is asking to urgently transfer money to an unknown account, and you fall for this... I really can't think of a technological measure that would've helped, it's only you and your common sense.
> My solution is educating about smartphones and computers first.
98% of people literally do not care and/or are too dumb to understand. You could force them at gunpoint to sit in the education class, and give them a simple basic quiz afterwards, and they'd get half the answers wrong. They will continue to not even read what's on their screen, and just click the big highlighted button every time they see one.
Yet somehow they are not too dumb to get a driving license or operate a gas stove. I would argue that operating a car is much more complicated than operating a smartphone.
At some point, if you are unwilling to learn basic facts about your environment, and you don't have a guardian, then you will get hurt. I don't necessarily mean by a computer. I think that's fine and I don't think a patronizing solution by a corporation that clearly wants more control over society is a necessary help.
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.
I've been experimenting with their controller for k8s runners https://github.com/actions/actions-runner-controller. The awful thing about it is that you cannot run one set for all projects unless they're all under an organisation, so for normal accounts you need to provision one runner set per project.
We used to run Gitlab Premium for around 300 users running hundreds of jobs over some monorepos. Gitlab suggested a small architecture using Omnibus, and while it helped a bit, it didn't perform as well under load as we expected it to.
Eventually, there was no virtual scaling that could help. This, for me, is the biggest problem with Gitlab hosting: as soon as you hit a scale where a single machine with Omnibus doesn't cut it, the jump in complexity, cost, and engineering hours is significant.
Omnibus is like entry level. We paid for GitLab Professional Services and they recommended going to the larger architecture. Since then, we haven’t had issues.
They have their free fast stats tool and you can run your logs through their tool to get statistics and identify hotspots
Maybe yes but also maybe not. Intra-european travel can be cheap but it can also be expensive. You can take a Ryanair flight and a local train to stay somewhere cheap for a couple days. But you can also take a expensive Lufthansa flight to stay in a big city where costs can be similar or higher to where where you are. It will always depend of where you are and where you'd like to go to.
My impression is that nowadays the UK has more cheap flight options than the rest of Europe and that trains aren't as cheap as they used to be a decade ago.
We’re reaching out to let you know that your organization is currently on the legacy HCP Terraform Free plan. This plan will reach end-of-life (EOL) on March 31, 2026. After this date, the plan will no longer be supported.
To keep using your organization without interruption, please sign up for a current HCP Terraform plan and migrate your existing organization before March 31, 2026
One sidenote is that the Twilio part is harder than it looks. Not because of technical factors, but because of the paid requirement. Twilio refused to take my money and upgrade me to a paid account, even though they forced me to go to their confusing KYC procedure, where they asked me many times to provide the same set of documents. Support was useless, it looked like an AI bot repeating the same thing, but this was before the widespread usage of AI bots.
Eventually I gave up and went to Telnyx, which had a better KYC process and actual humans behind support that could resolve any quirks with KYC. Apparently not being born where you live breaks a lot of the automation behind some of these processes, go figure.
I'm not sure if they've changed the process since your issues (hopefully) - I was using their trial and when it expired had to go through the KYC process. They under-promised by saying two working days to reach out, but everything was wrapped up within an hour and done over email.
I nearly moved away from Twilio having read the negative feedback, but my personal experience so far was very prompt support.
Hey, that's good to hear. Was it a recent experience for you? Maybe they heard some of the feedback and acted on it.
This encourages me to revisit them, not because I'm unhappy with my current provider, but rather because Twilio offers what I need (a number that can receive and send SMS) in regions where my current provider doesn't.
I ought to caveat that from a KYC perspective, I likely would have been 'easy' since my career history involves many well-known companies and the requested account was for a UK company that has been running for nearly 20 years.
Though I'm no longer personally in the UK. Microsoft on the other hand: It was impossible for me to open up an Azure account even with their Customer Support. Suspect I will have to use Tailscale to bypass overly rigid geographical controls.
I also use this guide, but I switched it to PostgreSQL instead. The recent upgrade to Trixie brought a new Dovecot with breaking changes to its configuration. That was a bit of a pain to resolve, but everything is working fine now.
I wonder how this will play out in the phones coming out of the Motorola+GrapheneOS partnership.