An immutable OS install and app sandboxing by default provide a lot of security. Those are present on third-party Android distributions that don't pass SafetyNet. Some users of those add root access so they can let a handful of apps out of the sandbox, but I'm willing to bet most of those are tech experts with better security habits than the average person.
Show me examples of actual data breaches and account takeovers SafetyNet would have stopped if you really want to defend this position.
Safetynet was not a mistake; it was a lock-in mechanism. Widespread failure to call it out as such and oppose it as happened when Microsoft proposed something similar for PCs a decade earlier[0] was the mistake.
> will this mean we have to support one more standard, one more release channel, one more modified OS?
Android apps don't have to take any active steps to support third-party distributions. All they have to do is refrain from taking active stops to block them, but I suspect you knew that.
I'm convinced the Amazon Fire Phone was the motivation for SafetyNet.
The Fire Phone was a midrange Android phone from 2014 preloaded with Amazon's app store and services instead of Google's. It failed on its own merits, but I think Google got scared someone else would do a better job. The barrier to entry is a lot higher if most people can't use their banking app on it.
This isn't just a matter of lack of a good driver because they didn't bother making one for an OS they didn't intend to support. Encrypting the firmware's power table serves no purpose other than frustrating any third-party effort to develop a good driver.
It is not obvious to me why they would want to do that.
I remember being a young child when my parents were shopping for a car. I heard a radio ad for a car dealer claiming it was the best place to get a car, and I was excited to tell them.
I think that experience helped blunt the ability of ads to manipulate me ever since. I recognize, however that advertising has increased in sophistication, so I block ads pretty aggressively and try to avoid media that makes it impossible.
I've taken hundreds of flights in and between the USA and EU and never once had to show anyone my credit card. In a number of cases, the ticket was booked with someone else's credit card.
For (non-Schengen) international flights, I usually have to show someone my passport.
This is for getting tickets printed on the spot, not for using the already printed tickets. People buy tickets online and have it printed later at the airport/station kiosks, which lets you prove your identity abusing the fact that customers realistically don't forge a credit card. It can be an ID/password login at the busy station using unresponsive touchscreen, or a membership card of the airline/train, or maybe even a driver's license, but CC is probably the most convenient(unless...).
I've seen swiping the CC used to buy the ticket be an option for things like printing the tags for checked bags on a flight, but it's definitely never been a requirement.
The fact that a ticket bought online must be printed on paper at all seems anachronistic in 2026. I would expect, or at least hope for a QR code saved to a smartphone as the default.
Add Oceania to that. As long as I've been able to produce the proper passport(s) and visas for my journey I've been let on the plane, throughout all kinds of complex journeys.
I have had a round trip flight recently that involved two passports, a work visa, and an ETA, and a total of 5 layovers across 3 airlines. As long as I produced the correct identity documents at any given check in desk, I was allowed to board, without ever producing a credit card.
Didn't happen to me for a domestic flight with JAL recently. I was actually surprised how little they checked; just a QR code was sufficient (although my memory might be fuzzy due to the international flight just before it).
I'm disappointed that issue tracking inside the VCS (probably as a separate repository, or at least a special branch) never got popular. That would reduce the importance of web-based code forges and make moving between them easy.
I believe radicle.dev (another federated forge) does this,
> Radicle’s Collaborative Objects (COBs) provide Radicle’s social primitive. This enables features such as issues, discussions and code review to be implemented as Git objects. Developers can extend Radicle’s capabilities to build any kind of collaboration flow they see fit.
Yeah, Radicle feels closest to a "network extension for git", I hope it or something near to it wins out in the end but I think Tangled with its VC backing and defaultism "its like github, you visit tangled.sh" orientation means it will probably be more popular and eventually win out. I think we'll see sponsored "GITHUB DEAD???" youtube videos for Tangled, but not many for Radicle.
Radicle has some association with cryptocurrency, which is a bit ick to me, but as far as I understand it, it's actually a non-profit and the crypto was more of a grant than buy-in.
An immutable OS install and app sandboxing by default provide a lot of security. Those are present on third-party Android distributions that don't pass SafetyNet. Some users of those add root access so they can let a handful of apps out of the sandbox, but I'm willing to bet most of those are tech experts with better security habits than the average person.
Show me examples of actual data breaches and account takeovers SafetyNet would have stopped if you really want to defend this position.
reply