Then the judge pretty much decided “no consequences”.

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.

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.

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)

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

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.

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.

> 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.

>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.

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.

"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

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

Where is my CVE?

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.

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.

Security is not an unqualified good. It's just mechanism of control.

Can you permanently apply chain3 (FIREWALL_CHAIN_OEM_DENY_3) firewall rules, so that when the device reboots these are still applied? I see no persistence. And if I'm forced to install some crappy app on-the-go, the solution you propose is to always carry a computer with me, right?

> A second phone does the same thing.

So does a Phonograph from 1877, right?

> Whether it's a "hack" is orthogonal to whether you control the device or not.

I didn't object to it being called a hack, I just pointed out how evil and malicious that privilege escalation on my own device is. Google must block it immediately, it endangers the mankind.

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.

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.