James Cassell

Create an XFS filesystem of a particular size, smaller than the device: mkfs.xfs -d size=50g /dev/sdx1 There's (count them) nine different size= options for mkfs.xfs...

On iOS and macOS, WhatsApp stores chat databases unencrypted in an app group container accessible to apps from the same developer. So all Meta apps on the same iPhone (e.g., Facebook) can read WA chats in plaintext without permission, and users wouldn't be notified. Demo👇

Someone buy me some of these, I need them for... projects.

First-sale doctrine is one of the oldest property rights in the common law. You buy a book, it is yours. Lend it, resell it, will it to your kids, burn it in the yard, keep it for fifty years. The seller loses all say the moment money changes hands. Federal law flipped that on its head for anything digital. Every ebook you buy ships wrapped in a lock, and DMCA Section 1201 makes breaking that lock a crime, even on books you paid for. The state did not simply fail to protect your property. The state wrote the statute that criminalizes defending it. Let people own what they buy.

Greatest productivity hack of all time, never mind privacy

Announcing reposurgeon release 5.7 Your system package manager probably knows this as 'reposurgeon' A tool for editing version-control repository history. reposurgeon enables risky operations that version-control systems don't want to let you do, such as editing past comments and metadata and removing commits. It works with any version control system that can export and import git fast-import streams, including git, hg, fossil, bzr, brz, darcs, mtn, bk, and RCS. There is import-only support for svn, CVS, and SCCS. In particular this tool can be used to script the production of very high-quality conversions from Subversion to any VCS with write support. New in this release: Documentation polishing. Build recipe cleanup. Forward-port to Kommandant 0.7.0 Housekeeping release. No new feattures or bugfixes, just keeping current with Kommandant. gitlab.com/esr/reposurgeon

A fresh install of GrapheneOS has far lower idle power usage than the stock Pixel OS. Power usage while active is comparable. Making a similar setup to the stock Pixel OS by installing sandboxed Google Play and a couple dozen apps doing a bit of background work will result in similar battery life. GrapheneOS doesn't come doesn't come with anything keeping open a push connection and barely has any scheduled work. Waking every 8 hours for update checks doesn't use significant power. It doesn't have better battery life due to any major efficiency improvements but rather the lack of bloatware. Installing sandboxed Google Play on GrapheneOS results in having a push connection for Firebase Cloud Messaging and doing a lot more work in the background. Idle power usage will still tend to be better than the stock Pixel OS, but adding more apps to match their bloatware will make it comparable. Battery life heavily varies based on apps, networks and OS configuration. Many people end up with far better battery life on GrapheneOS and many people end up with far worse battery life due to differences in how they set up their devices. It's easy to end up with either result with simple choices. Play Store policy coerces apps into using Firebase Cloud Messaging for push messaging including push notifications. Having every app sharing the same push connection is very efficient. Multiple push connections are inherently less efficient and many implementations of this aren't power efficient. Installing Signal in a profile without sandboxed Google Play and granting the power optimization exception it requests is enough to destroy battery life and end up worse than the stock Pixel OS. The power efficient choices are either using Molly with UnifiedPush (Signal fork) or Signal with FCM. Running both sandboxed Google Play and an efficient UnifiedPush app can have competitive battery life with the stock Pixel OS. Those should be the only 1-2 battery optimization exceptions for most users. Signal's fallback push will drain more power than all the bloatware in the stock OS itself. On a Google Mobile Services OS, Play services is built into the OS as a highly privileged component with immense access and handles work across profiles. Sandboxed Google Play are regular sandboxed apps without any special access. Each installation in a separate profile is entirely independent. Setting up a work profile, Private Space and secondary user on the stock Pixel OS results in all 3 secondary profiles using the global Play services instance running in the Owner user for a shared FCM push connection, etc. Installing sandboxed Google Play in 4 profiles would run 4 FCM connections. Network-based location is much more power efficient than the power hungry GNSS radio for satellite-based location. Maps/navigation apps will continuously use both when available but many apps will avoid using GNSS to save power if network-based location is available, so it can save a lot of power. For GrapheneOS, network-based location is an opt-in feature in the Owner user setup. For Google Mobile Services Android, it's opt-out there and you'll be regularly nagged to enable it if you didn't. It's a common pitfall since people expect indoor location positioning and it can save a bit of power. Cellular, Wi-Fi and Bluetooth are power hungry. 5G is particularly power hungry prior to the improved cellular radio in 9th/10th gen Pixels with the exception of the Pixel 9a. Either way, setting the cellular mode to 4G (meaning 4G and below) or the GrapheneOS 4G-only mode can save a lot of power. Stock Pixel OS has an Adaptive Connectivity service which largely keeps 5G disabled. GrapheneOS doesn't have an equivalent to this yet but you can do it manually. Other than that, the stock Pixel OS doesn't really have any significant power saving tricks and it has a lot of bloatware draining power.

I never thought I would see the day where I would consider KeePassXC/DX yet here we are

@mackenzieprice If it takes more than an hour to finish a lesson, such as with some of the science lessons, you can get to the end and have it not register your completion and have to click thru the lesson again due to a session timeout. Overall, it's very high friction

@mackenzieprice Most parts of the lessons have "read to me" but the voice is an awful robotic one that's very hard to focus on. You can't go back within a lesson, but if your session times out or browser crashes, you're forced to start the lesson over again.

Two questions I get all the time: "What educational AI tools would you recommend for my kid?" "What adaptive apps does Alpha use?" Many of the apps we've built ourselves aren't publicly accessible yet. Here are ten third-party ones I do recommend.

Google's claims are that this is about security, but this change affects those using hardened & secure operating systems. Convenient for Google is that this will likely prevent people from using hardware and software not approved by Big Tech. Maybe too convenient... 7/7

Google is no longer asking "are you a human?", they're asking "are you running our proprietary background services and phoning home?" Anyone adding the latest reCAPTCHA to their site is now implementing exclusionary gatekeeping by default, probably without realizing it. 4/7

This is the clarity we've been crying out for. But it's a poisoned chalice. This is a 10X cut to claude -p disguised as a monthly bonus. Anthropic is discouraging any kind of programmatic usage. And that's fine - no subsidy lasts forever. But it's time to try Codex.

I can't help but feel personally burned by the Claude Code changes announced today. We put so much work into wrapping the (atrocious) Claude Agent SDK in T3 Code. It was the ONLY path they supported, so we made it work. It was hell. Now our users are getting their rate limits cut by 40x, despite us doing everything right. I listened to the Claude Code team. I had my issues with their direction, but I trusted them and took them at their word. I will never make that mistake again. Until we see significant change, it is safe to assume any statement from an Anthropic employee is a lie on a timer. The rug will be pulled, no matter how many promises are made beforehand.

"Play Integrity" is nothing but a tool used by Google to limit freedom of users & adoption of competitors. It provides no security benefits, and in fact makes security worse by limiting the usage of applications to proven less-secure operating systems.

Something interesting you might not have realized: A number of words in English are NOUNS when you stress the FIRST syllable... But VERBS when you stress the SECOND syllable. -SUSpect/susPECT -CONflict/conFLICT -PROtest/proTEST -CONvert/conVERT

A new VPN leak that allows any app to leak traffic outside the VPN tunnel has recently been discovered by @cybaqkebm Read more here: mullvad.net/blog/any-app-o…

Money shot: “Services shouldn't ban people from using arbitrary hardware and operating systems in the first place. Google's security excuse is clearly bogus when they permit devices with no patches for 10 years… It's for enforcing their monopolies via GMS licensing, that's all.”

GrapheneOS isn't vulnerable to the 3 recently disclosed Linux kernel vulnerabilities named Copy Fail, Copy Fail 2 and Dirty Frag. Current Android Open Source Project SELinux policies block exploiting all 3 bugs. Standard AOSP GKI kernel configuration also has 2/3 of the vulnerable features disabled. Attack surface reduction via fine-grained SELinux policy rules and stripping out unused kernel features via kernel configuration goes a long way to protecting against vulnerabilities. There's also seccomp-bpf for various standard sandboxes but most of the attack surface reduction is via SELinux. AOSP uses SELinux to allowlist ioctl commands for drivers, permitted socket types, etc. in a fine-grained way. It strictly controls a lot of functionality prone to vulnerabilities including user namespaces and io_uring which aren't allowed to be used by apps or nearly any of the base OS processes. These kinds of issues are rare and attack surface reduction is the best way to defend against them. GrapheneOS does additional kernel attack surface reduction but in these 3 cases it's enough to have modern AOSP GKI kernel and SELinux policies. We also greatly improve generic exploit protections. Local privilege escalation vulnerabilities in the Linux kernel are very common. However, the vast majority are memory corruption bugs rather than these memory-related logic errors. We defend against the memory corruption bugs with hardware memory tagging, zero-on-free and similar generic defenses. Linux has a massive amount of code for the core kernel and drivers for the hardware. All of the code runs with full privileges with no isolation. In a microkernel, each of these 3 recent vulnerabilities would have been in isolated processes. Virtualization will have a major role in addressing this. Despite these not being traditional memory corruption, a memory safe language with a better type system would definitely help. Containing low-level handling of memory to a much smaller portion of the kernel and mostly using safe abstractions for networking, device drivers, etc. would help a lot. Linux has a relentless flood of severe memory corruption bugs being discovered. Nearly all exploit chains for Linux-based systems by commercial and government exploit developers use Linux kernel memory corruption bugs. It's a lot harder to make very portable and reliable exploits for those bugs. A lot can be done to further reduce Linux kernel attack surface in GrapheneOS and much better generic memory corruption exploit protections can also be developed. However, it clearly needs to be replaced. Hardware-based virtualization on smartphones keeps getting better and has a major role to play.

I actually want my OS to sync to a cloud account so it doesn't bug me that Windows requires one. But it really shouldn't require one. They need to undo that. From a pragmatic perspective I know it holds you back and there are certain solutions you can't deliver but that's fine. The user just opts out of those things. I just don't understand who is in charge at Microsoft. I want to believe Satya cares but actions speak louder than words and the actions show that revenue is more important than customer. We need CEOs right now that have a purpose. The CEOs that listen to Wall Street will destroy their company.