Try pi.dev. It’s also open source and works fast and without all those bells and whistles.

Good, young people are learning how internet works under the hood.

What are you guys getting from there? What kind of books/materials? Not to judge or spy on you (what a spy would say), but just genuinely curious.

And this is precisely why all such tools must be strictly open source and strictly using local models. So none of those fuckers would be able to influence anything I’m doing on my own machine.

Actual NFC payments (as well as security in general) are absolutely irrelevant to this attestation technology. NFC for payments works perfectly (and not by a bit less securely) without all this “security” circus — because NFC payments (and any other kind of banking or payments) is just a completely different thing.

The only thing that this kind of attestation does is proves to the app (in this example, a banking app), that the device it runs on has been deemed by the OEM (or Google in case of Play Integrity) as worthy.

And I specifically wrote it as “deemed as worthy” because it is exactly what it is: “deemed” doesn’t mean that it was certified or analysed for vulnerability or even properly updated, and “worthy” doesn’t mean that it’s actually secure or even capable to be secure.

This whole technology and the claims about its “security” is just a marketing scam that allows Google/OEMs to control your phone by ensuring that you’re not running some software not approved/sold by them specifically (e.g. GrapheneOS, LineageOS, PostmarketOS, your own Linux build, MS-DOS 6.11 — doesn’t matter) and for both the OEMs and the apps (banks in this case) to create a visibility of security without actually ensuring this security.

It doesn’t matter who controls the attestation “authority” — Google or random European companies — in the end this technology is still evil and even harmful for real security — by design.

Fuck Microslop and fuck Google.

It’s typical corporate marketing bullshit to cover up their real authoritarian censorship mechanism: https://keepandroidopen.org/

I think it sounds more correct like:

each non-technological[-company-owned] activity we participate in has become an act of micro-revolution.

There’s nothing wrong with the digital media or streaming technology on its own. It might be even more energy-efficient than some older technologies.

What’s wrong is that now the company X Y (sheesh, you can’t even use a random alphabet letter anymore without pointing right at one of them!) owns your whole music library, decides what to remove from there and what make you add there, and just by the way also casually sells your personal data and your habits to some other companies, that also decide for you what you should read/watch/listen to/buy.

So, basically, nothing useful.

I think this is exactly the win-win situation from this possible partnership: Motorola makes secure hardware and firmware patches, GrapheneOS takes care of the whole software security and timely updates (they already do).

Absolutely agree with this. Any age verification mechanism is always about censorship and control, not about helping kids. The only thing that helps kids is them being taken good care of and provided guidance at all levels: in the family, in the school, in the society. But that’s a deeper social problem and no one gives a damn about solving that problem.

Of course, not. The only thing that can protect kids is their parents taking proper care of them, not some spyware.

Fuck google.

To be fair, it’s worth noting that the majority (all?) of the flaws were found around organization management, SSO, vault sharing and compatibility features. All of which severely expand the attack surface of any password manager, and hence should be avoided like a plague.

Also worth noting that the actual whitepaper (also linked in the article) is much better written than the article, and it was an interesting and easily understandable read. Give it a go.

And thanks for sharing!

Yes, for small, especially non-IT businesses, it’s really hard. But thank you again for the article, I think we might (unfortunately) need such setup for different other things in the near future too.

There’s only one thing you can do: stop using it, stop giving them [an opportunity to use your data for] money. Everything other solution is mediocre at best. Thanks for sharing, though.

No, they’re just morons and sadists.

GMaps is horrible not only as a service that forces you to enable all their spyware technologies or lose most of the functionality, not only it’s hostile to any other mapping applications and makes it literally impossible to even copy the coordinates (I’m not even talking about converting links or using geo-uri’s), but even within itself it’s absolutely horrible for any non-car activity: hiking, walking, cycling, running, commuting — the UX of all that is absolutely abysmal.

So if you find a solution that works for you without GMaps (and preferably the one that contributes back to something like OSM), good for you, stick to that solution a forget that absolute garbage produced by Google.

No, the actual AI runs locally, on the phone. What MLKit does is two things:

1. Downloads the actual AI models from Google’s servers — not sure, but maybe they can be bundled or downloaded from other sources.

2. Send the usage analytics about those models — again, don’t remember exactly what’s being sent but the actual prompts/source images/model responses shouldn’t be sent in normal operation.

Why I highlighted the normal operation thing is because Google is kinda famous for collecting data it shouldn’t be collecting, e.g. read this README for example: https://github.com/PlqnK/magisk-supl-replacer

Not to bash them or something, but just FYI: I got interested in how they’ve implemented AI client-side, and they use Android MLKit in their Android app for that.

The problem with MLKit is that it phones back to… ta-dam!.. Google, even if it’s not actually used by the app, and that telemetry can’t be legally (and neither in any convenient and reliable way te technically) disabled, even by the app developer.

It doesn’t seem to be sending any sensitive information in that telemetry, but I don’t know Rick: changing Google for… Google?