Obviously you don't need an unlocked bootloader no matter how useful it'd be to unbrick when recovery dies (or a fixed build isn't available yet), to make sure the users won't say it's for nobody as it can't pass Play Integrity

https://developer.android.com/about/canary

https://www.reddit.com/r/NothingTech/comments/1lwqiob/nothing_phone_3a_camera_post_processing_adds_hair/

Usual stock camera experience.

If you find an issue with Nothing Phone 3 just because it's pricey and ugly, you're just a hater.

If you find an issue with Nothing Phone 3 because it's unergonomic, has a generic display, offers upper midrange cameras, entry level high-end SoC, the brand grifts off the "poweruser friendly" image and asks solid money for all of it despite the economies of scale, that's where it's at.

Pic

A phone stopped being usable because server said no :(
https://fixupx.com/developeruwu/status/1945021367939666004

(yes, I'm aware that you can probably bypass that in plentitude of ways, I just hope that activation mechanisms will be abandoned through an OTA whenever the servers stop handling them, but one could dream)

So Google already acknowledges the feasibility of proxying PIA results to/from (a good linguistic question...) vulnerable devices

To run an untouched (just kidding, the toggle in question and GP signing cause your app to be far from "untouched") original app enrolled into this unnecessary restriction, use:
pm disable com.your.app/com.pairip.licensecheck.LicenseContentProvider

https://github.com/pperez39/google-keys/

This repo is either a very high quality fake or Google's own leak of keyboxes they managed to obtain (not from themselves), divided into ones they decided to revoke and ones which they didn't. The details you can see in csv tables don't look like anything a third party would bother to catalogue.

Essentially, could say it's a mix of current state of revocations and a roadmap of future revocations.
It'd be exceptionally odd for any third party to mark the source of compromise in the level of details you can see in the csv, since it wouldn't really matter as long as you have a bunch of valid keyboxes around that would be obtained directly by you with no means of guessing how likely your gray market competitor would be to possess them.

Except using them to pass PIA, what can you do?
Simple: observe for their revocations and see how much longer the major OEM keys will stay unrevoked compared to B brands. What kind of conclusions or actions you'll take later is up to you.

https://github.com/RealJohnGalt/KeyBoxRevocationResearch/blob/master/keybox_check.txt

The tournament is started.

Deutsche Telekom released schizo ads targeted at gen Z that likely won't make them any money. I guess that's good.

https://youtube.com/watch?v=75nQs45HP50

(No, I'm not paid, I saw this ad on Reddit and it felt good to see an ad expected to be net negative for the business)

Fold 7 can't be bootloader unlocked, while running stable OneUI 8. Either they rushed it for the marketing points, making it equivalent to a beta (as other devices are still on beta, where they indeed aren't unlockable at this point in time) or Samsung is about to lose money on the people (including businesses) who'll move to Pixels, Nothing and OnePlus (not an exhaustive list).

The irony.
https://netzpolitik.org/2025/utiq-tracking-jetzt-auch-am-internetanschluss-zu-hause/

Still current news: you accept a cookie-like banner and then this gives a company the consent and capability to track you or your household (so with the accuracy of single contract) despite the IP changes because Deutsche Telekom tells them it's still you.

The watchful people who had internet in 2000s and early 2010s know that most of internet safety comes from not oversharing your personal details, and that presence of invasive know-your-customer practices by commercial entities is a major source of personal information leaks. But the topic of what we can do about it in technical aspect is rare.

One of the few things that remain alive in the current internet against all of the legal odds are torrents. And plenty of them thrive on DHT (distributed hash table), which is independent to trackers (predefined centralized servers that come and go).

A chat infra can be as sustainable. But people want reliability and low battery drain, okay, that can be done too. The biggest issue with distributed chat apps is narrow vision, a bet on a certain point in the decentralization spectrum. How many servers you need? What must motivate people to setup servers? What are the obligations of a server owner? What a server owner will have to accept? What's the impact of servers on their users?

Those are very serious questions with pretty long answers beyond the scope of this post. What I really want to say is that "zombies" are good. Chat app designs so invulnerable to politics and design flaws that a build from 2013 will still keep working for the few remaining users decade later. Yes, you can bet there's a known unpatched security flaw present at that point. But that is fine! Why? Because you can resurrect the project or the idea any day, but now do it better, because you'll be equipped with the answer to why it kept working for an unmaintained decade.

So what I propose? Design for both a tragic and thriving internet. If you can save battery on a mobile device, take advantage of it. If you can lessen the ping, take advantage of it. If you can enroll a user more easily into being a seed, if you can optimize for very large groups, please do. Just have a fallback for everything. The most obvious part (because it's stored offline) is self-sovereign identity. You're a public key and private key, not a username and password on a specific server. A lot can be done.

What I think we're missing the most? Actually, the attention. You can consider this post as a teaser for completely-no-ETA post that evaluates the UX and as much of what I can technically understand in various distributed chat projects. Some of them are exceptional at a thing or two and deserve a standing ovation for that. The recognition of individual qualities and number of users motivate developers and give them a better chance for funding.

A sign of potential unintentionality is that people actually report the devices locked themselves after the update to beta. Even in case of OEMs that offer no official means to unlock, taking an action against already unlocked units isn't something you hear about often. You don't want to mess with devices of people who followed a widely known documented behavior, that's a legal risk.