BTW if you don't wanna hear about my personal crap, go follow @VentralDigital where it's kept strictly technical✌️

New model benchmark: Animated SVG finger flick.

.@ChatGPT don't do that, that's weird

if, as alleged, TornadoCash was a money services business (MSB), the only real coherent theory is that the unincorporated association of relayers comprised that MSB (they are the only ones who arguably "accepted and transmitted value")...if so, then Chainanalysis, as a relayer, was much more clearly engaged in that MSB than Roman (who did not even run a relayer, merely owned ethereum:0x77777feddddffc19ff86db637967013e6c6a116c )...that's why they pled the 5th...but it shows this whole trial is a farce, @DonaldTrump @JDVance please save this man from unjust trial and imprisonment for software development...

I see that people are now happily connecting their gmail to Grok Bot, made by the people who did Grok Build, which uploaded users' entire private git repositories.

This paper is inaccurate slop. It makes a large number of clearly inaccurate claims about GrapheneOS and presents results which are verifiably false. It's filled with nonsense which appears AI generated. > The Clone Strikes Back: Efficient Vulnerable Code Detection in Custom Android-based Systems The authors wrongly believe GrapheneOS has diverged from the Android Open Source Project (AOSP). The starting point for GrapheneOS is the latest stable release of AOSP with all of the AOSP security backport commits applied. Our changes to AOSP repositories are maintained as cleanly rebased patches. Our AOSP changes are reviewed and improved on an ongoing basis. It's not only the code being improved but also commit structure. We're always preparing for porting to the next stable release. It's handled as if our AOSP changes are being prepared for submission to the project for the first time. We start fresh with each stable release of AOSP. All our changes are ported to the new source tree. There's no merging process but rather porting and submitting the changes to the new source tree. Major changes are often required including entirely rewriting certain features for the new release. This entire paper is based around a misconception. The authors wrongly believe we need to identify and incorporate all of the upstream changes into GrapheneOS. It's our changes we need to make sure to fully and correctly port to each new release of AOSP, not the other way around as they believe. The authors should have seen that each of releases has all of our changes to AOSP repositories cleanly rebased on top of the latest stable release. We do make substantial changes to AOSP but it can all be reviewed as a set of patches applied on top of the latest AOSP release with zero merge commits. Android Security Bulletins are a list privacy and security patches backported to older releases of the OS. These aren't the privacy and security fixes made in the development branch but rather incomplete backports. Far more fixes made in the development branch and the approach is often different. Android's development branch can do major refactoring and rewrites. It can make privacy and security improvements requiring substantial changes to the code. It can fix weaknesses requiring backwards incompatible changes. The backports don't even attempt to cover Low and Moderate severity patches. The authors of the paper took the diffs from the Android Security Bulletins and created tooling to look for the changes made by those diffs being missing. They present the findings where they manually confirmed lines of code don't appear to be present as if those are missing patches in GrapheneOS. They should have easily figured out GrapheneOS releases are based on the latest AOSP release. They should have used their tooling on AOSP itself as a control. They would have gotten the same results for AOSP and GrapheneOS if they used versions from the same date. Instead, they're misleading people. If they checked the latest AOSP release at the time, they would have seen there's no actual difference in what their tooling finds between AOSP and GrapheneOS. The code they identified as not present in GrapheneOS wasn't in the latest AOSP release at the time. It also doesn't show anything is wrong. Many of the security issues fixed by Android for older releases aren't present in recent releases due to rewrites and changes to the code. Fixes in the development branch are often difficult to backport with major changes or entirely different approaches being needed. Backports are their own thing. It's common for the initial attempt at fixing a privacy and security issue to be incomplete or incorrect. These changes sometimes even introduce new vulnerabilities. There are often multiple rounds of partial fixes. Truly fixing it often requires major changes or rewrites impractical to backport. This paper is built around an incorrect understanding of how GrapheneOS is based on AOSP and Android's security patches. All of the patches included in Android at the time were shipped by GrapheneOS. If any of what they found was an actual issue, which is doubtful, then it was missing in AOSP too. Aside from the incorrect premise and methodology, the paper is filled with many other inaccurate claims about GrapheneOS. Look at this example: > For instance, GrapheneOS eliminates unnecessary background processes and applies exploit-hardening techniques to reduce CPU and battery usage. Did a human truly write that sentence? We aren't aware of any background processes we've eliminated compared to AOSP. Our exploit protections certainly don't reduce CPU, memory or battery usage. We do take great care to minimize the overhead and provide toggles for features with a substantial cost. The paper is filled with statements which sound reasonable to non-experts but are nonsense. We wouldn't be surprised if most of the paper and code was LLM generated. There are many strong signs of it and it's hard to believe humans wrote all of this. We think it should be investigated further. There are 4 authors listed for this. The person listed 3rd is a Senior Research Scientist in the Platforms Security and Privacy team at Google. It's published as part of the 2026 IEEE 11th European Symposium on Security and Privacy (EuroS&P). What happened here? computer.org/csdl/proceeding… Google published Android as an open source project and it succeeded based on it. For years, they've been engaging in illegal anti-competitive tactics to gain control over what was an open platform supposedly governed by a group of companies rather than Google. That includes the Play Integrity API. Play Integrity API is pushed based on the false premise that it's a security feature. In reality, it's a core pillar of an illegal anti-competitive business model and clearly harms security. It bans GrapheneOS despite it being far more secure than anything they certify including far better patching. This paper pushes Google's false narrative of alternatives to Google certified Android not providing standard patches and protections. A Google researcher being directly involved as an author is scandalous. The claims made by the paper about GrapheneOS are clearly false and it needs to be retracted. The paper links to a GitHub repository with code, data and a copy of the paper. It's strange they apparently never thought to run this against the AOSP release which the GrapheneOS release they tested was based on. There are 0 differences in most of the relevant code... github.com/Demeter2025/Andro…

Watching the World Cup has reinforced my intense hatred for "Smart TVs". Just give me Program Prev/Next, let me select an input and leave me alone

Inter Profile Sharing can continue working on Android 17, if you want it to.

Android 17: *blocks local loopback network communication between user profiles* ...binding a port in one profile blocks it from being bound in another profile... Someone hold my beer while I turn this side channel into a comm protocol

New Agent benchmark discovered: Give agent access to Linux kernel code and a device's hardware it can freely flash and reboot. Tell it to rewrite hardware drivers from scratch in assembly until it succeeds controlling hardware. It's been circling for hours...

To protect me from the scrolling algos I now get a daily X/Twitter digest. LLMs, despite being considered summarization machines, are unfortunately still not very good at picking out what is actually important. Also, I'm already craving that sweet scrolling dopamine.

LLMs are terrible at technical writing I ran codex and claude on a rooted phone with a weakened kernel and had them look for RCEs into the subsystem firmware for a couple weeks Then asked them to turn their notes into technical writeups resulting in verbose, unfocused prattling

Running out of space on my old backup disk... rediscovering some gems from the old days, being like "ah yeah... that thing, completely forgot I still had it" That RAT remover I wrote in 2007 after infecting myself on accident... That time I reported every imaginable security issue in a CMS some German company made until they gave up on it in 2009... Those notes on all the security issues I found in random Swiss websites (no idea why, but they where the most fun targets back then)... That multi-gigabytes malware database someone send to me via mail from a university in 2011... That flyff mmorpg webGL clone I started writing in 2014... That browsergame exploit I started using after GM insisted it's not a bug... my old PHP webshell collection... Pre GPT, pre social media dominance, pre bug bounty... stack overflow, vbulletin forums, and mails warning me about being sued... Honestly, I miss the times where we just did cool stuff in small communities without algorithms dictating whether we can see each other's cool stuff... Anyone else storing old pearls for nostalgic throwbacks?

GrapheneOS dropped some very cool information on my thread here. Twitter isn't really showing it, so here it is: