Ads and tracking, obviously (https://localmess.github.io/)

All these changes Google is doing to Android aren't for you as the user, they are to protect their business interests from the user.

Not just that. A non-development Android build will also prompt the user when a connection is made to authorize the client's key.

This once again isn't about security of users, this is about security of the company's interests.

When is this insanity going to stop? I really think the IT security industry ought to be ashamed of itself. Security has become a totalizing value that trumps every other value - convenience, user-friendliness, privacy, hackability, openness, just anything at all in the name of MORE SECURITY.

The introduction of Manifest V3 API in Chrome for extensions, and disabling Manifest V2 for security reasons. It just so happened that ad blockers were made incompatible with the Manifest V3 API. It's a little blatant considering this came right around the time that YouTube began showing warning messages to users with ad blockers...

Requiring developers to verify their apps via Google Play Developer Console and blocking any unverified APK installations. This is done in such a way that it just so happens to squash F-Droid and most FOSS apps for most people, and blocks any serious competition to Google Play or any apps they don't like.

Of course, there's all this talk about preventing malware, but it is a fact that if you download any random ringtone or PDF app on Google Play it's going to come with probably 25 trackers and send your data to every jurisdiction in the world, and many apps even fail to declare any of this via Google Play data safety or privacy policy. Let's not forget that spyware is a form of malware. Take a look at the leaderboard :) https://reports.exodus-privacy.eu.org/en/reports/list/?filte...

In my opinion, this would probably be an indication that maybe Google controls too much technology and that they may need to be broken up to ensure fair competition. For Christ's sake they almost broke up Microsoft not that long ago for shipping a browser with their operating system, and now Google is blatantly controlling the operating system, the platform and app store, the ecosystem, the browser, the ad network, and abusing their power over it however they can.

This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass (or even if another app did it).

But sure, Google evil.

Not saying it will be good or arrive anywhere in the next 5 years but they are very persistent and that tends to work in their favour.

"Changing between A and B requires a device reset."

Most people are going to flat out refuse to wipe their device for a phisher, especially since it'll log them out of everything and trigger all sorts of "new device on your account" warnings everywhere if it's done without their knowledge.

Sure, this is mildly annoying for the 1% that have good reason for A — but it's annoying once per device rather than losing A for good as is happening now. Sure, Google will deny service to A. They're doing that no matter what, either b/c they remove A or b/c they deny A, but this forces them to construct and defend a case for why users who went through the hassle of wiping their device to switch to A ought to be denied access to the app store, and that's a critically absent case in regulatory circles right now. (See also Graphene vs. the EU age check app.)

That's all it would take to protect B from A, but no one asks for it, and no one presses Google publicly for it, and so of course Google isn't doing it. No megacorp will help you walk off the Golden Path without some sort of extrinsic pressure. I see a great deal of clamor around wanting A, but absolutely none of the 'here's a mild annoyance that we came up with as a valid and safe compromise' clamor that would make them look incompetent in the public eye, provide further leverage for EU antitrust steps regarding Android itself, and give them a way to continue to protect users who need B for safety, while allowing those of us who want A to pursue it.

Perhaps other styles of compromise exist, too? As far as I can determine, no one else is thinking about this in terms of "what compromises will developers offer that continue to protect non-developers?", and so I have no other examples to offer. I'd sure love to see more ideas, more effort invested into offering serious and real compromises rather than inflexible resistance of every real safety improvement.

It doesn't get better even if you pay 2500$, which is extra silly.

and google is doing all they can to try shut it down, because they saw how profitable a walled garden like iOS really is.

It's just that few people bother using it. But that number might increase if Android continues it's war against its users.

And why should modern corpo maintain additional complexity to pander to 1% of privacy-aware tech-savvy users?

Even if there was a way to install your own software, there's no point in doing so. You're "tampering" with the device. Fail attestation and you're untrusted. You get banned from everything. If you hack, you're ostracized from digital society. You're a second class citizen. Can't communicate. Can't bank. Can't stream. Can't play video games. Can't do pretty much anything.

That's the future of Android. GrapheneOS is quite literally the last hope for Android, and only because by some miracle there are companies out there who started trusting Graphene's attestation keys. If that hope ever dies then we might as well buy iPhones.

This is not even Google's mindset, the control strings of this mindset stretch far beyond its management and board of directors.

That's the OBEY from the timeless Carpenter's classic.

You mean the new recaptcha that requires remote attestation?

https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...

Obviously, it doesn't have the fee part. But Google can decide soon for a substantial number of websites which devices can visit them and which not.

You would have the "new web" consisting of the top n major websites paying this fee.

And then you would have the "old web", accessible only to people still owning their own PCs with unrestricted browsers. And probably heavily scrapped by AI companies to reguritate to the masses through the new web.

You don't have to pay a fee directly, but you can't use open source web browsers.

Not everyone has the same threat model as you, $BIGTECHCORP.

I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.

(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

and conveniently, google now has access to your photo, the meta data, and potentially able to scan it for advertising purposes.

I personally don't have a problem with a mediocre-performance phone but it should not be expensive. Not to mention app ecosystems - there aren't a lot of Linux apps for Linux phones.

as long as such personal freedoms gives users the ability to skirt the profit motives of companies making these devices, there will always be a force to try restrict it.

The internet, as it has been, is quite an anomaly, but inevitably, power that the people have gets usurped one way or another. It's just a matter of time.

Can you install your own OS? If yes, you own it. And Google consistently lets you do that. It other OEMs don't then direct your outrage at them.

I think there's a difference between criticism of a policy and being brigaded by a reddit mob.

Google does take feedback from app developers every now and then, but obviously their own teams' feelings on the subject are more important to them than some open source developers relying on a hack like in this article.

I think it should be quite obvious that the ADB daemon wasn't designed to enable call recording from an app initiating an adb session over a loopback address. https://xkcd.com/1172/ strikes again.

That doesn't mean the developer who wrote this is wrong to dislike the change: Google themselves have added call recording to their dialer a while ago so it's clearly a feature they stand behind. That doesn't mean the adb team shouldn't do a little security hardening, though.

We don't need anything to completely capture the market, it has to be just enough to make Google hesitate or make it hard for Google to do it for legal reasons. Like how Firefox is ideally supposed to be for Chrome.

edit: I not realizing that I been replying to wrong comment

That said, I wasn't under the impression kimwolf was that technically sophisticated. Some of the others are, though.

See Pournelle's Iron Law of Bureaucracy.

Where Android/iPhone users have "apps", I mostly end up writing small shell scripts around existing linux tools. My alarm clock "app" is realized via cron jobs; my TOTP "app" is a one-liner around `oathtool`.

Messenger apps are a bit tricky; I'll probably end up hosting my own matrix homeserver and then have bridges running for Signal and the likes.

It's not an anomaly, it was the data grabbing infrastructure, and now that enough data is vacuumed in from it to train AI, it is now time to turn this dangerously conductive communication network into a control-only one, by all logic of the process and those who funded it all the way.

Our company also uses Revolut business, but that requires a phone app to verify online payments with cards. And Revolut recently changed the app so it now requires Google Play Integrity so it doesn't work with LineageOS anymore. So I'm looking to move all new things away from Revolut. I have little patience with companies that want to unbank my company, and decide what hardware or software we use.

https://ec.europa.eu/commission/presscorner/detail/fr/qanda_...

Require payment services providers to ensure that all users can benefit from methods to perform SCA which are adapted to their needs and situations and, in particular, that those methods do not depend on one single technology, device or mechanism, for instance on the possession of a smartphone.

But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?

1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times

2. Enable USB ADB debugging in the Developer Options

3. Establish an actual USB ADB session

4. Enable TCP/IP ADB debugging in the Developer Options

5. Unknowingly download a malware app from the official Play Store

6. Blindly click "Yes" on the permission prompt.

In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. And it only works if the Play Store is useless at preventing malware in the first place - but I thought their excellent app scanning was the entire reasoning behind all-but-banning 3rd-party app stores and sideloading???

It is "for safety" in the same sense that governments banning all encryption is to "protect the children" or to "prevent terrorism": flawed justification invented to distract from the real reason they want it.

Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being against the original proposal possibly restricting non-loopback access, which would enhance security.

Or perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.

I think a possibility of knowingly pushing the handlebar should be removed from me, just in case. After all I could do it.

And while we're at it I just realised my car has a similar vulnerability, but triggered by a slightly different mechanism, but the effect is exactly the same, I can crash into a pillar.

Edit: oops, I just discovered that if I have a banking app installed on my phone, then tap my screen in the specific places, enter several numbers, including the number I receive in text, suddenly I lose all the money.

That's staggering!

[1] https://www.reuters.com/world/eu-top-court-dismisses-google-...

The CVE mentioned in the article is https://nvd.nist.gov/vuln/detail/CVE-2026-0073. That's a real CVE: logic error leading to auth bypass. Fix can be seen at https://android.googlesource.com/platform/packages/modules/a....

Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does not appear to share that view.

Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?

Same in Norway.

There are hundreds of millions of outdated Android devices that all Google attestation systems consider secure even though they all running Linux kernel that was never ever updated and can be rooted by anything.

Now try to install your own firmware on them without said outdated kernel... How dare you.

I bank with HSBC in the UK and there's still branches (worldwide) and banking via web.

I assume you mean things like Starling and Monzo in this case? Banking with them is simply dangerous.

Like, if security was a concern we would have simpler systems and still use 2fa devices for banks etc.

If you are talking about allowing listening on localhost - remote ADB requires enabling in the developer settings. It is a developer feature, similar to ADB over USB. If I'm charitable, it is possible that they are seeing too many people that are using Shizuku without understanding the security implications. But Shizuku has a lot of useful applications and they use ADB because the Android APIs and permission system are lacking and do not make these applications possible.

It depends on how you define a bad actor.

"rootless privacy tools based on Shizuku."

It's not for the security of the owner; it is for the security of the government.

Trusted execution environment applications like the EU Digital (Identity) Wallet, or whatever they will demand next to protect the children, heavily rely on the fact that users cannot mess with their devices or install unsanctioned software. We all know how badly the Intel SGX story is going.

For the popular apps you mention, there is Waydroid to run Android apps.

Google is really stretching their goodwill with this one. The ability to sideload and debug my phone is the only marginal benefit to these janky Java relics. If that's gone, no reason not to switch to a wholely better platform.

I'm not quite sure why they don't support something like a yubikey with FIDO, but maybe there's a good reason.

But it helps against account sharing, err I mean they make database leaks irrelevant except for private info of the customer, err I mean that we can now send more mail to the customer about new AI features without risking they think it is phishing, err I mean this is the easiest measure for the auditor findings so since we implemented this we don't need to fix all the crappy internal api auth problems and atrocious out of date dependencies, err I mean...

I'm not saying it's right to respond by simply locking everything down, but let's not downplay the blast radius of basically every attack that involves telling the user to do things.

Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about.

I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps.

There are legitimate security reasons here. Whether there are reasons beyond that is an open question.

A measure needs to be in proportion to the actual risk it seeks to mitigate.

Along the lines of "Are you being asked to do this by someone else? Be cautious, as your device could become compromised."

The US should.

https://synthient.com/blog/a-broken-system-fueling-botnets

There are 3 things which I feel like are being confused here:

1. There was a genuine authentication bypass vulnerability in ADB (bad)

2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)

3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)

[1] https://nvd.nist.gov/vuln/detail/CVE-2026-0073

[2] https://issuetracker.google.com/issues/526109803#comment1

[3] https://issuetracker.google.com/issues/526109803#comment3

This was proposed by a Google employee: https://issuetracker.google.com/issues/526109803#comment3

In early days of this, I honestly think it was rooted in the famous Steve Jobs paranoia, the one that shipped without an app store and told users to use Safari, the same Steve Jobs that was said to not want certain medical devices during cancer treatment to touch him because they weren't beautifully designed. It was fundamentally about not wanting "dirty" things coming in contact with his "perfect" device. They dressed it up in language about security as a post hoc justification.

I remember in those days people would say they didn't want it to be like malware ridden Windows 98. But they omitted the weak security behind Windows at that time, which modern systems had long ago exceeded, even in the Windows world.

That use-case was never designed for when the sensor was added, and is every bit as hacky and fun as adding call recording with a loopbakc address

And that's the first problem: Android is no longer fun, and it's no longer for trying this hilariously stupid hacky method of doing what we, the users, want.

The second problem is an attitude of "Google's dialer has it built-in, why would one want a third-party dialer instead of Google's?"

Because we fucking can - or could, at least. The OS was designed to be as modular as possible, to the point where, while iOS still can't change their launcher, Android has had that option since day one. Setting aside Google casting themselves as the (not so) benevolent dictator of "Just use our apps exclusively. Life will be easier that way", closing off the modularity is antithecal to the Android experience that so many geeks fell in love with, and arguably made the platform what it is

GNU/Linux phones already exist. Sent from my Librem 5.

Sidenote: The poster in that article is insane to me. Imagine advertising yourself as the only alternative. I'd rather vote for an empty seat than for someone who's that arrogant! Then again, I don't really have to imagine it, since there have been quite a few politicians within the last 10 years who have functionally done that same, just without actually saying those words out loud.

Arguably it would be highly preferable compared to the option of not being able to use them at all.

Reminds me of what Ubiquiti tried to pull a few weeks ago. They wanted to force everyone to their Cloud UI and login instead of the local interfaces so they reduced the local session lifetime to something insane like 20 minutes while lying to our faces and saying it is for security, and kept the session lifetime longer on their cloud panels. They made sure to exclude this from their changelog too.

The community started monkey patching their local scripts, wrote services to undo their changes, many people disabled auto-updates as Ubiquiti only makes their product worse with their updates. Publicly complained on their support forum that we are onto their little plot.

They ended up backtracking for now but you just know they will try again like Google does.

Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0). Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1) And without developers pouring tens of thousands of work hours into making projects such as GrapheneOS viable despite Google, you wouldn't even be able to do much that requires anything to do with SafetyNet and all successors delivered through Google Play Services, which is functionally the core component of any Android device for the near entirety of typical use-cases. And I'm not excusing OEMs, but they did not build their market share off of being "open" then start to close every door and trap you in it.

0. https://www.fitzsim.org/blog/?p=545

1. https://www.eff.org/deeplinks/2026/07/googles-new-remote-att...

Apple has had this feature for three years on iOS. What else should they have done?

To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick your phone, etc.

[1] https://play.google.com/store/apps/details?id=com.google.and...

https://en.wikipedia.org/wiki/Mozilla_Foundation#Financing

Here is a better question:

"Is the EU going to stop this?"

So you won't be able to use your banking apps, your local transport app, public services apps, health services apps, etc.

But sure, you can do SMS (no RCS though), use the device calculator, and maybe browse the Web… until websites kick you out because your non Chrome/Safari browser isn't supported anymore. Even Signal won't work well due to the lack of FCM.

And I'm a GrapheneOS user happy with Obtainium and without Play Services installed in main user space.

Like iPhone idle auto-reboot every 3 days. After a while they added "Allow Idle Reboot" flag but it only accessible via MDM and require device wipe and for switching it to be a managed device.

I've been getting by with a bankid codebrick and web browser access (although Nordea and DNB apps work fine on GrapheneOS).

I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.

Is it an open standard that anyone can permissionlessly implement?

When the answer is yes, there is a high probability that it's something reasonable, e.g. TOTP.

When the answer is no, what you will find behind the curtain is either a fool or a crook.

Sure, there are differences in types criticisms, but then try to actually articulate those and address whatever you think the issues with those are

Most of the users who saw the post on reddit didn't even open the blog post anyways, according to analytics.

Of course this isn’t true, the play store, and yes even the apple App Store to a lesser extent, is riddled with malware.

But what this demonstrates is that, clearly, Google doesn’t care too much about security or safety. It’s a pretense, not a goal. If it was a goal, they’d dump money into fixing the play store, but they won’t and they don’t.

So, we should be highly skeptical when they say something is for “safety” and “security”. At this point, it’s a lot like saying something is for “national security”.

That radius would be negligible should the things that must remain secret remain offline.

But no, that's a luddite thing to even think about in an all-connected ever-online world where even wiping one's ass is done via of a swarm of dedicated apps.

On the other hand, there has always been a way to extract secrets from a granny via a mere voice call, so no amount of dumbing it down would really help.

Apple can do the same for iPhones. In terms of dark shit they can do there's no difference anymore.

Not that I trust a device running Android enough to do banking, mind you.

oookay? Hardly seems like a big deal? It would indeed be nice if the unlocked phones were set from the factory as such instead of all being the same system image as the ones that locked carriers use, sure, but hardly significant since it's not like you have to sign in or anything?

> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)

Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.

Are any commercial mobile phone vendors not able to do such a thing? Do remember that this giant kerfuffle is all over the seeming preparation for the apparent removal of a developer feature that iPhones have never had at all.

Yes, that is what I meant. They should be hesitant to lockdown completely and (grudgingly even) allow alternative options and/or workarounds due to legal concerns like anti-trust.

Firefox was existing before Chrome, but in this case we either need a different OS or need an android based option like Graphene/3rd party stores gain enough marketshare to trigger anti-competitive laws.

Only things attestation do is security theater and messing up people ability to use software of their choosing.

FWIW, similar kinds of attacks is exactly why side-loading apps is about to require a reboot and 24 hour cooldown. Which you mention at the end. It sucks, but it's a decent compromise; power users like me will just do the dance and pick the "indefinite" option the moment they unpack their new phone, and rest of the people will never even know about it until they're half-way through being scammed.

I personally don't believe doing anything more in this direction is warranted.

What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough?

>Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)

Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.

I think the impulse for an OS vendor to try to make such mistakes impossible is about as wrong as selling knives dull so people can't hurt themselves. A knife that can't cut its user is useless as a knife.

You are free to install a custom OS which provides you the security model you desire. You have choices.

Use an AOSP fork like grapheneos or lineageos. Barring that, voting with their wallets and buying a HarmonyOS phone. If for whatever reason they're doing that too, there's probably more powerful forces behind this change (eg. government mandates) that won't be helped by spamming an issue tracker.

And both are banks I'd never want to associate with. I would have used Sbanken before the DNB buyout (and I even did for a bit!), but now that's of the table too.

There are a few more options, but many are just worse if you look at their fees and interest rates.

I've been very happy with Bulder. The only thing they're missing is a web portal. The fact that they're missing that annoys me greatly, but they've been good to me in every single other aspect, so it's hard to be dissatisfied (especially compared to the other banks where I and others have been burned). Their app works fine on de-Googled Android, and so long as that's true, I can live with my choices.

We could also imagine a 24h delay to get Play Store access with a modal to make them understand the risks.

No technology prevents the crash, they just lower the chance of it happening accidentally (like, say, ABS or DCT). I can remove almost all of the guardrails on my bike choosing more aggressive riding mode.

Countermeasures to the accidentally allowing a malware to "do something" already exist and were described in the original article. The comment I was responding to wants a removal of the whole capability, hence my cases.

>Which OEM do not provide this feature? This hardly quality as a legitimate usecase but rather as a shortcoming of the OEM.

I find this kind of attitude maddening. Although I assume they overlooked "advanced" because as soon as I read that, I knew this wasn't going to be something ever supported as a basic functionality. I get that many people will be fine with simple things but I hate being forced into them.

This kind of comment is frequently made on HN and elsewhere. However, more than a few "elderly parents" are as computer-sophisticated as their grown children. A safe bet it's not rare to be exchanging ideas with an elderly person sophisticated enough to make comments on HN.

AFAIK there's no shortage of careless, uninformed, non-elderly individuals who get scammed into doing stupid things. Age is only one possible factor out of many contributing to scam vulnerability. And let us not forget that youthful, well-trained professional IT workers, developers and software engineers are not immune to scams via misunderstanding elements of the systems or processes they supervise.

"Ageism" is a word as ugly as what it signifies.

This is actually a feature, very common in real world, that security maximalists keep insisting is a bug.

It is tech feudalism - you don't own anything anymore, you just get to live on the digital land of a bunch of ~trillion dollar companies.

At least, that is the goal.

IMO either everyone gets access at the user's discretion or Google has to sandbox their own GMS services as well.

Which incidentally is often just a pretense for other motives?

If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)

Then the judge pretty much decided “no consequences”.

https://www.cloudflare.com/learning/ddos/glossary/aisuru-kim...

This is like saying that SSH is insecure because some device vendors install SSH, permitting root login with a default password of 'root'.

Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".

- the app embedding the proxyware SDK for money

- the proxy operators

- the attackers/botnets using the proxy to access ADB.

The botnet has no access to the app, so it can't show any messages.

The app can show messages, but probably has no connection to the botnet. (I hope)

The proxy operators could show a message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.

It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.

> Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface wlan0 ?

Nowhere in that text do I see a proposal to assign an additional CVE for this behaviour. Personally I think it would be unusual to assign a CVE for intended-but-potentially-harmful functionality, although I expect people have done that in the past. But, I think overall we're agreeing here.

Now an application on my computer can obtain root without user interaction.

Where is my CVE?

"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.

"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.

Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.

You are forgetting the most important questions of security, without which the whole discussion becomes pointless:

Who is securing what, and from who?

CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.

This is one of them

It depends on a remote endpoint that can go down at any point, and depends on the company's policies present and future. It is functionally asking for permission to another party to unlock it, and that would not fall under the umbrella of ownership through being able to install "my own OS" on it, at least for me. And a simple OTA update is all it takes to add multiple verification steps to it, such as providing your ID/using your verified Google account, or just take it out.

Your example is about one developer's decision, which is not really what we're talking about. The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store? We're talking about restrictions laid down by the OS developer and for iding all applications outside of their crappy walled garden, which is very different. Also, you don't actually think Google is going to stop there do you? They will certainly turn it off one day of they think they can get away with it, because it is in their financial self-interests to do so.

It puts iPhone in cold boot state if for instance police or any agency confiscate it from you. Better tamper proofing.

It's easy enough to imagine that Google is trying to fix something they see as a problem, and not caring about the developer case rather than specifically seeking to destroy it.

When Apple fixed security issues that allowed for jailbreaking, they weren't doing it specifically because people use it for jailbreaking, they were doing it because it was a security issue.

We should have 100% control of our own devices. But we should have it by design, in a fashion that makes sure that we control them rather than other people.

  Quod licet Iovi, non licet bovi

Something like, "I'm worried about impairing Google's ability to compete in AI" or some nonsense. (Paraphrasing here.)

Looks like all it takes to compete in AI is to issue stock or get a bunch of investors. I don't see how Google would struggle with that. It's completely orthogonal to antitrust enforcement.

> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.

Patch: https://android.googlesource.com/platform/packages/modules/a...

Docs:

> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.

The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.

Here's my article about that from 2021. It's for the devices sold in Russia, but this issue is worldwide: https://habr.com/ru/articles/575626/

And here's more detailed research of two particular devices: https://notes.valdikss.org.ru/trojan-digma/

I mean, this seems more like one of the root causes for a lot of bad things in the industry me...

Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.

Too far towards trying to make mistakes impossible (which is easy for corporations to talk themselves into because it also makes them money and moat) and you make devices useless. Too far towards full user control and you get difficulties in support and security issues (which are tractable if you’re an enthusiast, but not so much if you’re a normie on a corporate-maintained device).

Truthseeking here is further complicated by ordinary end users’ dislikes and usability issues not always overlapping.

I'm an immigrant and most banks refused to give me an account when I moved here. Or ghosted me during the months long process. These are the banks that let me live here, and actually gave me an account and bank id. It's the only real choice I have until I get citizenship.

What’s worrying is that noone protests about it

It doesn’t suprise me that corporations and governments want the laziest, most „protective” laws passed that extend their power. But why noone, absolutely noone puts some kind of resistance to it?

Government and citizens are at eternal conflict of interests. It has been this way and it will be this way forever.

Your job as a citizen is to make sure you have greatest amount of liberties

Noone will do it for you.

If vendors use updates to restrict functionality that the user had before, puts existing features behind paywalls, etc. people are rightfully outraged, because it breaks the social contract.

It's just that the repeated offenses have made us insensitive. Imagine Debian rolling out some mechanism that only allows you to install software outside their repos with a 24 hour delay. It would destroy Debian.

"we will never ask for this over the phone" takes second place to:

"we will send/save you money/time if you make it convenient"

dress it up to taste like developer needs, and you can hook the newbies.

Also, the original sin: framing it as "security" vs. "convenience". It's not. The other end of the spectrum is utility - as in, maximally secure computing device is an inert rock. More security means less utility - reduced functionality, constrained capability, reasonable use cases no longer possible. It means manual process where previously automation or batching was possible. It means more electricity, more compute, more money spent.

It means more user time and therefore more human lives wasted.

This ultimate non-renewable resource is what we're trading off when we accept even more security. This trade-off needs to be respected much more than it is.

That's why I use GrapheneOS.

Who is doing the securing, whose interests are being secured, and against who/what?

Security isn't an unqualified good thing to have. It's just an instrument of control. Who wields it and how are the paramount questions. You can have an "open standard that anyone can permissionlessly implement", aimed at protecting interest of third parties, by securing the device from its actual owner. In fact, that describes many, if not most, security measures introduced in computing over the past 20 years, especially on the web and mobile devices.

People seem to be ok with needing a license to operate a motor vehicle and those are far less dangerous.

Nothing is stopping the guy at Walmart or Tmobile from selling them dumbphones, or are you implying they are forced to?

It's one more revenue stream to be able to remote control real android phones to pass device attestation checks etc.

It's marketed to users with phrases like "earn money from your phone whilst you sleep".

Your problem is with the last one which has nothing to do with the CVE itself.

That's why Trump's tariffs on everything was so ... Uh ... "Interesting". If only one party gets the tariffs, you end up with other parties selling the goods instead, which does cause meaningful damage to the tariffed party

“Large numbers of people will uncritically follow sketchy instructions and get hacked” doesn’t in any way lead to “and therefore they cannot be trusted with devices”.

“People keep dying in auto accidents” doesn’t imply “ban cars” on the first order, it implies “seat belts and airbags”.

Whether that means there's a _feature_ lacking there, is another question.

Is it? Many games outsource their anticheat to a third party developer, similar to how many apps outsource their app security to play integrity.

>The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store?

What about (nearly) all the games that only support windows, and worse yet, are exclusives on one distribution platform? Yes, there's wine/proton and cracks, but that's a "solution" in the same way that using a modded apk to get past the play integrity requirements is a "solution".

I'm sure you meant "wary". How amazing, education really does work. There is such a thing as overabundance of caution. But it's possible further education could encourage users to apply more balanced caution policies.

There's no reason the banks should be dicks about it, but they often are in cases like yours. All the accounts I've opened in recent times have just been a matter of logging in with BankID and going through the form and selecting 'no' 10 times. Once you've got BankID and can go through the automated flow, there shouldn't really ever be any issues.

This is why it bothers me greatly that BankID is still controlled by the banks, since they can just decide that someone like you shouldn't get it. It should be government issued and issued to everyone, on the same level as an ID card or a passport.

--

[0] - Which I find deeply ironic, in that merely a decade ago, people would laugh at Windows with its "reboot after installs, reboot in case of problems" approach, and now frequent reboots are seen as Standard Security and Stability Practice on *nix systems, both mobile and server-bound...

Sounds worthless (in court).

You can unlock it with additional free option.

allow [intransitive verb]: to make a possibility

https://www.merriam-webster.com/dictionary/allow

So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.

That, and security maximalism displayed in 3. and some comments in the HN thread.

Here is the first iPhone ad:

https://www.youtube.com/watch?v=6Bvfs4ai5XU

The ad depicts it as a mere phone instead of a potentially hostile Turing machine. There is equivalent messaging in the android ecosystem but its advertising is not so ubiquitous.

And even when they are required, it's up to the person using the stairs to determine whether they wish to elect to use the handrail or not.

[1]: IRC R311.7.8

I don’t think that kind of stupidity warrants respect.

That’s not what’s happening. Here you have security used as an excuse for vendor lock ins. Just like AI is used as an excuse for layoffs. But you shouldn’t confuse actual security with BS like this.

Literally no one in security thinks this.

How do you know? We're not allowed to see the source code.

Doesn't help that the banks then do, in fact, call you, and ask for this over the phone.

It’s not like that anymore in my experience at least but the stigma stuck.

If the user chooses to free certain apps from restrictions, that should be their choice.

But if a piece of software overrides the users' choice, that certainly qualifies as a CVE.

This is an important distinction! The user must always have final say.

Whether an app breaks out of the sandbox and steals my vacation photos, or the OS sets new restrictions I can't remove, both are wrong.

Any piece of software has to act in service of the user, and ONLY the user. It must not do things or set restrictions without the users consent. No means no.

2. There's no real disadvantage to leaving your bootloader in "locked (unlockable)"[1] state, because you can continue using stock rom and avb is enforced, but you can unlock it at any point using fastboot.

3. The Bandcamp analogy still applies because it offers streaming too (ie. web player), which means you could be happily streaming (ie. not downloading) and then one day they shut down, denying you access to all your music.

[1] https://i.ytimg.com/vi/rh6JxG0xE2k/maxresdefault.jpg

Also telling that advertising and locking down devices are driven by the same companies...

in my region AT&T has a very explicit statement not to reveal MFA codes to anyone who asks, is not part of thier system to do that.

there is 1 bank in my area that does voice call relay over the phone, the others keep it 10 fingers relayed from phone to authentication form.

guess who has the most problems with account compromise, and fraud claims? yes, that one bank. it has a phishing vector in its system.

Stop trying to flatten the human experience, Harrison Bergeron style.

The phrase "the user doesn't have to know if this is on his computer or the cloud" has done a lot of harm to the software ecosystem.

For 30% of transactions with the EU it’s just the US shooting itself in the foot and passing on higher costs to average Americans.

Imagine enacting a tax where 30% of the money collected was a net negative. I can’t think of many taxes that are that poorly constructed.

For the 70% of transactions where US companies and individuals decide to buy less or use alternative sources, doesn’t that at some point harm US businesses? At the very least you’re now artificially lowering competition, which tends to drive overall prices up and quality down.