After months of quietly adding to it, the Tools directory on my site is at a point I'm willing to call v1. 125 tools across 46 categories. Everything here is something I actually recommend, evaluate, or point people toward. No affiliate links, no sponsorships, no pay-to-rank. Each entry is meant to help you compare options fast, see the tradeoffs, and pick something that fits a real threat model instead of a vibe. What it optimizes for: privacy by default, transparent security practices, day-to-day usability, and a strong fit for threat-model-driven choices. I know it isn't complete. That's the point of shipping v1. A few categories are thin and a couple are missing entirely, and I'd rather hear what you reach for than guess. So: what's the one tool you'd be annoyed to not find here? Project link below.

When the question is about your own medical data, the best model is the one running on your own machine. A cloud model usually reasons better. But the second you paste in symptoms, labs, prescriptions, scans, or insurance details, that stops being what matters. You want the model on your hardware. That's the case for MedGemma. Google's open medical model family, built on Gemma 3, running fully local through Ollama: ollama run medgemma:27b Watch the tag. Plain ollama run medgemma pulls the 4B, fine for light use. The 27B is ~17GB and wants a real GPU or 32GB unified memory, and that's where I'd start for serious medical Q&A. Both Ollama tags take text and images. A privacy-first frontend pointed at local Ollama keeps it local. And it's not a doctor. Google says so directly: not for diagnosis or treatment, and verify what it tells you. Use it to understand your results and ask sharper questions. Leave the diagnosis to a clinician. Skip "diagnose me." Try: explain what these values generally mean, list benign and serious possibilities, flag anything urgent, tell me what's missing and what to ask my doctor, and don't diagnose me.

@Brave grew to 117.56M Monthly Active Users (MAU) in May 2026. DAU grew 3.1%. 2nd best browser growth month in 2026. ATH new browser user volume. Spike in Android & iOS new U.S. browser installs following Google I/O 2026. Android DAU is back to record levels post-haircut. 1/4

Brave now has over 117 million monthly users! 🚀

It should NOT be this hard to buy a privacy-respecting car. Seriously. A car should be one of the simplest privacy relationships in modern life. You get in. You drive somewhere. The car moves you from point A to point B. That should be the whole relationship. Instead, the mainstream car market has become a swamp of telematics, driver scoring programs, mobile apps, dealer enrollments, remote diagnostics, insurance partnerships, location tracking, infotainment data, cameras, microphones, cloud accounts, and “connected” features nobody asked for. GM and OnStar are the canonical example of how bad this got. The FTC alleged that GM and OnStar collected, used, and sold precise geolocation and driving behavior data from millions of vehicles without consent. Consumer reporting agencies used that data to compile reports used by insurers to deny insurance and set rates. Why does a car need to report your driving habits to anyone just to do the one job it was built for? And from a security perspective, this is a nightmare. A connected car is a computer on wheels. A compromised car can expose far more than the vehicle itself. It can: - store paired phones, contacts, and call logs - keep navigation history and saved destinations - retain home and work addresses - hold garage door and gate codes - store app logins and driver profiles - retain payment or subscription data - report telematics back to the manufacturer - feed data into third-party systems, including insurers A modern car can log where you live, where you work, when you leave, when you come home, which routes you take, and which clinics, schools, churches, protests, hotels, or private homes you visit. That is a behavioral dossier. And unlike a laptop, people do not think of a car as something that needs a privacy audit. Used cars are worse. Assume the previous owner left behind Bluetooth pairings, contacts, saved destinations, garage codes, Wi-Fi settings, app sessions, toll tags, remote service subscriptions, and old driver profiles. Rental cars are worse still. People pair their phones, load contacts, use navigation, sign into apps, and then hand the car back like none of that data matters. One reason to be wary of any feature named “Smart Driver,” “Driving Score,” “Insure Connect,” or “Driver Feedback”: these can be the pipes to insurers. Driver scoring is the broader issue. Good intel on this is weirdly hard to come by.

Fresh PopOS install with @COSMIC_desktop. Brave Origin set as default.

If you've followed me for a while, you know I don't give OpenAI the benefit of the doubt on privacy. And personal finance is one of the last places I'd want to see weak defaults. Bank data reveals your income, debt, rent, medical bills, donations, subscriptions, travel, relationships, employer, habits, and vulnerabilities. In other words: it is a behavioral map of your life. OpenAI says this finance experience is read-only. The real risk is what happens when your financial context joins a general-purpose AI assistant's memory, personalization, and training pipeline. OpenAI's own docs say conversations with connected financial accounts follow your normal ChatGPT model-training settings. For Free, Plus, and Pro users in personal workspaces, data sharing is enabled by default unless you opt out. The privacy question is what it retains, what it infers, and what it trains on after you’ve handed over the map.

@privacy_guides Thank you for covering Brave Leo’s TEE work in your news section. We’d be grateful if you’d consider evaluating Brave Leo for the AI Chat page, especially now that Leo supports both a local BYOM path and a verifiably private TEE-backed cloud path in Brave Nightly. AI Chat page: privacyguides.org/en/ai-chat… Privacy Guides coverage: privacyguides.org/news/2025/… TEE write-up: brave.com/blog/browser-ai-te… BYOM: brave.com/blog/byom-nightly/

From a security perspective: recent Apple Silicon, especially current iPhones and iPads and Apple Silicon Macs (with M5 adding Memory Integrity Enforcement). Secure Enclave, pointer authentication, Lockdown Mode, and Memory Integrity Enforcement on A19/M5 deliver the most consistent default hardening you can buy. PAC is an Arm feature, Android has StrongBox and MTE on newer Pixels, Windows has Pluton and VBS. Apple’s advantage is deployment consistency. For journalists, activists, or anyone in a mercenary spyware threat model, that is the bet.

“Secure by default” is NOT a claim you earn just like that. Anyone can say “hardware-isolated sandbox,” “VPC-level separation,” “short-lived proxy tokens,” and “encryption at rest.” Security is verifiability. Perplexity Computer is a closed production agent system. The parts that actually matter are NOT independently reproducible by outside researchers: - sandbox orchestration - token broker - connector permissions - model routing - persistent memory - egress controls - action approval gates - cross-tenant isolation The question that matters: “What can users and researchers actually verify?” Can we inspect the sandbox primitive? Is it a VM, microVM, container, TEE, or something else? The post says “hardware-isolated.” Perplexity’s own docs describe an “isolated compute container.” Those are not interchangeable terms. Publish the actual boundary. Is the isolation per-task within one tenant, or per-tenant at hardware level? Can customers get remote attestation? Are builds reproducible? Has the production isolation boundary been independently audited? What persists after the “temporary” workspace resets? Where are proxy tokens stored? Can code inside the sandbox read them? Are tokens bound to sandbox identity, task ID, audience, provider, expiry, IP, and action scope? Can the token be used outside the sandbox? What is the default outbound egress policy? Which model providers see task contents? Who can access those logs for support, abuse review, or debugging? What goes into memory? What can memory later retrieve? If task N writes attacker-controlled payloads into memory, what stops task N 10 from reading them? Persistent memory is an exfiltration channel by default. Where is the published threat model? What does the sandbox protect against, and what does it explicitly NOT protect against? Without that document, “secure by default” maps to undefined coverage. Where is the user-visible audit trail? Not Perplexity’s internal logs. Can a user see every connector call the agent made on their behalf, with payloads, append-only, exportable? Without it, users cannot detect a compromise even after the fact. Which actions require explicit human approval? Sending external email, deleting data, posting publicly? Until those answers are externally verifiable, “secure by default” is marketing. And Perplexity has NOT earned that trust. Comet had public prompt injection findings. The relevant question is institutional behavior since then. Perplexity’s own docs describe Computer as an “independent digital worker” that can act across the web and a user’s work context through hundreds of app connectors. It can use Gmail, Outlook, GitHub, Linear, Slack, Notion, Snowflake, Databricks, Salesforce, and more. It has persistent memory, scheduling, automation, background execution, file monitoring, document creation, app building, email management, browser activity, and code execution. A sandbox can protect Perplexity’s infrastructure from the task. It does NOT automatically protect the user from the agent. Short-lived proxy tokens are better than raw API keys. Fine. But this is a confused deputy problem. The agent already holds legitimate authority across Gmail, Slack, GitHub, and Salesforce simultaneously. Prompt injection does not need to steal a token. It asks the deputy to act. Exfiltrate from Gmail to attacker-owned Notion. Open a malicious pull request. Send a Slack DM that looks authentic. And the injection surface is enormous. The attacker does not need a long-lived key. They need one successful action while the token is valid.

MacBook Neo is way more private and secure than Googlebook [at least based on what Google has disclosed so far]. And it's not even close. MacBook Neo starts at $599 and runs Apple silicon with a full Secure Enclave-backed security architecture. The $599 model ships with a Lock Key instead of Touch ID. The $699 model adds Touch ID, which unlocks Secure Enclave-backed biometric auth for login, passkeys, payments, app auth, and website sign-in. Googlebook is an AI-first laptop platform built around Gemini, Android apps, phone integration, Magic Pointer, custom AI widgets, Google account context, and access to phone apps and files. From a privacy and security standpoint, it massively expands the attack surface. MacBook Neo is a known vertical stack: Apple silicon, Secure Enclave, hardware root of trust, Apple-controlled boot chain, Secure Enclave-backed storage encryption and FileVault key handling, Signed System Volume, Gatekeeper and notarization, XProtect, SIP, TCC privacy controls, and Private Cloud Compute for Apple Intelligence. Googlebook's core product pitch is giving Gemini more context: what's on your screen, what's in your Google apps, what's on your phone, what you select, what you ask it to act on. Google has disclosed some guardrails here: granular controls, app-specific automation permissions, purchase confirmations, prompt-injection defenses, real-time indicators, activity logs, and Privacy Dashboard visibility. That helps. But guardrails are not the same thing as a mature, published, device-level security architecture. The privacy issue is also data handling. Gemini activity can include prompts, files, videos, screens, photos, connected-app data, and other interaction data. Depending on settings, some of that can be used to improve Google services, reviewed by humans, and retained for long periods. It is a much larger privacy blast radius than any average laptop. Apple's model is narrower: process on-device when possible, use Private Cloud Compute when needed, do not retain the request after the response, do not make it accessible to Apple, and allow researchers to inspect and verify the server software. To be fair, Apple also has phone integration. iPhone Mirroring, Handoff, AirDrop, iCloud, and Continuity all expand what a Mac can touch. The difference is that Googlebook makes phone apps, phone files, Google account context, screen selection, and Gemini-driven action the center of the product. That changes the threat model. Android's app sandbox is excellent. ChromeOS has a strong secure-by-default model. Verified Boot, file-based encryption, containerization, hardware-backed keys, and long update support can be very good. But right now, Googlebook is a preview of an OEM ecosystem. MacBook Neo is a shipping Apple silicon Mac with a documented security architecture. For a privacy-conscious buyer, I'd take the $699 MacBook Neo with Touch ID over Googlebook.

Friends don’t let friends use Chrome.

This is a huge win for privacy by default. Cross-platform end-to-end encryption is finally rolling out for RCS between iPhone and Android. RCS is the modern SMS/MMS replacement. Better photos and video, typing indicators, read receipts, group chat. When you see the lock icon, the message content is E2EE. It can’t be read in transit by Apple, Google, your carrier, or anyone in the middle. MLS (RFC 9420) is the IETF standard built for interoperable end-to-end encrypted messaging across clients and platforms. Having said that, content privacy is NOT metadata privacy. RCS is still phone-number, provider, and carrier-based. A huge upgrade from SMS, but it does not make the fact of communication disappear. For conversations where who, when, and how often is sensitive, @signalapp is still the standard. iMessage is the strongest default for Apple to Apple, especially with PQ3 post-quantum protections. iPhone users update to iOS 26.5. Android users update Google Messages.

You shouldn’t trust any Google software if you care about privacy. The Pixel in my pocket is a GrapheneOS device that happens to run on Google hardware. That’s the only relationship with Google I’m willing to have.

Privacy research is a serious endeavor. Real people make threat-model decisions based on what they read in posts like this. Journalists, dissidents, abuse survivors, activists, and ordinary users trying to protect their families. Getting it wrong is NOT a hot take. It is harm. This post gets almost everything wrong. @signalapp was NOT hacked in 2025. The 2025 incidents people are citing were not compromises of Signal’s protocol or Signal’s servers. One was TeleMessage, an unofficial Signal-like archiving service used by some US officials, whose backend was breached; TeleMessage is designed to capture messages after decryption for compliance archiving, which is the opposite of Signal’s privacy model. Separately, Russian state-aligned actors phished Signal users by abusing the linked-devices QR flow. That is social engineering against endpoints - not a break of Signal’s cryptography. Signal shipped hardening around linked devices and account safety in response. Calling that “Signal was hacked” is the kind of careless framing that actively misleads people about what they need to defend against. Then XChat. This is where the post stops being sloppy and becomes actively misleading. XChat has multiple publicly acknowledged structural limitations, several of them described by X itself. X’s own help page says Chat is not forward secure: if the private key of a registered device is compromised, an attacker can decrypt all encrypted Chat messages sent and received by that device. Private keys are not stored only on the user’s device; X says they are stored on X infrastructure using the Juicebox protocol, split across three Juicebox realms currently operated by X, and recoverable with the user’s PIN. X also says two of those realms are HSM-backed and that the PIN cannot be brute-forced, but that still leaves users relying on X’s implementation, client delivery, key directory, HSM deployment, account system, and operational security. X’s own documentation also says associated metadata is not encrypted - including recipients and creation time - and that sharing Posts in encrypted Chat leaves X with a record that those Posts were shared. It says sending a message or image to Grok takes that content out of the encrypted conversation context. Early public testing also reported weak media-metadata handling in XChat’s beta rollout. X has cited a @trailofbits review of the Chat protocol. External experts, including @matthew_d_green of Johns Hopkins, have argued that XChat’s forward-secrecy and key-storage choices make it structurally weaker than Signal and not appropriate for sensitive conversations in its current form. “The only major messaging app without a known structural vulnerability” is not a careful security claim. At best, it is marketing. XChat may be an improvement over legacy X DMs, but it is not a mature replacement for Signal, and it is not the safer choice for high-risk users. This is why privacy research has standards. A confident wrong answer on a million impression account is not neutral. It pushes real people toward weaker tools while telling them they are safer, and the people most likely to be hurt by that are the ones with the least margin to absorb a mistake. Do NOT get privacy advice from accounts like this one. Read the researchers. Read the audits. Read the help pages of the products you trust your life to.

Here’s mine:

PrivacyPack by @enteio has come a long way since I became a maintainer. We’ve added new categories, multiple alternatives per category, more privacy-respecting picks for mainstream apps, and a cleaner export/share flow. What should we add next? High-signal feedback only.

Brave Leo is absolutely GOATED 💯🐐

how @brave leo stacks up against mainstream consumer AI assistants on privacy by default. looked at defaults around: - whether consumer chats are used for model training - server-side retention of prompts/responses - human review / abuse monitoring - opt-in vs opt-out controls - data routing and jurisdiction - whether stronger protections only apply to enterprise/API plans methodology is still being refined, and corrections are welcome.

“No training” is a promise. Privacy by design is architecture. Brave Leo’s privacy model is minimization non-retention unlinkability: no linkable identifiers like IP addresses, no persistent server retention of prompts/responses/context, no model training on conversations, local encrypted chat history, unlinkable Premium tokens, and aggregate query analytics via STAR/Nebula. In Brave Nightly, we’re testing the next step: TEE-backed confidential LLM inference. The model runs in a hardware-isolated GPU environment, computation is encrypted, and cryptographic attestation can verify which model and server code ran. The goal is to move sensitive AI from “trust our policy” toward privacy boundaries users can verify.