标签：#Privacy

TL;DR — I built and open-sourced AI Health Steward , a self-hosted, private AI health manager for families. It reads photos of lab reports with multimodal LLMs, builds a structured per-person health profile, shows trends on a dashboard, and answers health questions grounded in your actual data — all running on your own server. Privacy isn't a feature; it's the whole point. Star it on GitHub . The problem: your health data is a product Every family has a shoebox — or a folder — of medical reports: blood tests, blood-pressure logs, prescriptions, scan findings. And every "convenient" health app wants to hold those records for you. But hold them where ? On someone else's cloud, to be monetized, analyzed, or lost when the startup pivots. Health records are the most sensitive data you own. They shouldn't be a product. They should live on your shelf. So I built the opposite: a self-hosted AI health steward where the data never leaves your server. What it does 📄 Take a photo of a lab report → structured data. A multimodal LLM extracts key metrics (BP, glucose, lipids, CBC…) with your confirmation before anything is filed. 🧬 A person-level health profile as the single source of truth — basics, metrics, diagnoses, medications, allergies, lifestyle, family history, and data provenance (where each value came from). 📈 Trend visualization with anomaly markers and clinical critical-value alerts (e.g. BP ≥ 180/110 triggers a "see a doctor" banner). 💬 AI consultation grounded in real data — not a generic chatbot. Intent routing + function calling means answers reflect your profile, not Wikipedia. 🗓️ Personalized checkup plans via a 1+X+Y framework, with budget tiers and safety/contraindication screening. 📋 Periodic health summaries (weekly/monthly/yearly), risk scales (PHQ-9, GAD-7, diabetes, ASCVD), and follow-up/medication reminders . 🧠 RAG over your own history — archived reports are vectorized so you can ask "what did my A1C trend look like over 3 years?" The architecture ┌────

I keep seeing the same mismatch in the screen-time category: a lot of apps are technically blockers, but they feel like parental control software. That is fine if a parent is the customer. It is a bad fit if the user is an adult trying to manage their own habits. The difference is not cosmetic. When a blocker feels like surveillance, adults bounce. They do not want an account, a dashboard, or the feeling that their phone behavior is being watched somewhere else. That is the gap I built SproutGuard for: built for adults blocking themselves , not kids runs on-device through Apple's Screen Time APIs no account no server no usage data leaving the phone App Store: https://apps.apple.com/us/app/sproutguard-screen-time-detox/id6768664921?ct=devto-adults I also put the positioning plainly on the product page: self-control, not parental control The hard lesson from launching it is that being right about the problem is not the same thing as being shareable . Privacy architecture matters, but users rarely tell friends about architecture. What they do share is something emotional or visible: a streak, a mascot, a challenge, a before/after feeling. So the current working question for me is not "how do I explain on-device privacy better?" It is: How do you make a self-control product feel human enough that people talk about it? Website: https://shantj.github.io/sproutguard/ If you've worked on consumer productivity or habit products, I'm interested in what actually made users talk about them.

Companies treat some email domains as digital trash cans, despite the risks.

A security researcher has designed an algorithm that can create computer-generated patterns capable of hiding people, faces, and vehicles from detection by surveillance cameras.

There’s no perfect way to transfer possession of your digital assets to your loved ones after you’re gone. But there are things you can do now to make the process easier for them.

Most file-conversion workflows start with a trade-off that is easy to miss: Choose a file from your device. Upload it to a third-party server. Wait for processing. Download a new file. Trust that the original and the result are handled exactly as promised. That model is convenient, but it is not the only option. For a growing set of formats, a modern browser can read, transform, and export files directly on the user's device. The result is a different kind of tool: no upload queue, no account requirement, and no server-side conversion step. This post explains how browser-based file conversion works, where it is a strong fit, where it is not, and how we approach the problem in I Hate Converter , a free collection of locally run file converters. What “no upload” should mean “No upload” should be more than a reassuring line next to a file picker. For a browser converter, the useful promise is that the selected file is read and processed within the browser runtime. A tool can use browser APIs such as File , Blob , ArrayBuffer , Canvas , and Web Workers, as well as locally loaded WebAssembly modules, without sending the source file to an application server. That matters when a file contains information you would rather not place in another system: draft documents, customer exports, source assets, screenshots, scanned records, or internal media. It also reduces friction for quick conversions: choose a file, process it, download the result. The distinction is important: an app can have a website while still keeping the actual conversion local. A page load may fetch its code and assets, but the chosen file does not need to become a network request. Our no-upload file converter hub is built around that boundary: supported conversions run on-device, and formats that require a server are not presented as if they were local. The browser capabilities that make this possible Browsers are no longer just document viewers. Several stable platform features make useful local conversio

I thought I had a settings bug. What I actually had was three different kinds of state pretending to be one boolean. While building a Chrome Manifest V3 email-tracker blocker, I expected a simple flow: you flip Gmail on in the settings, and the extension starts working in Gmail. That was the theory, anyway. The problem showed up when I was testing on a second Chrome profile. I'd enabled Gmail on my main profile, and Chrome Sync helpfully carried that preference over to the other one. But the optional permission for mail.google.com didn't come along — host grants live in the local profile and never sync. Profile number two now believed Gmail was enabled while lacking the host grant needed to inject the inbox content script or inspect its DOM. Depending on how you write your code, that's either a silent no-op or an extension quietly behaving as if access exists when it does not. Neither is great. Once I stopped and wrote it down, the picture got clearer. There are three separate things here: the inbox the user wants enabled, the host access Chrome has actually granted in this profile, and the dynamic DNR rules that are currently installed . Collapsing them into one flag is convenient. It's also wrong. The manifest is a menu, not an order The extension declares each webmail origin under optional_host_permissions . Every inbox gets activated on its own, and Chrome only asks the user for access when they turn that particular integration on. Here's the thing I had to internalize: declaring an optional origin means nothing by itself. Until the live grant exists, the extension has no business registering a content script for that inbox, poking at its DOM, or — by its own scoping policy — activating client-scoped blocking rules for it. Why bother with per-inbox prompts at all? Mostly trust. A tracker blocker that asks for all your webmail up front looks exactly like the thing it's supposed to protect you from. Asking for Gmail when you enable Gmail — and nothing more — is an

Plus: A judge rules cell tower dumps unconstitutional, water utility hacks spread to a dozen states, a phishing email opens a missile-parts supplier’s inbox, and a ransomware boss gets 16 years.

Two security researchers bought cheap domains—including noreply.net and deleteduser.com—and set up email listening services. Hundreds of companies are sending them corporate secrets.

There are many companies manufacturing adversarial clothing designed to confuse facial recognition systems. It’s a cool idea, but I worry that it’s mostly security theater: “Our patterns play with that chaos, confuse algorithms and make it way harder to pin you down,” he said. Bell, however, said “none of these products are tried and tested, and a lot of these surveillance technologies can deal with a little resistance … [but] even if the designs don’t necessarily work perfectly, fashion is also a visible sign of resistance. “This is consumers collectively coming together to make a visible statement.”...

Most mobile apps ship a privacy policy as a link that opens Safari. A smaller number ship an in-app rendered policy. A tiny minority ship what I think is the single highest-leverage privacy screen: a summary that mirrors your Nutrition Label in plain language, designed to be read. Why it's high-leverage The privacy summary sits at the intersection of three concerns: Users read it before granting sensitive permissions. Especially for camera, contacts, location, and health data. App Store reviewers check it exists and matches your store listing. Regulators (GDPR, CCPA) reward it. Clarity is a compliance signal, not a legal defense — but it's what an investigator asks for first. Sixty minutes of design work. Meaningful trust dividends. Often the difference between first-submission approval and a rejection loop. What to include The privacy summary should mirror your Privacy Nutrition Label but with real language humans can parse: Each data category you collect — displayed as a card or a row, with a clear icon. Why you collect it — one line, plain language. "So you can log in on another device," not "for authentication purposes." Where it's used — is it stored on our servers, shared with third parties, only on your device? Be specific. How to opt out or delete it — a link or a button to the settings page where the user can act on that category. Six to eight cards, one per data category. No more. Visual patterns that read as trustworthy Design choices that consistently score high in user-testing for trust signal: Real language, not legalese. "We store your email address so you can log in" beats "Personal identifiers are retained for authentication purposes." Muted, confident colors. No warning reds, no compliance yellows. A neutral surface with soft accent for the data-category icons. Readable typography. 16pt body, generous line-height (1.5x), enough paragraph spacing that scanning is easy. Icons per category (not just text). A camera icon for camera data, a location pin

Immich is the better choice if you own a machine that stays powered on and you care where your photos live. It gives you the parts of Google Photos people actually use every day, mobile auto backup, face grouping, map view, albums and shared links, without a storage meter that raises your bill as your library grows. Google Photos still wins on zero maintenance and on search that understands a sentence. If you are willing to spend one evening on setup and roughly an hour a quarter on updates, Immich replaces it. TL;DR by reader profile: Family archivist with 15 years of photos (Marta, two phones, one shared library): move to Immich on a small always on box, because a growing archive is exactly the case where a per gigabyte subscription compounds against you forever. Photographer shooting RAW every weekend (Tomas, 40 megapixel bodies): Immich, because RAW files eat cloud tiers fast and you already keep a local working copy that you can point the server at. Non technical user with one phone and no home server (Elena, iPhone, no NAS): stay on Google Photos for now, because Immich needs someone to own updates, backups and remote access, and that someone would be you. Privacy sensitive professional handling client images (lawyer, therapist, journalist): Immich on hardware you control, because the legal question is not whether the provider is trustworthy but who can be compelled to hand over the data. Homelab owner already running Docker (Sam, existing NAS and reverse proxy): Immich, because the marginal cost is one compose stack on infrastructure you maintain anyway. Small team or studio sharing a shoot library (five people, one archive): Immich with per user accounts and shared albums, because Google Photos was built for one person and gets awkward the moment several people need write access. The central tradeoff: Google Photos sells you freedom from maintenance and pays for it with a recurring bill and a library you do not control, while Immich hands you control and a o

Most organizations do not operate a single website. A typical customer journey might move through: company.com ↓ docs.company.com ↓ company-academy.com ↓ company-checkout.com These properties may belong to the same organization, but browsers and analytics systems can treat each domain as a separate visitor and session. Cross-domain measurement is possible with major analytics platforms, but it normally ties the implementation to a specific vendor, transfers an existing measurement identifier through the destination URL, or depends on users authenticating. I built Nylo to explore another approach: Preserve pseudonymous continuity across domains an organization controls, without browser fingerprinting, third-party cookies, or requiring the visitor to log in. Nylo is not intended to identify a person. It is intended to answer a narrower question: Did the same pseudonymous browser journey continue from one authorized domain to another? What Nylo is Nylo consists of: A zero-dependency JavaScript client SDK A server-side event ingestion interface A pseudonymous identifier called a WaiTag A short-lived cross-domain token exchange DNS-based verification of participating domains Configurable event collection Storage adapters for different backend systems The core analytics SDK is available under the MIT License. Production commercial use of the cross-domain WTX-1 functionality uses a separate commercial license. Nylo is designed to function as an analytics collection and continuity layer. It can eventually send events to an existing warehouse or analytics platform rather than requiring organizations to replace their reporting stack. How continuity works Consider a visitor moving between two independently registered domains: Visitor opens site-a.com | v Nylo creates a pseudonymous WaiTag | v Visitor follows an authorized link | v A short-lived token is transferred | v site-b.com verifies the token | v Both events reference the same pseudonymous journey Before enabling cross-d

AI photo editors look simple from the outside: upload an image, describe a change, and download the result. The hard part is everything around the model call. If you are building or evaluating a browser-based image editor, the workflow needs to protect the original file, reject bad inputs early, make retries safe, and help the user compare the result with the source. This article walks through a small implementation pattern that does that without turning the UI into a complex desktop editor. 1. Validate the image before upload Do not rely on the file extension. Check the MIME type, file size, and whether the browser can actually decode the image. const ACCEPTED_TYPES = new Set ([ " image/jpeg " , " image/png " , " image/webp " , ]); async function validateImage ( file ) { if ( ! ACCEPTED_TYPES . has ( file . type )) { throw new Error ( " Use a JPG, PNG, or WebP image. " ); } const maxBytes = 10 * 1024 * 1024 ; if ( file . size > maxBytes ) { throw new Error ( " The image must be smaller than 10 MB. " ); } const bitmap = await createImageBitmap ( file ); const dimensions = { width : bitmap . width , height : bitmap . height }; bitmap . close (); if ( dimensions . width < 64 || dimensions . height < 64 ) { throw new Error ( " The image is too small for a useful edit. " ); } return dimensions ; } This catches renamed files, broken images, and tiny inputs before they consume bandwidth or model credits. 2. Treat the prompt as a single edit contract Open-ended chat is useful, but it can make image editing unpredictable. A clearer UI asks for one concrete change at a time: remove the person on the right; replace the background with a plain white wall; repair the crease across the top-left corner; extend the image to a 16:9 frame. The request object should preserve that intent without mixing it with UI state: function buildEditRequest ( file , prompt , options = {}) { const normalizedPrompt = prompt . trim (). replace ( / \s +/g , " " ); if ( normalizedPrompt . length < 5 )

A lawsuit accuses Homeland Security of violating protesters’ free-speech rights—but the agency is using it to try to get access to the plaintiffs’ encrypted communications.

Homeland Security told immigrants that leaving the US would wipe out fines it claims they owe. Now it wants private investigators to find them in their home countries and collect.

More than 50 offending image and video ads were published across Facebook, Instagram, Messenger, or Threads, according to Meta’s ad library data. Some ran as recently as this week.

You can link more devices with one phone number on Signal now, including an Android phone or iPhone. Signal already supported linking PCs and iPads, but not additional phones. When you link a device on Signal, you can check and respond to new messages across all of your linked devices. You can also choose whether […]

New findings by the Electronic Frontier Foundation aim to warn app developers that some of the third-party code they place in their apps may also collect their users' location data when they grant permission to the app.

And it’s personal information (alternate link ): The exposed data includes an AI-powered therapy app that someone appears to have vibe-coded, notes on meetings, and a dashboard someone made apparently to analyze medical billing data. Exposed chats reportedly include private cryptocurrency wallet keys and personal information like peoples’ addresses. What seems to be the issue is a user setting about data sharing. Anthropic’s position is that it’s not their problem : “We give people control over sharing their Claude conversations publicly, and in keeping with our privacy principles, we do not share chat directories or sitemaps with search engines like Google,” the company said in a statement. “These shareable links are not guessable or discoverable unless people choose to share them themselves. When someone shares a conversation, they are making that content publicly accessible, and like other public web content, it may be archived by third-party services.”...