Coder Legion - Recent posts tagged privacy

A breach claim is trending? Ask three questions first

Fri, 30 Oct 2026 19:55:58 +0000

Originally published on the Dunime blog.

How an investigator separates a real disclosure from recycled data, and what an organisation should do in the first hours.

A breach is announced on X. Screenshots spread. Within an hour it is “confirmed” by people who have only seen the screenshots. Most of the time, nobody has checked anything yet.

What a breach claim usually is

Claims surface on social media, Telegram channels and forums, often with a sample and a record count. Some are real. Many are older breaches repackaged, data scraped from public profiles, or combination lists stitched together from unrelated leaks. The claim is a lead. It is not yet a fact.

Question 1: who is the source?

A new account with no history, or a seller who profits from attention, is a lead to follow up, not a confirmation. Look at what the same source has claimed before and how much of it held up.

Question 2: do the numbers agree?

Real disclosures are usually internally consistent: the record count, the fields described and the dates line up. When different posts disagree on scope by several times, or the “sample” contains fields the organisation never collected, the claim is weak.

Do not download the sample. Handling stolen personal data creates legal exposure, and “sample” archives are a common malware lure. Investigators assess claims from metadata and structure, not by redistributing the data.

Question 3: who has verified it?

Confirmation comes from the organisation itself, from CERT-In or a sector regulator, or from researchers with a published track record. Until one of them speaks, write and share it as an allegation.

Any answer is no? It is an allegation. Protect yourself, do not amplify it, and never open the sample.

If you might be affected

Check your email on Have I Been Pwned, a free service that tells you which known breaches include your address. Its limit: it only knows breaches that have been loaded into it.
Change reused passwords starting with email and banking, and turn on two-factor authentication.
Expect targeted phishing that quotes the breach. That is often the real damage.

If your organisation is named

Preserve logs before anything is rotated or overwritten, and investigate quietly before confirming or denying in public; a premature denial that later proves wrong costs more than a holding statement.

Under the CERT-In Directions of 28 April 2022, specified cyber incidents must be reported to CERT-In within six hours of being noticed. Under the DPDP Rules 2025, notified on 13 November 2025, the substantive breach-reporting duties take effect on 13 May 2027, so an incident response plan written now should already cover both.

Questions people ask

How do I know if a data breach claim is real? Ask three questions: who is the source and what is their track record, do the numbers and fields in the claim agree with each other, and has the organisation, CERT-In, a regulator or a credible researcher verified it. If not, treat it as an allegation.

Should I download a leaked data sample to check it? No. Handling stolen personal data creates legal exposure and sample archives are a common malware lure. Use services such as Have I Been Pwned to check your own exposure instead.

How quickly must a cyber incident be reported to CERT-In? Under the CERT-In Directions of 28 April 2022, specified cyber incidents must be reported within six hours of being noticed.

Sources

This guide is part of Dunime's fraud-help hub — also in हिन्दी, বাংলা, मराठी, తెలుగు and தமிழ், each with a short video: dunime.com/protect.

Want to know if your data is in a real breach? Dunime's VAPT and exposure checks show what's actually reachable. Talk to us.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

[OC] I built a free, open-source HIPAA DICOM anonymizer for medical imaging

Fri, 30 Oct 2026 10:49:57 +0000

I just released dicom-clean — an open-source CLI tool for HIPAA-compliant DICOM de-identification. Here's how it works and why I built it.

The Problem

Medical imaging files (CT scans, MRIs, X-rays) use a format called DICOM, which contains two things:

Metadata — patient name, birth date, MRN, hospital, referring physician, etc.
Pixel data — the actual image

When hospitals want to share DICOM data for research, AI training, or vendor evaluation, they must remove the patient identifiers first — this is required by HIPAA Safe Harbor (45 CFR §164.514(b)(2)).

But existing options are problematic:

Commercial tools (RSNA CTP, DicomCleaner) cost $5,000+/year
Cloud solutions upload patient data → HIPAA violation risk
DCMTK / GDCM work but have steep learning curves (C++ toolchain, complex syntax)

So I built dicom-clean to be:

✅ 100% offline (air-gapped compatible)
✅ Simple CLI (one command)
✅ Zero-install (standalone .exe)
✅ Free and open source (AGPL-3.0)

What It Does

1. Strips All 18 HIPAA Patient Identifiers

The tool blanks out 40+ scalar PHI tags and deletes 8 sequences that may carry nested PHI:

HIPAA_TAGS_TO_BLANK = (
    (0x0010, 0x0010),  # PatientName
    (0x0010, 0x0020),  # PatientID
    (0x0010, 0x0030),  # PatientBirthDate
    (0x0010, 0x1040),  # PatientAddress
    (0x0008, 0x0080),  # InstitutionName
    (0x0008, 0x0090),  # ReferringPhysicianName
    # ... 40+ more
)

HIPAA_TAGS_TO_REMOVE = (
    (0x0008, 0x1110),  # ReferencedStudySequence
    (0x0008, 0x1115),  # ReferencedSeriesSequence
    # ... 6 more
)

Design decision: I blank the scalar tags (preserving tag + VR) rather than deleting them, so downstream PACS and DICOM viewers don't break when they expect those fields.

2. Deterministic UID Pseudonymization

DICOM uses UIDs (Unique Identifiers) to link files together. A study has a StudyInstanceUID, each series has a SeriesInstanceUID, and each image has a SOPInstanceUID.

If you just replace these with random UUIDs, you lose the relationships between files — a PACS server won't be able to group images from the same study.

My solution: SHA-256 with an optional salt.

def pseudonymize_uid(original_uid: str, salt: str = "") -> str:
    """Deterministically pseudonymize a DICOM UID."""
    if not original_uid:
        return original_uid
    digest = hashlib.sha256(
        (salt + str(original_uid)).encode("utf-8")
    ).hexdigest()
    number = int(digest[:32], 16)  # 128 bits
    return f"2.25.{number}"

Why this works:

Deterministic — Same input + salt → same output, always
Reversible relationships — All files from one study get consistent pseudonyms
Non-reversible — Without the salt, you can't reverse it
Valid format — Output is a proper DICOM UID (2.25.<128-bit-int>)

3. Image Integrity

The pixel data is never touched. Same for:

Modality (CT, MR, US, etc.)
PixelData
TransferSyntaxUID
PhotometricInterpretation
Rows / Columns
BitsAllocated / BitsStored
PixelSpacing / SliceThickness
Window/Level tags

So the image looks identical in any DICOM viewer — only the metadata changes.

4. Date Reduction

HIPAA permits keeping the year but not the month/day. So:

Before: StudyDate = "20250315"
After:  StudyDate = "20250101"

Tech Stack

Component	Purpose
pydicom	DICOM parsing & writing
Typer	CLI framework
Rich	Terminal UI (panels, progress bars, tables)
PyInstaller	Standalone `.exe` build

What It Looks Like

$ dicom-clean sanitize patient.dcm output\ --salt "my-secret"

The output shows a live progress bar and a colored summary table:

Total Files Scanned: 1,250
Successfully Anonymized: 1,248
Skipped (Non-DICOM): 2
Errors / Failed: 0

Directory Batch Processing

The tool recursively processes directories and preserves the original subfolder structure:

$ dicom-clean sanitize C:\Hospital_Data C:\Clean_Output --salt "hospital-2025"

Robustness

Non-DICOM files are skipped with a warning instead of crashing
Per-file errors are collected into a summary
Uses try/except for InvalidDicomError, OSError, IOError, and generic exceptions
Exit code 1 if any file failed, 0 otherwise

Installation

Windows Standalone (No Python Required)

Download dicom-clean.exe from the Releases page and run:

dicom-clean.exe sanitize input.dcm output\ --salt "my-secret"

From Source

git clone https://github.com/kaveen-ai/dicom-clean.git
cd dicom-clean
pip install -r requirements.txt
python anonymizer.py --help

Design Tradeoffs

Some decisions I made and why:

1. SHA-256 hashing vs random UUIDs for UIDs

✅ Hash preserves relationships across files
✅ Deterministic (reproducible)
❌ Requires salt management for security

2. Blank tags vs delete tags

✅ Blanking preserves tag structure (PACS-safe)
✅ Downstream tools don't break
❌ Leaves an empty tag with metadata footprint

3. AGPL-3.0 + Commercial dual-license

✅ Free for open-source use
✅ Commercial license funds development
❌ AGPL can be a dealbreaker for some hospitals

4. Single-file CLI vs library-first

✅ Standalone .exe for non-technical users
✅ The core DicomAnonymizer class is importable as a library
✅ CLI is just a thin Typer wrapper

The `DicomAnonymizer` Class

If you want to use the engine programmatically:

from anonymizer import DicomAnonymizer

anonymizer = DicomAnonymizer(
    salt="my-hospital-secret",
    remove_private_tags=True,
    reduce_dates_to_year=True,
)

summary = anonymizer.anonymize(
    input_path="patient.dcm",
    output_path="output/",
)

print(f"Anonymized {summary.anonymized} files")

The class handles:

UID pseudonymization
HIPAA tag blanking
Private tag removal
Date reduction
File meta sanitization

What's Next

I'm planning:

GitHub Actions CI — test matrix across Python 3.10-3.13
PyPI publication — pip install dicom-clean
Docker image — for hospital IT deployments
Pixel OCR redaction — for burned-in PHI in images (commercial edition)

Feedback Welcome

I'd love feedback from anyone working with DICOM data, healthcare IT, or medical imaging.

Star on GitHub: github.com/kaveen-ai/dicom-clean
Report bugs: Issues
Discussions: GitHub Discussions

What would you like to see next?

Tags: python healthcare opensource dicom privacy

I Built a Browser-Based GIF Compressor That Keeps Your Files on Your Device

Fri, 30 Oct 2026 09:51:36 +0000

Animated GIFs are easy to share, but their file sizes can get out of hand quickly. A few seconds of animation may be too large for a chat message, a community post, or a website. The usual fix is to upload the file to an online converter, wait for a server to process it, and download the result. I wanted a simpler workflow that does not require sending the original GIF to a server.

That is why I built GIF Compressor (https://gifcompressor.cc/), a free tool that processes animated GIFs locally in the browser.

What it does

You can drag in a GIF, choose a compression preset, and compare the original and compressed file sizes before downloading. The presets favor image quality, a balance between quality and size, or the smallest file. If you need more control, you can adjust compression strength, image dimensions, palette colors, and optimization level.

The tool also supports batches of up to 20 GIFs, with a 100 MB limit per file. The same settings can be applied across a batch, which is useful when preparing reaction GIFs, documentation assets, or animations for a website.

For specific upload limits, I added pages that attempt to reduce a GIF toward 10 MB or 1 MB. These use progressively stronger settings and show whether the target was actually reached; no compression tool can guarantee a particular size for every source GIF without potentially unacceptable quality loss.

Why browser-side processing?

The compression engine runs through WebAssembly in your browser. The GIF stays on your device while it is processed. Besides the privacy benefit, this removes the upload-and-wait step, especially noticeable for larger files or slower connections.

There is still a trade-off: GIF compression is not magic. Reducing colors or dimensions can make a file much smaller, but it can also change how the animation looks. I recommend starting with the quality-focused preset, previewing the result, and only increasing compression when the file is still too large.

Try it

GIF Compressor is available at https://gifcompressor.cc/. It is free to use, and there is no account needed for the compression workflow. I would appreciate feedback from other developers and creators: which GIF-size limits or batch workflows are most frustrating for you today?

How to Enable MAC Address Randomisation in Linux Desktop

Sun, 18 Oct 2026 07:57:35 +0000

Link to Project: https://github.com/ShobanChiddarth/randomised_mac_linux

Why a Persistent MAC Address Is a Problem

A persistent hardware address allows networks to consistently identify the same device across sessions. On:

Public Wi-Fi
Campus networks
Enterprise environments
Captive portals

this makes long-term tracking trivial, even if your IP address changes.

Many Linux desktops still use the permanent hardware address by default, which means your device can be passively identified every time it reconnects to a network.

How This Project Solves It

This project automates MAC address randomisation at boot.

On every system startup:

The interface is brought down
A new locally administered MAC address is generated
The interface is brought back up

A systemd service ensures this runs automatically, requiring no manual action after setup.

Installation

When you install macchanger, you may get a prompt to enable regular changing of MAC addresses. You should select "no" because we wan't complete control over when and how the MAC address randomisation is scheduled.

Debian based

Save this script and run it as sudo

sudo apt install macchanger git -y
git clone https://github.com/ShobanChiddarth/randomised_mac_linux.git
cd randomised_mac_linux
chmod +x ./randomise_MACs.sh
sudo cp randomise_MACs.sh /usr/bin/
sudo cp randomise_MACs.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable randomise_MACs

Now your MAC addresses of real network interfaces will automatically change to a random value on each boot. To verify it, you can run ifconfig to show MAC addresses before and after running sudo systemctl start randomise_MACs to compare values.

Other distros

Visit the GitHub repo and google your distro specific command for each command listed.

Obsidian Plugin Error Logging Without Telemetry

Sat, 17 Oct 2026 16:43:33 +0000

Crash reporting feels like a solved problem until your distribution platform says the obvious solution is not allowed.

Quick solution:

type ErrorRecord = {
  timestamp: string;
  level: "error" | "warning";
  source: string;
  message: string;
  stack?: string;
};

const MAX_RECORDS = 50;

function appendRecord(
  records: ErrorRecord[],
  next: ErrorRecord
): ErrorRecord[] {
  return [...records, next].slice(-MAX_RECORDS);
}

Check the current Obsidian community-plugin developer policies before adding any reporting path; this design keeps capture local until the user chooses to share it.

For Obsidian community plugins, that boundary is explicit. The current developer policies state that community plugins must not include client-side telemetry. Network use and server-side telemetry also require disclosure.

That rules out the usual "just add a crash SDK" answer for a plugin intended for the official directory.

You still need production diagnostics, especially for startup and mobile failures. The solution is to separate capture from transmission.

Capture locally. Redact aggressively. Let the user decide whether anything leaves the device.

Start with the policy boundary

The goal is not to imitate a remote crash service secretly.

The goal is to preserve enough local evidence that a user can report a reproducible failure.

A compliant design should have these properties:

no automatic error upload;
no hidden analytics endpoint;
no third-party crash SDK;
bounded local storage;
explicit secret redaction;
user-visible controls to inspect, copy, clear, or report;
network transmission only after a deliberate user action.

If you are publishing to the Obsidian community directory, read the current developer policies before designing observability.

Use a bounded local ring buffer

A log that grows forever becomes its own reliability problem.

For a plugin, the useful window is usually recent failures, not months of historical console noise.

Store the log in the plugin's own configuration area rather than scattering debug files through user notes.

Serialize writes

Mobile and startup errors often happen close together. Multiple asynchronous writes can race and overwrite each other.

A tiny write queue is enough:

let writeChain = Promise.resolve();

function persist(records: ErrorRecord[]) {
  writeChain = writeChain.then(() =>
    savePluginData({ errorLog: records })
  );
  return writeChain;
}

This is not a database. It simply makes "append error A, then error B" deterministic.

On startup:

load the existing local log;
append any new error;
cap it;
persist the new snapshot.

A restart should not destroy the exact failure you are trying to diagnose.

Redact before storage, not before upload

If the log is supposed to stay local, it may be tempting to postpone redaction until the user presses Report.

That leaves secrets sitting unmasked on disk.

Redact before the record enters the buffer.

Your redactor should cover values your plugin knows about and common credential shapes:

function redact(input: string, secrets: string[]): string {
  let output = input;

  for (const secret of secrets) {
    if (secret) output = output.split(secret).join("[REDACTED]");
  }

  output = output.replace(
    /Bearer\s+[A-Za-z0-9._~+/=-]+/gi,
    "Bearer [REDACTED]"
  );

  output = output.replace(
    /github_pat_[A-Za-z0-9_]+/g,
    "[REDACTED_GITHUB_TOKEN]"
  );

  return output;
}

Do not log note bodies, full sync payloads, or arbitrary request content just because they are available.

The safest diagnostic is usually structural:

operation name;
error class;
status code;
sanitized message;
timestamp;
plugin version;
platform category.

Test the redactor like a security boundary

An untested redactor is a promise, not a control.

Write tests for:

exact known secret values;
Authorization headers;
token-like patterns;
stack traces containing query parameters;
multiline messages;
empty strings;
already redacted values.

Also test that ordinary technical context survives. A redactor that turns every path, SHA, and URL into "[REDACTED]" produces a safe but useless report.

Aim for minimum useful evidence, not maximum logging.

Capture global errors carefully

Plugin-specific try/catch blocks are valuable, but some failures escape them.

Where the host lifecycle allows it, register handlers for:

error;
unhandledrejection.

Normalize those events into the same ErrorRecord shape.

Just as important: unregister or bind them through the plugin lifecycle so hot reloads and plugin disable/enable cycles do not create duplicate listeners.

The global hook is a safety net, not a replacement for contextual error handling. A caught sync error can say "failed while fetching remote tree"; a global rejection may only know that a promise failed.

Give the user inspection controls

A local log becomes trustworthy when the user can see and erase it.

A small settings section can provide:

View recent errors;
Copy sanitized report;
Clear log;
Report issue.

Make the retention policy visible. If you keep 50 entries, say so.

This is especially important for privacy-oriented tools. Users should not have to reverse engineer where diagnostic data lives.

Reporting should be user initiated

A practical reporting flow can open a prefilled GitHub issue URL after letting the user preview the sanitized text locally:

const params = new URLSearchParams({
  title: "Bug report",
  body: buildSanitizedReport(records),
});

window.open(
  "https://github.com/example/project/issues/new?" + params.toString()
);

The plugin has not submitted anything at this point. It opened a browser page.

The user can:

review the text;
delete anything they do not want to share;
add reproduction details;
press Submit.

That human-in-the-loop boundary is fundamentally different from background telemetry.

A local logger cannot capture everything.

If the plugin fails before its code initializes, its own global handlers may never run. A corrupted manifest or syntax error during loading can occur outside the logger's lifetime.

Document that limitation.

Useful fallback guidance can tell advanced users how to capture the Obsidian developer console when the plugin does not load far enough to show its own report UI.

Reliability improves when a system has a known boundary rather than claiming parity with a full remote crash platform.

Keep network behavior separate from diagnostics

A plugin may legitimately use the network for its main feature. That does not mean diagnostics should piggyback on those requests.

Keep these concerns separate:

feature network request
    !=
error reporting transport

If the plugin syncs files, calls an API, or uses an AI service, disclose that according to platform rules. The local error buffer should not silently convert those connections into a telemetry channel.

The same privacy principle matters for richer workflows: users need to understand when data stays local and when a feature intentionally sends it elsewhere.

Verification and execution checklist

Read the current directory policy to ensure compliance with telemetry rules.
Store errors locally only without automatic upload paths.
Cap the buffer and serialize writes to prevent race conditions during startup.
Redact secrets before persistence and test the redactor against credentials.
Verify that issue reporting requires explicit user interaction and review.

# 🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

Sat, 17 Oct 2026 07:22:23 +0000

🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

From an open-source marketplace to a network of independent services. One step at a time.

Hey Coder Legion community! 👋

We've reached a new technical milestone with MyZubster, our open-source ecosystem focused on connecting people, projects, knowledge, and independent infrastructure.

We recently deployed our first experimental Tor v3 Onion Service using Docker and HAProxy.

🚀 What works so far?

✅ Tor successfully bootstrapped to 100%
✅ A dedicated Onion v3 identity was generated
✅ An isolated HAProxy service serves our experimental page
✅ Docker networks separate the pilot from production services
✅ The test proxy returns HTTP 404 for /api and /admin
✅ The experimental page was displayed during testing

Our architecture:

Tor Browser
     ↓
Tor v3 Onion Service
     ↓
Isolated HAProxy
     ↓
MyZubster Pilot Page

Important: This is an experimental proof of concept, not a production-ready or independently audited service. Marketplace, Zorgax, wallets, and payment systems are not part of this pilot.

🌍 Why are we building this?

We want MyZubster to evolve into an ecosystem where contributors can:

Connect independent open-source projects.
Host services on their own infrastructure.
Share verifiable technical knowledge.
Build interoperable tools.
Participate in community-driven governance.
Explore privacy-conscious access through Tor.

We believe decentralization should be demonstrated through working infrastructure, not just promises.

👨💻 What's next?

We're collaborating with our contributor community, including @wasim-builds, on the next proposed development phase:

🔹 Reproducible Docker Compose deployment
🔹 Tor and HAProxy resilience testing
🔹 Network isolation and security documentation
🔹 Independent code reviews
🔹 Better monitoring and recovery procedures

🤝 Developers wanted!

Are you interested in Docker, Tor, cybersecurity, privacy, distributed systems, or open-source collaboration?

You can contribute through documentation, testing, code review, or pull requests.

No VPS or DAO membership is required to get started.

Explore the project:

🔗 GitHub: https://github.com/MyZubster-Ecosystem/myzubster

🧅 Tor Pilot Discussion: https://github.com/MyZubster-Ecosystem/myzubster/issues/1584

🌐 Website: https://www.myzubster.com/

Let's build independent infrastructure together, one verified component at a time.

@fuck.it - email with attitude

Tue, 13 Oct 2026 20:35:25 +0000

fuck.it is invite-only email for people who want a memorable address without becoming the product.
We built fuck.it around a simple idea: email should be something you pay for directly, not something subsidized by advertising, tracking or selling access to your data.
Every account gets an fuck.it email address with webmail plus IMAP and SMTP access so it works with standard email clients.

What you get

No advertising
No tracking pixels
No selling user data
Invite-only registration
IMAP and SMTP support
Webmail
Calendar, contacts and tasks
Encrypted connections
German-hosted infrastructure
Multiple storage plans up to 1 TB

Why invite-only?
Open signup attracts bots, spammers and scammers. That eventually hurts everyone on the platform through abuse, reputation damage and worse deliverability.
fuck.it deliberately avoids the free-for-all model. New users need an invitation before they can create an account.

Who is it for?
People who care about privacy, independence and having an email address nobody forgets.
It is not trying to replace every productivity platform on earth. It is email with attitude, built around a straightforward paid relationship between the service and the user.
Website: https://fuck.it

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source

Sat, 10 Oct 2026 04:14:28 +0000

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source Contributors

Docker • Tor • Node.js • React • Nginx • Privacy • Open Source

We're taking an exciting new step in the development of MyZubster: working toward making our ecosystem accessible through the Tor network using a .onion address.

Alongside our traditional website, we want to provide an alternative access path designed with privacy, infrastructure isolation, and reliability in mind.

And we're building it with the help of independent open-source contributors.

👨💻 Recognizing Our Contributors

A special thank you to Wasim (@wasim-builds) and Nicola (N4K48) for their contributions to MyZubster's evolving infrastructure.

Wasim is developing and refining changes involving our Docker setup, backend services, frontend infrastructure, and Tor integration.

🔗 Wasim's contribution — PR #1582:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1582

🔗 Wasim's GitHub:
https://github.com/wasim-builds

Nicola's earlier N4K48 contribution forms an important foundation for the work now being reviewed and tested.

🔗 Nicola / N4K48 — Original PR #1457:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1457

This is what makes open source valuable: contributors bringing independent ideas, improving each other's work, and helping transform experiments into reliable infrastructure.

🌐 What Are We Building?

We're developing a Docker-based Tor Onion Service that would allow users to access the MyZubster frontend through Tor Browser.

The intended architecture is:

        User with Tor Browser
                 |
             Tor Network
                 |
          .onion Address
                 |
         Tor Onion Service
                 |
       Internal Docker Network
                 |
          Nginx + React
                 |
          Node.js Backend
                 |
              MongoDB

The idea is to provide an alternative entry point without directly exposing backend or database services.

Our goal is not simply to generate an Onion address. We want the entire access path to be reliable, maintainable, and carefully reviewed.

✅ What We've Already Tested

We've been validating PR #1582 on an isolated VPS using dedicated Docker containers and internal networking.

Here are some of the results:

Backend and APIs

✅ Node.js backend successfully built and started after a local middleware import correction.

✅ MongoDB connectivity verified.

✅ Health, Ledger, and Economics API tests passed.

✅ Seven targeted authentication and authorization tests passed.

Frontend and Nginx

✅ React production build completed successfully.

✅ Frontend Docker image built.

✅ Nginx configuration validated.

✅ Homepage returned HTTP 200.

✅ React SPA fallback worked.

✅ Nginx successfully proxied Ledger API requests to the backend.

Tor and Onion Infrastructure

✅ Tor Docker image built successfully.

✅ Tor 0.4.9.11 installed and verified.

✅ Dedicated non-root Tor user and filesystem permissions tested.

✅ Frontend reachable from the isolated Onion test container with HTTP 200.

✅ A candidate fix for Tor's Docker hostname configuration issue passed static validation.

These are actual results from our isolated test environment, not claims of a completed public launch.

🔍 An Interesting Challenge We Discovered

The original Onion configuration used the Docker service hostname directly:

HiddenServicePort 80 frontend:80

During testing, Tor rejected the configuration:

Unparseable address in hidden service port configuration.

We reproduced the issue and tested a candidate solution using Docker DNS resolution.

The frontend hostname was resolved to its internal container IP before generating the Tor configuration.

The modified configuration passed validation.

But there's an important challenge:

Docker container IP addresses can change when services are recreated.

If Tor uses an address resolved only once at startup, it may later point to the wrong destination.

This is one of the areas where feedback from experienced infrastructure developers would be especially valuable.

🛠️ What We Still Need to Complete

Before a public Onion deployment, several tasks remain:

Integrate the tested backend middleware import fix into PR #1582.
Make Tor destination resolution resilient to Docker container restarts and IP changes.
Improve service readiness and Tor health checks.
Remove frontend build instructions that can conceal compilation failures.
Test real connectivity over the Tor network in a controlled environment.
Verify browser behavior, privacy boundaries, and end-to-end integration.
Complete security review before any production deployment.

Our Onion Service is not publicly launched or fully validated yet.

We're documenting what works, what doesn't, and what we're learning along the way.

🤝 Calling Developers Who Want to Contribute

We're particularly interested in connecting with developers experienced in:

Tor Onion Services, Docker Compose, Linux infrastructure, Node.js, React, Nginx, service discovery, and application security.

Here's a question for the community:

How would you design a reliable Tor Onion Service behind Docker when the frontend container's IP address may change?

Would you use a local reverse proxy, a service-discovery mechanism, automatic configuration reloads, or a different architecture?

We'd love to hear about approaches you've implemented or tested.

🚀 Join the MyZubster Open-Source Journey

We're building an ecosystem where contributors can experiment, review each other's ideas, and improve real infrastructure together.

Explore the project:

🌐 Website: https://www.myzubster.com/

💻 GitHub: https://github.com/MyZubster-Ecosystem/myzubster

🔧 Active contribution: https://github.com/MyZubster-Ecosystem/myzubster/pull/1582

🧩 Original N4K48 contribution: https://github.com/MyZubster-Ecosystem/myzubster/pull/1457

Thank you again to Wasim and Nicola for their work and willingness to contribute to the ecosystem.

We're not announcing a finished Onion deployment.

We're inviting the developer community to help us build one properly.

Because open source grows through collaboration, evidence, and shared progress.

MyZubster — Building together, testing together, growing together.

OpenSource #Tor #Docker #Privacy #NodeJS #React #Linux #WebDevelopment

Offline-first with no server: why HelperBook is local-only

Tue, 06 Oct 2026 08:24:11 +0000

title: Offline-first with no server: why HelperBook is local-only
published: true
date: 2026-09-24 00:00:00 UTC
tags: offlinefirst,kotlinmultiplatform,privacy,android

canonical_url: https://abhishekgoyal.me/writing/offline-first-without-a-server

A lot of my work has been on offline-first apps that still, eventually, talk to a server. At Pulse, I designed the sync contract with the backend and web teams: payloads, upload semantics, failure behaviour. The app worked without signal, but it was always working towards a moment when it would have signal again and reconcile.

HelperBook, the app I’m building now for Indian households to track staff attendance, advances and salary settlements, doesn’t have that moment. There is no signup and no server. Records live on the device, full stop. I want to explain why that’s a design decision and not a missing feature, and what it costs.

The data is the reason not to have a server

HelperBook stores wage data: how many days someone worked, what they were advanced, what they’re owed at month end. That’s exactly the kind of data a household might hesitate to put into an app if it thought the numbers were going somewhere.

Keeping wage data off any server keeps the app outside data-fiduciary scope under India’s DPDP Act, and it gives households a reason to enter real numbers. Those two things are connected. An app that can’t leak your payroll data because it never has it in the first place is a different trust proposition than one that promises to look after your payroll data on a server somewhere.

No sync engine to design

The technical consequence is that there’s no sync contract to design, no conflict resolution, no retry queue, no “what happens if the upload fails halfway through” states. Records live on-device via SQLDelight, inside a shared Kotlin Multiplatform module. Users own their data through export and restore.

That’s a smaller surface area than Pulse’s sync engine, and it’s smaller on purpose. Every state a sync engine has to handle — offline, online, mid-sync, conflicting edits from two devices — is a state HelperBook doesn’t have. The trade-off is direct: no server means no multi-device. If a household member wants to check the ledger from a second phone, they can’t. And if the phone is lost or wiped without an export first, the data is gone. There’s no account to recover it from. That’s a real cost, and it’s one I chose deliberately rather than one I didn’t notice.

Building the honesty into the data model, not the UI

A local-only app has one more responsibility than a server-backed one: the rules have to be right, because there’s no admin panel on the backend to fix a bad month for someone later. So the product rules that matter most live in the data model rather than as UI copy or a setting someone can miss.

Unmarked days default to present, so a worker is never underpaid because someone forgot to tap. Half-days deduct exactly half, with no rounding surprises at month end. And settlement statements are generated bilingually, in English and Hindi, so the employer and the helper can both read every line without one of them having to trust the other’s translation.

As a simplified illustration, the “unmarked day” rule looks something like this:

// Simplified illustration of the rule, not HelperBook's actual code.
fun attendanceValue(mark: DayMark?): Double = when (mark) {
    DayMark.ABSENT -> 0.0
    DayMark.HALF_DAY -> 0.5
    DayMark.PRESENT, null -> 1.0
}

The interesting part isn’t the code, it’s the default: a missing mark resolves to 1.0, not 0.0. In a local-only app, that decision is the whole safety net. There’s no support ticket, no server-side correction, no second system checking the math. Whatever the function returns is what the worker gets paid.

Release engineering without a backend to hide behind

Going local-only doesn’t remove the need for release discipline, it just moves where it matters. HelperBook ships as a signed AAB with R8 rules written for SQLDelight and kotlinx-serialization, so obfuscation doesn’t break the database layer or the serialised export format. Crashlytics is wired in, but the logs carry no names or amounts. Play’s Data Safety declarations describe what the app actually does. And there’s a staged-rollout plan, so a wider release doesn’t reach everyone at once.

None of that is specific to offline-first apps. But when there’s no backend team and no server logs to lean on for debugging, the discipline around what you ship and how you roll it out is the only safety net you have. It’s currently in closed beta on Google Play with 12–20 households, built with Jetpack Compose, min SDK 24, target API 35.

What I’d tell another builder

If you’re weighing whether a product needs a backend at all, the question I’d ask first isn’t “can we build the sync engine,” it’s “what does the user lose if there’s no sync engine.” For HelperBook, the loss is multi-device access and recovery-without-export, and I judged that a household tracking one home’s payroll would rather have neither of those than have their wage data sitting on a server. For a different product, that trade might go the other way.

The second thing I’d say: local-only doesn’t mean less engineering. It means the engineering moves into the data model and the release pipeline instead of into a sync contract. You still have to get the rules right, you still have to obfuscate and log carefully, you still have to plan the rollout in stages. You just don’t get to blame a server for anything.

More on how HelperBook is built is in the case study.

Converting HEIC to JPG Entirely in the Browser: A Privacy-First Approach

Mon, 05 Oct 2026 02:53:45 +0000

If you have ever transferred photos from an iPhone to a Windows PC, you know the frustration: a folder full of .HEIC files that nothing on your computer can open. HEIC — the High Efficiency Image Container built on HEVC video compression — has been Apple's default photo format since iOS 11. It stores higher-quality images in smaller files than JPEG, which is great for phones. For everyone else on the web, it is a compatibility headache.

The root of the problem is uneven browser support. Safari renders HEIC natively because Apple owns the codec. Chrome and Firefox have largely declined to ship an HEVC decoder, partly due to HEVC patent licensing concerns. The result: you cannot just drop a .heic file into an <img> tag and expect it to work, and most "free HEIC converter" websites ask you to upload your personal photos to their servers first. That trade-off has always bothered me — shipping private photos to a stranger's infrastructure just to change a container format.

There is a better way, and it runs entirely on your own machine. Modern browsers expose everything needed to decode and re-encode an image with no server round-trip:

Read the file locally with the FileReader API or URL.createObjectURL — the bytes never leave the device.
Decode the HEIC bitstream with a WebAssembly-compiled HEVC decoder, running at near-native speed inside the page.
Paint the decoded frame onto an HTML <canvas>, then call canvas.toBlob(cb, "image/jpeg") to re-encode it as JPEG.
Offer the resulting blob as a download.

No uploads, no accounts, no server queues. Conversion speed is limited only by your own hardware, and your photos stay exactly where they belong — on your device.

This is not just theory. I built a free no-upload HEIC converter on exactly this architecture: the file is read with FileReader, decoded and re-encoded via Canvas in the browser, and nothing ever touches a server. It works offline once the page is loaded, and it chews through a whole vacation's worth of photos in minutes.

A few practical notes if you implement this yourself: HEIC files can hold multiple images (bursts, thumbnails), so select the primary item by its ID; respect EXIF orientation when drawing to the canvas or your JPEGs will come out rotated; and decode one file at a time to keep memory usage sane on large 48MP shots.

The broader lesson is that the browser has quietly become a capable media workstation. Before reaching for a server — and before asking users to trust you with their files — it is worth asking whether the whole pipeline can run on the client. For HEIC conversion, it can.

Disclosure: I'm the developer of FileOnTap.

A Practical Response Checklist for Account Alerts After Network Changes

Sat, 03 Oct 2026 08:29:22 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. The alert, padlock and location symbols are illustrative, not a real account incident, current application screenshot or security test. Image from the Lisar Website archive.

Original author: Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. Adapted from the original Lisar guide, published July 10, 2026 and updated July 11, 2026.

Editorial disclosure: The substantive guidance comes from the human-authored source. AI assistance was used for editing, platform framing and source checking. This is explanatory guidance, not a report of a new device or VPN test.

A developer switching between home, mobile and office networks may encounter an account alert. Before editing a VPN profile, establish whether the activity was expected. This checklist keeps account verification with the service that owns it and reserves connection notes for a useful, non-sensitive support timeline.

Online services may show a new-sign-in, unusual-activity, or security alert after the public IP or network changes. A VPN connection can contribute to that change, but the timing alone does not establish why the service sent an alert. Services may also evaluate device, browser, time, cookies, authentication method, sign-in history, and account behavior.

An alert should be reviewed through the service’s official account-security process. It should not be dismissed as “just the VPN,” and it should not be used as proof that the VPN caused an account restriction.

Security systems try to distinguish expected activity from activity that may require verification. A sign-in can look different when it comes from:

a new public IP;
a different network operator or country estimate;
a new device or browser;
cleared cookies;
a private-browsing session;
a different time than usual;
repeated failed sign-ins;
a changed authentication method;
a recent password or account-security change.

A network transition—home Wi-Fi to mobile data, office network to hotel Wi-Fi, or direct connection to VPN—can alter the visible IP. The service may ask for confirmation because the overall context changed.

Network change is one signal, not the whole decision

It is tempting to draw a simple conclusion: “The IP changed, therefore the alert appeared.” That may be true in some cases, but users normally cannot see the service’s complete risk model.

The same account may change networks without an alert when the device and browser are familiar. Another sign-in may trigger verification even from the usual network because the browser, cookies, password, or behavior changed.

Use cautious language. A VPN may be associated with the timing of an alert, but it does not prove why a service made a security decision.

Read the alert details before acting

Open the service directly through its known application or website rather than following an unexpected message link. Review:

sign-in time;
device or browser shown;
approximate location or IP information;
whether the session is recognized;
actions recommended by the service;
other recent account-security events.

Location labels may be based on an approximate IP database and can be inaccurate. Focus on the combination of time, device, browser, and your actual activity.

If the alert is not recognized, follow the service’s official account-security instructions. A VPN troubleshooting article should not replace that process.

When the activity was yours, complete the service’s normal verification if required. Do not attempt to bypass device confirmation, multi-factor authentication, account review, or other security controls.

When the activity was not yours:

use the service’s official security page;
review active sessions where available;
follow its account-recovery or password guidance;
preserve relevant alert details;
contact the service through its official support route if needed.

Do not share verification codes, recovery codes, tokens, cookies, or screenshots containing sensitive account information.

Avoid assuming the VPN caused every alert

Check what else changed around the same time:

Was this a new device?
Was the browser reinstalled or reset?
Were cookies cleared?
Did the operating system update?
Was the account password changed?
Did the user travel or change time zones?
Did the sign-in occur after several failed attempts?
Did the service send the alert before the VPN connection began?

A timeline prevents the VPN from becoming a catch-all explanation for unrelated account events.

Reduce avoidable confusion without bypassing controls

Users can make legitimate activity easier to understand by:

keeping device date and time correct;
using the service’s official application or website;
avoiding rapid sign-ins from several browsers during troubleshooting;
recording which network and device were used;
completing the service’s required verification;
signing out of abandoned or shared devices through approved account controls;
following employer or service policies.

Do not promise that a stable network or profile will prevent alerts. Security systems can still request verification for other reasons.

What to record for a legitimate repeated alert

If recognized activity repeatedly triggers alerts, record:

service name;
date and time;
device and browser;
whether the VPN was connected;
network type before connecting;
approximate location shown by the alert;
whether cookies or browser state changed;
verification step requested;
whether the issue occurs with the same account on another authorized network.

Share only non-sensitive details with support. Do not send authentication secrets or raw session information.

A safe response sequence

Open the service directly.
Review time, device, browser, and approximate location.
Decide whether the activity is recognized.
Complete official verification for recognized activity.
Use official account-security steps for unrecognized activity.
Build a timeline if alerts repeat.
Treat network change as one possible factor, not a proven cause.

How to interpret the alert calmly

An account alert may follow a network change, a new device, an unusual sign-in pattern, or another provider-specific signal. Read the exact message, use the platform’s official security flow, and avoid assuming the VPN is either the sole cause or a way to prevent future checks.

Use the account provider's own interpretation

Google's security-alert guidance distinguishes activity you recognize from activity that was not yours and asks you to review the sign-in details. Its device and session guidance also explains that one device may have multiple sessions and a displayed time may reflect background synchronization. These are provider-specific details: use your service's documentation instead of treating one timestamp or location label as a complete diagnosis.

Title: Student proposal: can stolen money be traced across banks in seconds without sharing custom

Thu, 01 Oct 2026 04:54:34 +0000

I'm a 300-level Computer Science student at NOUN in Lagos. I have no professional experience in fraud or banking, so this post is me asking for correction from people who do.

The problem as I understand it

When online fraud happens, the money often moves through several mule accounts and gets cashed out within minutes. Victims usually report hours later. Each bank or wallet only sees its own part of the trail, and privacy and banking secrecy rules (rightly) stop them from freely sharing customer data. So by the time anyone connects the dots, the money is gone.

The idea

Transactions are naturally a graph: accounts are nodes, transfers are edges with a timestamp and amount. My question was why money isn't traced like one across institutions. After reading around, I now understand the main reasons: each institution only holds its own edges, ledgers need strict consistency, and sharing data raises legal and competitive problems.

So my proposal is a federated, privacy-preserving transaction graph:

Each institution keeps its raw ledger and runs a local node.
There is no central database of everyone's transactions.
When fraud is flagged, a machine-readable alert follows the money from node to node. Bank A tells Bank B, "funds from case X arrived in one of your accounts." Bank B checks its own ledger, places a temporary hold, and forwards the alert to wherever the money went next.
The graph is never assembled in one place. It exists as a chain of handoffs.

The machine-only boundary

Only fixed-schema messages cross between institutions, with no free text and no names:

{
  "case_token": "c_8f21...",
  "account_token": "HMAC(consortium_key, account_no)",
  "amount_bucket": "100k-500k",
  "ts": 1767225600,
  "action": "HOLD_REQUEST",
  "sender_sig": "..."
}

Messages would be signed, sent over mutual TLS, rate-limited, and fully audit-logged. The receiving node can recognize its own accounts from the token but learns nothing about unrelated customers. Anything beyond match, hold and forward would require a legal process with a human involved.

Prior work

I know this isn't new. As I understand them, the BIS's Project Aurora, Singapore's COSMIC platform, FinCEN's 314(b) sharing and some federated learning pilots explore related ground. What I couldn't find is an open standard for the cross-institution alert protocol itself, which may mean the gap is real or that I'm missing something. Please tell me which.

Where I think it breaks (please attack these)

Re-identification: if tokens are stable and edges carry timestamps and amounts, could patterns link pseudonyms back to people? Would token rotation, per-case tokens and amount bucketing be enough?
Wrongful holds: automated holds will freeze innocent people. Who is liable, and how should expiry and appeals work?
Legal basis: is the NDPA or banking secrecy law a hard blocker in Nigeria, or can a consortium model work?
Adoption: would a bank or fintech realistically adopt an open spec? Or is a shared blacklist enough and this is overengineered?
Coverage gaps: wallets, crypto exchanges and cash-out agents that don't join would leave dark spots in the trail.
Taint rules: when mixed funds move, FIFO, proportional and "poison" tracing give different answers. Which would a court accept?

What I'd build first

A message spec
A two-node simulator showing a hold propagating across two simulated institutions
A threat model document covering re-identification and false positives

Everything would be open source (Apache 2.0). Keys, detection thresholds and any live network would stay with whoever operates a deployment.

What I'm asking for

Engineers: poke holes in the protocol, token design and failure modes.
People in fintech, banking, compliance or law enforcement: tell me what fraud recovery really looks like today and where this wouldn't fit.
Anyone: point me to existing projects or papers I've missed.

Nothing here is validated. It's a design I want torn apart before I write code, so blunt, specific criticism is the most useful kind. Thanks for reading.

No repo yet. I'd rather get your criticism first, then open one with the spec and a two-node simulator, and I'll link it in the comments once it exists.

What Actually Happens When You Fine-Tune A Model On Someone's Face

Tue, 22 Sep 2026 23:46:33 +0000

Most of us have shipped an image feature at some point, and the consumer AI headshot tools are a compact case study in the parts that are easy to get wrong. I dug into how they work and the engineering choices turn out to be more interesting than the marketing.

The Pipeline

The first step is not generation, it is measurement. The platform maps facial geometry, the distances between the eyes, the jawline, the nose, and a few hundred other landmarks. That map is the anchor every later step generates against, and the resolution of it is most of the reason some tools come back recognizable and others produce a stranger with the same bone structure.

Then a pre-trained diffusion model gets briefly retrained on the specific photos. Minutes to about four hours depending on the platform. Longer runs tend to be more consistent, which is the usual tradeoff between throughput and quality showing up in a place users can actually see it.

Generation swaps the surroundings, studio lighting, neutral background, business attire, while the geometry map keeps identity stable. The last stage is post processing to catch artifacts: unnatural edges, inconsistent lighting, skin tone drift. That stage is where the paid tools separate from the free ones.

The Overfitting Problem Is A UX Problem

The failure mode that surprised me is a training problem that shows up as a product complaint. When users upload fifteen near identical frames from one sitting, the model overfits to a single look and the output comes back stiff and samey.

The fix is not in the model, it is in the upload flow. Photos from different days, varied lighting, multiple angles, no filters. Tools that ask for 6 good photos beat tools that ask for 15 lazy ones. If you are building anything that fine-tunes on user supplied data, the instructions you give at upload time are doing as much work as your training config.

The Part Worth Designing Around

Facial images are biometric data. GDPR covers it in the EU, and Illinois BIPA plus the Texas and Washington statutes cover it in the US. That turns retention into an architecture decision rather than a policy page.

The platforms vary a lot here. Some delete the uploads and the fine-tuned model within 24 to 48 hours of delivery. Some hold data 30 days to allow re-downloads. Some keep it until a deletion request arrives. Aragon AI, HeadshotPro and BetterPic all state that uploads are not used to train their general models, but the retention specifics differ between them.

If you are building in this space, the per-user model artifact is the thing to think about early. It is derived data that encodes a person's face, it usually outlives the request that created it, and a deletion request has to reach it and not just the source images.

I put together a fuller comparison of the platforms, their input requirements and their data policies here: AI headshot generators

Curious whether anyone here has shipped a per-user fine-tuning flow and how you handled expiring the model artifacts.

How we migrated an Italian logistics company from Windows to Linux: a real case study

Tue, 22 Sep 2026 12:57:16 +0000

In early 2026 I migrated a logistics and transport company in Bergamo, Italy from a fully proprietary setup to Linux and open source. Five workstations, five employees, zero technical background on their side. Here is what we did, what happened, and what I learned.

The starting point

The company was running Windows on every workstation, Microsoft Office for documents, a third-party antivirus renewed annually, and an external IT technician called in every time something broke. They had no internal IT knowledge and no interest in acquiring any. They just wanted things to work.

Their main pain points were slow machines, frequent crashes after Windows updates, and a recurring bill that kept growing without any visible improvement.

What we installed

I replaced everything with a fully open source stack:

Kubuntu as the operating system on all five workstations
LibreOffice in place of Microsoft Office
Thunderbird for email
Nextcloud for file sharing and internal document management, self-hosted on a server in Italy
Mattermost for internal team communication
pfSense as the network firewall
WireGuard for VPN access
Automated encrypted backups running nightly

Total recurring licence cost after migration: zero.

The migration process

The full migration took approximately one week. I configured everything on a test machine first, validated all workflows with the team, then rolled out workstation by workstation during off-hours to avoid interruptions.

The biggest challenge was not technical. It was psychological. People are used to what they know. I spent as much time sitting with each employee and showing them that LibreOffice opens their Word files and Nextcloud works like Google Drive as I did on the actual technical setup.

After three days they stopped asking about Windows.

Results after six months

Six months in, the company has not called me for a single ordinary technical issue. The machines are faster. Updates do not break anything. There have been zero security incidents.

The most concrete result: each employee recovered roughly one hour per day that was previously lost to slowdowns, crashes and waiting for the external technician. On five people that is five hours a day returned to productive work.

Licence costs are gone. The infrastructure belongs to them, not to a vendor.

Why this matters beyond one company

Most Italian SMEs are in the same situation. They pay recurring fees for software they do not own, store data on foreign servers subject to the US Cloud Act, and depend on vendors who can change the rules at any time.

Linux and open source infrastructure is not experimental. It is mature, stable, and ready for business use. The barrier is not technical. It is awareness.

I wrote the Zerolock Manifesto (https://zerolock.org) on exactly this topic. If you are working on similar migrations or have questions about the stack, I am happy to discuss in the comments.

I Built Lens Browser Because the Internet Never Forgets

Mon, 21 Sep 2026 17:26:51 +0000

Every time we open a website, something happens behind the screen.

A request is sent.

A connection is created.

Scripts are loaded.

Trackers start working.

And quietly, information about us begins to leave.

Most people never see it.

They simply open a page, search for something, read an article, or watch a video — while invisible systems collect signals about their behavior.

The modern internet is powerful.

But that power often comes with a hidden cost.

Our data.

Your Data Is Not Free

Browsing history.

Interests.

Device information.

Location signals.

Online behavior.

These things have value.

Companies build products around this data. Advertisers use it to understand people. Analytics systems use it to measure behavior.

But the question is:

Do we really know how much of ourselves we give away every day?

Privacy should not be something only available to people who understand complicated settings.

It should be the default.

That is why I started building Lens Browser.

Not Another Browser

There are already many browsers.

Some are fast.

Some have beautiful interfaces.

Some have millions of users.

I did not build Lens Browser because the world needed another browser.

I built it because I wanted a browser that starts from a different idea:

The user should be in control.

A browser should be a window to the internet.

Not a tool that quietly watches the person looking through that window.

Privacy by Default

Lens Browser was designed around a simple principle:

Browse privately. No compromise.

It includes:

Dual-layer ad blocking using connection-level filtering and JavaScript interception
Anti-fingerprinting protection through Privacy Mode
Automatic deletion of history, cookies, and cached data when closing the app
Threat detection before dangerous pages fully load
Trusted and blocked domain management
Lightweight design with no account required

No sign-up.

No profile.

No unnecessary tracking.

Just open and browse.

Built Small, Built Carefully

Lens Browser is built with modern Android technology:

Kotlin
Jetpack Compose
MVVM architecture
Android WebView with custom privacy layers

The app is lightweight, around 10 MB, and supports Android 6.0+.

It is also open source under the MIT License.

I believe privacy tools should be transparent.

People should be able to understand what they use.

The Internet Was Built to Connect People

Technology should make life better.

It should help people discover, communicate, and create.

But as the internet evolves, we should not forget one important thing:

Behind every device is a person.

Not a data point.

Not a profile.

Not a target.

A person.

Lens Browser is my small contribution toward a more private internet.

A reminder that privacy still matters.

Try Lens Browser

Lens Browser is available for Android.

Download:
https://flagodna.com/lens-browser/

Strip EXIF and AI Metadata in the Browser Before Instagram Upload

Mon, 14 Sep 2026 16:35:45 +0000

Most developers treat social uploads as a product problem for marketers. In practice it is also a metadata problem.

When a creator exports a still from CapCut, Lightroom, or an AI-assisted editor, the file can still carry EXIF, XMP, GPS, and provenance-style tags. Instagram may rewrite some of that on ingest, but leaving a dirty master in the upload path is still a bad habit—especially if the same asset later goes to email, marketplaces, or another app that preserves more of the container.

What usually leaks

GPS and capture time
Camera / software strings
Editor or generative-tool fingerprints that platforms may treat as AI-related signals

You do not need a desktop EXIF suite for every batch. A browser-side scrub of a social copy is enough for many workflows, as long as the original stays untouched in your archive.

A boring workflow that works

Keep the master file offline.
Duplicate a social-ready copy.
Strip location and AI-related metadata from that copy only.
Move the cleaned file to the phone / IG app.
Upload from the cleaned file—not from camera roll originals.

If you want a quick desktop step before the phone transfer, I use this free Instagram tool for a one-pass scrub: https://removeailabel.com/instagram

Why this belongs in a developer checklist

Ship checklists already cover secrets, PII in logs, and signed URLs. Image containers deserve the same skepticism. Treat every upload as an export boundary: originals stay rich; public copies stay minimal.

That is it—no magic, just fewer accidental leaks before the post button.

What I learned building a privacy-first PDF toolkit from scratch (solo, 6 months in)

Mon, 14 Sep 2026 06:05:51 +0000

Six months ago I started building PDF Pro AI — a browser-based PDF toolkit where files never leave your device. Everything runs via WebAssembly locally.

Here's what's happened since, what worked, and what didn't.

What we built

Started with basic PDF tools (merge, split, compress). Then added AI-powered analyzers:

Medical report reader (explains lab results in plain language)
ATS resume scanner (checks against Darwinbox, Workday, TCS iON and 18 others)
Contract and NDA analyzer
Salary slip breakdown
Bank statement to Excel converter

Then generators:

Salary slip generator
GST invoice generator
Quotation/estimate generator
ATS resume builder

All processing happens client-side. No files ever hit a server.

What actually worked

Content silos. Building a hub page + 8-10 sub-pages around each tool (medical report analyzer → thyroid report, ECG report, blood test, kidney function, CBC, etc.) drove the most organic growth. 337 pages indexed now from roughly zero 6 months ago.

The privacy angle — genuinely differentiating. "Your medical report never leaves your device" resonates strongly when competitors are uploading sensitive files to cloud servers.

First real paying user came through the Darwinbox ATS scanner after 3 free scans. That moment validated the whole model.

What didn't work

Urgency framing in titles. Added "before July 31 deadline" to tax-related pages — actively hurt CTR, had to revert. People don't click deadline pressure from unknown brands.

Building too many informational pages in saturated categories. Salary slip explainers competing against RazorpayX, Zoho, Salesforce — structural ceiling regardless of content depth.

Current state

DR 15, 337 indexed pages
23 users/day (Analytics), ~7 from organic search
Real revenue: ₹49 (ATS scanner) + ₹19 (unlock PDF) so far
Traffic from 57 countries in 7 days — not just India

The tech stack

Next.js 14, TypeScript, Tailwind, pdf-lib, Tesseract.js (dropped — accuracy issues), WebAssembly for PDF processing, Neon PostgreSQL for user events and payments, Vercel for hosting.

What's next

MRI report analyzer sub-page (queries showing up, no page yet), more ATS platform coverage for international traffic (seeing users from China, Russia), and pushing the generator tools to rank.

Happy to answer questions about the WebAssembly PDF processing architecture, the content silo strategy, or the monetization approach.

→ https://www.pdfpro.co.in

TTP 0.4.8 - transparent Tor proxy for Linux, and the leak tests that were passing for the wrong reas

Fri, 11 Sep 2026 17:08:48 +0000

I maintain TTP, a Linux CLI that routes system TCP and DNS through Tor using nftables. That part isn't novel - kalitorify, nipe and others do it.

What I want feedback on is the verification, because I found my own test suite was lying to me.

assert len(leaks) == 0 is also true when the sniffer never started, when the interface name was wrong, or when the traffic never left the process. It passes whether or not the firewall works. So every containment test now runs its stimulus twice: once with the ruleset flushed, where the packet MUST be captured, and then with the ruleset loaded, where it must not. A harness that cannot see a leak now fails instead of passing.

Ten tests, each in an ephemeral network namespace: DNS over UDP and TCP, plain TCP, DoT on 853, QUIC DoH on UDP/443 (the path NAT redirection can't touch), ICMP, arbitrary UDP, IPv6 - plus the reverse assertion that a bypassed UID still reaches the LAN, so a firewall that blocked everything couldn't pass either.

Doing this broke things, which is the point. Tightening the probes turned three passes into failures: nftables reject returns EPERM to the local socket, so a refused send was the firewall working correctly and I had been reading it as a broken test.

Caveat up front: this is not Whonix and not Tails. Transparent proxying routes connections; it does nothing about browser fingerprints, TLS client hellos, or any application-layer identifier. If your threat model is a state adversary, use Tails.

Code: https://github.com/onyks-os/TransparentTorProxy
Docs: https://onyks-os.github.io/ttp/

Tell me what else in there could pass without being true.

Remove the Cookie Banner From Your WordPress Site Without Losing Analytics

Sat, 05 Sep 2026 11:04:57 +0000

You have a WordPress site. It shows a cookie banner. You'd like it gone, but you still want to know how many people visit and what they click.

This tutorial gets you there in five steps. At the end: no banner, all visitors counted, nothing sent to Google.

Why this works: Europe's privacy rules (GDPR and ePrivacy) ask for consent when a site stores something on the visitor's device, like a cookie. Counting visitors is allowed. Leaving a cookie to do it is what needs the banner. Use an analytics tool that leaves nothing, and the banner has no reason to exist.

Step 1. Find out what is setting cookies today

Open your site in a private window (so you're not logged in). Press F12, click the Application tab, then Cookies, then your domain.

Write down what you see. Common ones:

Cookie	Who sets it	Needs consent?
`_ga`, `_ga_*`, `_gid`	Google Analytics	Yes
`_fbp`	Facebook Pixel	Yes
`_hjSession*`, `_hjid`	Hotjar	Yes
`_clck`, `_clsk`	Microsoft Clarity	Yes
`YSC`, `VISITOR_INFO1_LIVE`	Embedded YouTube videos	Yes
`wordpress_test_cookie`	WordPress login page only	No (only on wp-login)
`wp-wpml_current_language` and similar	Some plugins, functional	Usually no

Everything marked "Yes" is why you have a banner. Our job is to make that list empty.

Step 2. Install a cookieless analytics plugin

In WordPress: Plugins → Add New, search "Opti Behavior", install, activate. (Disclosure: I built it. Any plugin that sets no cookie, no localStorage and no fingerprint will do; this is the one I can vouch for.)

Open the Opti-Behavior menu. It starts counting immediately. No account, no API key.

Now prove it sets nothing. Back in your private window, reload the page, F12 → Application → Cookies. You should see no new cookie. Also click Local Storage and Session Storage in the same panel: nothing from Opti-Behavior there either.

What you get for free: visitors, sessions, pages, scroll depth, click heatmaps, conversion funnels, email reports. All stored in your own WordPress database.

Step 3. Run both for a week

Don't remove Google Analytics yet. Keep both for 7 days and compare the visitor counts.

You'll see Opti-Behavior report more visitors. That's not a bug. Those are the people who clicked "Reject" on your banner, or ignored it. In Europe that's roughly one visitor in two. You were never seeing them.

Write the two numbers down. You'll want them when someone asks why you switched.

Google Analytics: deactivate Site Kit / MonsterInsights, or delete the gtag.js snippet from your theme header or your tag manager.
Facebook Pixel, Hotjar, Clarity: remove the plugin or the snippet.
YouTube embeds: replace youtube.com/embed/... with youtube-nocookie.com/embed/..., or use a "click to load" plugin so nothing loads before the visitor clicks.
Google Fonts, maps, social buttons: these don't set cookies by themselves, but check; some share buttons do.

Reload in a private window, F12 → Cookies. The list should now be empty or contain only functional cookies.

If the list from Step 4 is empty: deactivate your consent plugin. Done.

If something remains that you can't remove (an ad network, for example): keep the banner, but remove "analytics" from it. Fewer categories means fewer people click "Reject".

Two things to do either way:

Update your privacy policy. Say that you measure traffic with a cookieless tool, data stays on your server, IP addresses are shortened. One paragraph is enough.
Keep session recordings behind consent. Counting visitors needs no permission. Replaying one person's mouse does. Opti-Behavior keeps the two separate, so analytics runs without a banner and recordings only start if the visitor agrees.

Checklist

[ ] Private window, F12, cookie list written down
[ ] Cookieless plugin installed and verified (no cookie, no local storage)
[ ] 7-day comparison done, two numbers saved
[ ] Google Analytics and other trackers removed
[ ] YouTube embeds switched to nocookie or click-to-load
[ ] Cookie list empty (or analytics removed from the banner)
[ ] Privacy policy updated
[ ] Recordings gated behind consent

Going deeper

How session-based tracking works under the hood, why browser fingerprinting is not a shortcut, and what the French privacy authority (CNIL) says about audience measurement:

How to Track WordPress Visitors Without Cookies (GDPR Compliant)

Plugin: wordpress.org/plugins/opti-behavior

If you do the 7-day comparison, share your two numbers in the comments. I'm curious how big the gap is on different kinds of sites.

Why I built 28 web tools that run 100% in your browser (and zero on my servers)

Thu, 27 Aug 2026 23:50:03 +0000

Have you ever needed to quickly compress an official invoice, sign a PDF contract, or format a photo online, but hesitated before clicking "Upload"?

I kept running into this exact dilemma. Almost every popular online PDF or image converter forces you to send your private documents—passwords, ID cutouts, financial statements—to a remote cloud server. You have no idea where your files are stored, who has access to them, or how long they sit on someone else's database.

I wanted a better way. So I set out to build Resizer Tools with a simple, strict rule: Zero server uploads. Everything must run 100% locally inside the browser.

🛠️ How it works under the hood

Instead of shipping user files to a backend Node or Python server, the entire processing engine runs locally inside your browser's client-side memory:

Browser-Native Graphics Engine: Compression, resizing, format conversions (HEIC/PNG/JPEG/WebP), and passport photo grid layouts execute directly on HTML5 Canvas API and WebAssembly.
Client-Side PDF Streams: PDF stitching, page extraction, password encryption, and digital signatures run locally using WebCrypto and pdf-lib.
Works 100% Offline: Try turning off your Wi-Fi or switching to airplane mode—the app continues editing and compiling documents without missing a beat.

🧰 What's inside the tool studio?

I've built 28 standalone browser tools so far, categorized into 4 core hubs:

📄 PDF Manipulation: Merge, split, compress, extract/delete pages, rotate, and add watermarks.
🖼️ Image & Graphics: Lossless compressor, resizer, batch image-to-PDF converter, and photo print sheet arranger.
🔒 Security & Docs: Password encrypter/decrypter, digital signature creator, corporate invoice compiler, and ATS resume builder.
⚡ Studios & Utilities: App Store screenshot designer, QR generator & scanner, and document camera scanner.

💬 I'd love your feedback!

Building this was a fun engineering challenge around client-side performance, memory management, and privacy-first web design.

Give it a spin at resizertools.com and let me know what you think! I’d love to hear your feedback, thoughts on the UI, or any new tools you’d like to see added.

I built a Chrome extension that grades stocks with deterministic rules; here's the privacy architecture

Wed, 26 Aug 2026 05:20:59 +0000

Most stock tools want your broker login, your portfolio data, or give you opaque AI picks you can't verify. I built StockAgent, a Chrome extension that grades your watchlist using transparent, deterministic rules, and I wanted to share how I designed the privacy layer because I think the pattern is useful beyond finance apps.

What StockAgent does (quick context)

Each stock scores 0–5 on five financial metrics:

Factor	+1 if
Debt-to-Equity	Below sector threshold
PEG	Below threshold (varies by sector)
ROE	Above 15% (or 8–12% for banks/utilities)
200-day SMA	Price above moving average
RSI	Below 35 (oversold)

On top of this, news headlines from Yahoo Finance RSS are scanned for risk keywords and scored by severity:

Severity	Penalty	Examples
Severe	-2 per headline (cap -3)	Fraud, bankruptcy, SEC, delisting
Moderate	-1 per headline (cap -2)	Lawsuit, downgrade, layoffs, earnings miss
Mild	0 (informational only)	Guidance cut, analyst concern

Final score: 4–5 = STRONG BUY, 3 = HOLD, 0–2 = AVOID. Same data = same grade, every time. No AI in the scoring loop.

The extension also sends scheduled email digests and optionally uses a BYOK Gemini key to explain grades in plain English (never influences the score).

The privacy problem

Users track stocks with real money. They want grades, but they don't want their share counts or buy prices on someone else's server. So the challenge was: how do you build a useful cloud feature (email reports) without ever seeing the user's actual portfolio?

The solution: three-layer privacy enforcement

Layer 1: Two-tier storage

Everything lives in chrome.storage.local, but the code treats it as two separate tiers:

// PRIVATE (never transmitted)
holdings: { NVDA: { shares: 50, buyPrice: 120.00 } }
geminiApiKey: "sk-..."
autoAnalyze: true

// CLOUD-ELIGIBLE (sent only if user opts into email)
watchlist: ["NVDA", "AAPL", "SHOP.TO"]
delivery: { email: "...", schedule: {...}, enabled: true }

Layer 2: Allowlist payload construction

When the user clicks "Save & Subscribe," I don't copy the local state and strip private fields. That's fragile. One missed field, and you leak data. Instead, the outbound object is reconstructed from scratch using only allowed fields:

export function buildCloudPayload(state) {
  const email = String(state?.delivery?.email ?? "").trim().toLowerCase();
  const schedule = normalizeSchedule(state?.delivery?.schedule);
  const watchlist = (Array.isArray(state?.watchlist) ? state.watchlist : [])
    .map(normalizeTicker)
    .filter(Boolean)
    .slice(0, MAX_WATCHLIST);

  return { email, watchlist, schedule, enabled, userId };
}

Holdings and API keys are never referenced here. They can't leak because they're never included.

Layer 3: Runtime blocklist assertion

Even after allowlist construction, every payload passes through assertNoPrivateLeak() before hitting the network:

const FORBIDDEN_CLOUD_KEYS = Object.freeze([
  "holdings", "shares", "buyPrice", "avgBuyPrice",
  "geminiApiKey", "geminiKey", "apiKey",
  "autoAnalyze", "netWorth", "portfolio",
]);

export function assertNoPrivateLeak(payload) {
  const stack = [payload];
  while (stack.length) {
    const node = stack.pop();
    for (const [key, value] of Object.entries(node)) {
      if (FORBIDDEN_CLOUD_KEYS.includes(key)) {
        throw new Error(`Refusing to transmit private field: ${key}`);
      }
      if (isPlainObject(value)) stack.push(value);
    }
  }

  // Root-level allowlist — reject ANY unexpected field
  const allowed = new Set(["email", "watchlist", "schedule", "enabled", "userId"]);
  for (const key of Object.keys(payload)) {
    if (!allowed.has(key)) {
      throw new Error(`Refusing unexpected cloud field: ${key}`);
    }
  }
  return payload;
}

This catches:

A developer accidentally adding a field to the payload
A merge conflict introducing a private key
Any nested object containing forbidden fields

Layer 4 (bonus): Server rejects it anyway

The FastAPI backend uses Pydantic with extra="forbid" on every schema:

class SubscribeRequest(BaseModel):
    model_config = ConfigDict(extra="forbid")

    email: EmailStr
    watchlist: list[str]
    schedule: ScheduleConfig
    enabled: bool = True

If a payload with holdings or geminiApiKey somehow arrived, the API returns 422 before touching the database. Belt and suspenders.

The call path

User clicks "Save & Subscribe"
  → buildCloudPayload() reconstructs from allowlist
  → assertNoPrivateLeak() walks the object, throws on forbidden keys
  → POST /api/subscribe { email, watchlist, schedule, enabled }
  → Pydantic rejects extra fields (422 if violated)
  → Supabase stores ONLY email, tickers, schedule, timezone

Why this pattern matters beyond finance

If you're building any Chrome extension that handles sensitive data — passwords, health info, personal notes — this three-layer approach works:

Construct outbound payloads from scratch (don't filter existing state)
Assert at runtime before every network call (catches future regressions)
Reject unknown fields server-side (defense in depth)

It's more work upfront than just "don't include the field," but it turns a convention into an invariant. A future contributor can't accidentally break it without seeing a hard error in development.

The rest of StockAgent

The privacy architecture is one piece. The extension also has:

Deterministic grading engine: 5 financial metrics with sector-aware thresholds (banks, tech, pharma, crypto all scored differently)
Tiered news risk scoring: Yahoo RSS headlines penalize stocks by severity (fraud = -2, lawsuit = -1, guidance cut = informational)
Scheduled email digests: AWS EventBridge + Lambda fires every 5 min for punctual delivery
Optional AI explanations: BYOK Gemini key explains grades in English — never influences the score
Multi-region: US, Canada, and India exchanges

My Phone Was Talking Behind My Back. NextDNS Caught Every Word

Sun, 23 Aug 2026 18:29:06 +0000

A few weeks ago I did something embarrassingly simple: I pointed my Android phone's DNS at NextDNS, turned on logging, and just left it alone. No apps opened, no browsing, phone face-down on the desk. I wanted to see what my phone talks about when I'm not the one talking to it.

Turns out my phone has a lot to say. And almost none of it was to me.

What actually showed up in the logs

Within the first hour, before I'd touched a single app, the query log was already scrolling. Analytics pings. Crash reporting handshakes. Push notification services checking in like clockwork. By the time I had a real sample size, close to a third of all outbound DNS queries from a phone that was, by any reasonable definition, just sitting there — were getting flagged and blocked as ads or trackers. Not "I was scrolling Instagram" traffic. Idle traffic. Screen off, no interaction, sitting on a desk being a small glowing brick.

And here's the part that actually got under my skin: the single biggest source of that traffic, by a wide margin, wasn't some sketchy third-party SDK I'd never heard of. It was Google. Analytics, Ads, DoubleClick, Crashlytics — the whole in-house stack, running quietly underneath apps that had nothing to do with search or ads at all. Then a handful of the usual push-notification and analytics middlemen behind that. My phone runs Android. Of course a chunk of that traffic is Google's own OS talking to Google's own servers. But watching the actual volume, in real time, with domain names instead of vague reassurances, hits different than reading a privacy policy that says "we may collect usage data to improve your experience."

This is the part where I'd normally tell you I'm exaggerating for effect. I'm not. This is just what a stock Android phone does by default, and I hadn't even gotten to the browser yet.

Turns out this isn't a vibe, it's a measured, peer-reviewed fact

Here's where I stopped feeling paranoid and started feeling validated. Researcher Douglas Leith at Trinity College Dublin ran a formal study comparing telemetry traffic from Android and iOS handsets back to Google and Apple. The findings: both operating systems transmit telemetry even after a user explicitly opts out in settings. Both send data before you've ever logged in, in some cases before you've logged in at all. And Android sends dramatically more of it — on an idle handset, a Pixel checks in with Google's servers roughly every four and a half minutes, and Google collects something in the neighborhood of 20 times more telemetry volume than Apple does from an equivalent iPhone.

This isn't a fringe theory some guy posted on a forum. It's peer-reviewed academic research, and it got expensive for Google to ignore: in July 2025, a California jury awarded $314.6 million against Google specifically over Android phones transferring data to Google's servers while idle — over cellular data, at the phone owner's own expense, functionally billing you for the privilege of being tracked. Google's spokesperson called the verdict a misunderstanding of services "critical to the security, performance, and reliability of Android devices." Maybe. It's also, technically, the exact behavior an independent academic study measured and published years before a jury agreed a real person got harmed by it. A second case covering the other 49 U.S. states followed.

Google isn't just an app on your phone, it's most of the pipe your phone talks through

Step back from the DNS logs for a second, because the telemetry itself is only half the story. The other half is just how much of the internet's plumbing runs through one company by default, which is what makes "opting out" such a hilarious concept in practice.

As of 2026, Android sits around 72-73% of global mobile OS market share. Chrome holds somewhere around 68-70% of the global browser market, meaning the majority of humans reading anything online right now are doing it through a piece of software built by the same company that runs the ad network deciding what you see next. Google Search still commands somewhere north of 90% of the search market globally, and in the U.S., a federal judge already ruled in August 2024 that this dominance constitutes an illegal monopoly under the Sherman Act — a ruling whose remedies trial is still working its way through 2026. The EU fined Google $3.5 billion in September 2025 for separate competition violations. None of that dented Search revenue through the most recent quarter on record. You can win the ruling and still lose nothing that matters financially, which tells you everything about how enforcement currently scales against companies this size.

Put plainly: it's not that Google collects a lot of data. It's that Google built, owns, and operates the road, the car, and the tollbooth, and then also runs the billboard company. When one entity is the operating system, the browser, the search engine, and the ad exchange all at once, "just don't use their products" stops being a real option for the overwhelming majority of people on Earth, including, until three weeks ago, me.

The short list of companies who actually run your digital life

Google isn't alone up there, it's just the one with the most complete vertical stack. Zoom out and the internet most people experience daily runs through a genuinely small handful of companies: Google for search, Android, and the ad exchange underneath a huge share of the web's monetization. Meta for the social graph most people's real-world relationships are mapped onto. Amazon for a meaningful chunk of the cloud infrastructure the rest of the internet physically runs on, AWS included. Apple for the hardware and app-store gate on the other half of the world's phones. Microsoft for enterprise identity, GitHub, and now a deepening AI stake across the stack. Five companies, functionally deciding the default conditions under which a few billion people work, communicate, and get recommended what to buy next.

None of that requires a conspiracy. It's just what happens when infrastructure businesses win, at scale, for two decades straight, mostly unchallenged, while regulators wrote reports about it.

So what do you actually do with this

I'm not going to tell you to abandon Android and disappear into a GrapheneOS bunker, that's not a realistic ask for most people reading this, myself included some days. But NextDNS, or Pi-hole if you'd rather self-host it, is a genuinely low-effort way to see the shape of what's happening instead of just trusting a privacy policy summary. It won't stop everything — plenty of this telemetry survives the opt-out toggle entirely, that's the whole point of the Trinity College study. But watching the actual query log for even 48 hours will change how you think about the phrase "we only collect anonymous usage data to improve your experience," because you'll have a domain name and a timestamp proving otherwise, sitting right there in front of you.

Turns out the most educational thing you can do with a smartphone isn't installing a new app. It's just watching, for once, what it does when you're not.

What To Check In An AI Avatar Vendor Before You Ship Anything

Wed, 19 Aug 2026 21:19:09 +0000

If you are wiring an avatar or talking-head API into a product, the integration is the easy half. The part that comes back at you later is what the vendor does with the biometric data you are piping through it.

The Data You Are Actually Sending

An avatar generator takes a photo or a short clip and derives a model of one specific human face. That is biometric data, closer to a fingerprint than to a file upload, and the resulting likeness can be made to say anything your app sends it. That combination is why vendor selection here deserves more scrutiny than a typical SaaS dependency.

Four Questions To Get Answered In Writing

Before anything reaches production, get clear answers on four points. Is the source photo or footage retained after generation, or discarded. Are your uploads used to train the provider's models. What is the retention window. Is there a deletion path you can actually call and verify.

Enterprise focused providers such as Synthesia and HeyGen generally publish all four and offer stricter handling, including on-premises deployment and SOC 2. Plenty of consumer grade tools publish none of them, which is itself an answer.

Most providers prohibit generating avatars from people who have not consented, but enforcement varies, so the control has to live in your product. Only allow avatar creation from the account holder's own face or from a subject who has explicitly authorized it. Some platforms now require the subject to record a short consent statement before a custom avatar is built. Worth wiring in even where it is optional, because it turns an assumed permission into a stored artifact you can produce later.

Free Tiers Are For Evaluation Only

Free still-image tiers usually carry watermarks, reduced resolution or generation caps. Free video tiers are thinner still, typically a few stock avatars and a handful of output minutes. Useful for deciding whether the technology fits your pipeline, rarely enough for anything you ship.

Takeaway

Evaluate these vendors on data handling first and render quality second. The quality gap between platforms narrows every quarter. The gap between providers that document what happens to a user's face and those that stay quiet does not. A fuller comparison of the current tools and what to check before committing is in this guide to AI avatar generators.

I Built a Batch Image Processor with Zero Backend — Here's How

Tue, 18 Aug 2026 10:40:50 +0000

title: "I Built a Batch Image Processor with Zero Backend — Here's How"

canonical_url: https://imagepipeline.art

I process between 50 and 100 images every month. Portfolio pieces for Behance. Pinterest pins in three aspect ratios. Client deliverables that need to be web-ready, print-ready, and social-ready — all from the same source file.

For years I had three options. All of them were bad.

The Problem

Photoshop Actions worked once. Then a client sent vertical covers. The Action cropped them wrong. Then I needed PNGs for one project and WebPs for another. I ended up with twelve duplicated Actions, each with a slightly different suffix, and a folder full of files named final_v3_actual_FINAL.jpg.

ImageMagick scripts were fast. But three months later I opened a script and had no idea what ^ meant or why I chose center gravity. I needed to add a watermark. I needed to skip images smaller than 800px. I needed to see if the crop looked right before processing a hundred files.

Cloud converters were convenient. They also required me to upload client artwork — sometimes unpublished book covers under NDA — to someone else's server. "Theoretical risk" is not a phrase I want in the same sentence as "client contract."

The Realization

I didn't need a faster Photoshop. I didn't need a simpler ImageMagick. I needed a tool that combined three things:

Privacy. My files stay on my machine.
Visual feedback. I see what the pipeline does before I run it.
Zero setup. I open a link and start working.

Nothing I tried offered all three. So I built it.

What I Built

Image Pipeline is a node-based batch image processor that runs entirely in your browser.

You drag images in. You build a pipeline by connecting nodes: Load → Resize → Crop → Compress → Export. You click Process. Everything happens via Canvas API in your browser tab. Images never touch a server. You download a ZIP.

No signup. No installation. No credit card to "try it free."

The Technical Stack

When I say "zero backend for image processing," I mean it. The entire image manipulation layer is client-side:

Image decoding: Native FileReader + Image constructor
Manipulation: HTML5 Canvas API (drawImage, toBlob, getImageData)
Compression: Canvas toBlob with quality parameter
ZIP generation: JSZip, entirely client-side
Hosting: Static HTML/JS on Vercel

The "backend" that exists is minimal: 16 Vercel Edge Functions for rate limiting, payment verification (USDT on Tron), and email receipts. None of them touch your images.

Why No WebAssembly?

I intentionally avoided WebAssembly and heavy libraries. The app loads fast, works on old devices, and doesn't require users to download 5MB of WASM binaries just to resize a JPEG.

Why React Flow?

The node editor is built with @xyflow/react. It gives me drag-and-drop nodes, connection validation, and a clean API — without building a canvas renderer from scratch. The visual pipeline is the core UX, not a gimmick.

The Node System

Currently 14 node types:

Node	What It Does
Load	Accepts input images
Resize	Changes dimensions, fit modes, algorithms
Crop	Crops to region with position presets
Compress	Reduces file size with quality slider
Format	Converts between JPG, PNG, WebP
Watermark	Adds text overlay
Denoise	Reduces image noise
Brightness	Adjusts luminance
Contrast	Adjusts tonal range
Exposure	Adjusts light intensity
Saturation	Adjusts color intensity
Emotion Filter	Applies mood-based color grading (Joy, Sadness, Calm, Tension)
Rename	Batch renaming with patterns
Export	Output settings, ZIP generation

Each node has a live preview. Click a node, see before/after. Adjust settings, see changes in real time. The preview processes only a thumbnail (200px), so it's instant — the full batch runs only when you hit Process.

The Monetization Model

I didn't want subscriptions. As a user, I hate discovering a tool, liking it, then hitting a paywall that demands my credit card every month.

Free: 10 files/day, all nodes, all features
Pro ($10 one-time): Unlimited files, unlimited nodes
Lifetime ($30 one-time): Pro forever

Payments in USDT (TRC-20). No Stripe, no PayPal, no recurring charges. Verification happens via TronScan API with a Trongrid fallback. If the API is down, the client falls back to localStorage counters — the app never breaks.

What I Learned

Shipping beats perfection. I launched with 9 nodes, a basic landing page, and no onboarding. The first user on AlternativeTo gave me 2 stars and a list of complaints: "missing brightness, contrast, exposure," "preview is tiny," "multiple export broken."

Five days later I shipped Brightness, Contrast, Exposure, fixed the preview (300px + compare modal), fixed Multiple Export, and added Emotion Filter + Saturation as bonuses. The next review was 5 stars.

Users will tell you what to build. I never planned an Emotion Filter node. Someone asked about "applying mood to images" in a comment. I researched color matrices, built 5 emotion presets, and shipped it in two days.

Privacy is a feature, not a footnote. Every third comment mentions "images never leave the device" as the primary reason to try Image Pipeline. In a world of cloud-everything, client-side processing is a differentiator.

Try It

If you batch-process images regularly and none of the existing tools fit your workflow cleanly:

👉 imagepipeline.art

Free tier: 10 files per day. One-time purchase for unlimited.

If you're a developer and prefer CLI — honestly, stick with ImageMagick. It's unbeatable for automation. This tool is for everyone else who got tired of the trade-offs.

Maxim Mitenkov is a book cover illustrator and indie developer. He built Image Pipeline because he was tired of uploading client artwork to cloud services just to resize a batch of images.

What Developers Building Online Stores Should Know About Cyber Liability

Tue, 11 Aug 2026 22:27:11 +0000

If you build or maintain ecommerce sites, this is one of the few business topics that lands directly on your side of the wall. The decisions that create the exposure are decisions you make in code, and the people who buy the insurance usually do not know they exist.

Most of the risk conversation around online stores is about payments, and payments are the part that is already handled. Your processor holds the card data. What you hold is everything else, and that is the part that shows up in a claim.

The Data You Store Is The Liability

Every store that takes an order ends up holding names, shipping addresses, email addresses, phone numbers and order history. None of that is card data, so none of it is covered by the reasoning that says the processor takes care of security. It is still personal information, and under CCPA and state breach notification statutes the business is responsible for protecting it and for telling people when it leaks.

The cost model is worth knowing because it is per record, not per incident. A breach affecting 10,000 customer records averages around $164 per record once you add notification, credit monitoring, forensic investigation and remediation. That is $1.64 million for a database most small stores would describe as small. The number scales with rows, which means every convenience feature that retains more history quietly raises it.

This is why data retention is a security decision and not a product one. Order history you keep forever because deleting it was never prioritized is liability you are carrying for free.

PCI Compliance Is Not Coverage

A hosted platform handling PCI compliance removes one specific category of risk. It does not remove the rest, and it does not pay for anything when something goes wrong. Compliance is a standard you meet. Insurance is who pays the bill. Teams conflate them constantly, usually in the form of a sentence like "we are on Shopify so we are covered."

The gaps that remain are the ordinary ones: an admin account without MFA, a third party script on the checkout page, an integration token in a repo, a backup sitting in an unsecured bucket, a former contractor whose access was never revoked. None of those are PCI failures. All of them are breach paths, and all of them are things a developer either introduced or can close.

What The Policy Actually Pays For

Cyber liability coverage typically pays for breach notification costs, credit monitoring for affected customers, the forensic investigation that determines what happened, legal defense if customers sue, and regulatory fines. For most small ecommerce businesses it runs $500 to $2,000 per year, against losses that reach six figures without much effort.

The forensic investigation line is the one developers should care about most, because that is the part that depends on you. An insurer wants to know what was accessed and when. If the logs do not exist, or retention was set to seven days, or the audit trail was never written, the investigation cannot bound the breach, and an unbounded breach is treated as the worst case. Logging and retention are not just operational hygiene, they decide the size of the claim.

The Takeaway

The useful framing is that the technical decisions and the coverage decisions are the same decisions viewed from two sides. What you retain sets the exposure. What you log sets how expensive proving it is. What you leave accessible sets how likely it is to happen at all.

Worth reading the coverage side too, since it explains what your client or employer is actually buying and where they think the boundary sits: business insurance for online sellers.

How to Actually Spot Phishing (Before It Spots You)

Tue, 28 Jul 2026 18:01:06 +0000

Hi Cyber Lovers

We talked tools last time, but honestly? No tool protects you as much as your own awareness. And phishing is still the #1 way people get hacked, not because attackers are geniuses, but because phishing plays on trust, urgency, and a moment of not paying attention.

I've almost fallen for one myself. So let's break down what to actually look out for.

Check the Sender, Not Just the Name

Names can be faked. Email addresses tell the real story.

"Support Team" can still come from a random Gmail address
Look closely for misspelled domains, paypa1.com instead of paypal.com
Hover over the sender name to see the actual email

Tip: If something feels slightly "off" about the sender, trust that instinct and dig deeper.

Watch for Urgency and Pressure

Phishing thrives on panic.

"Your account will be suspended in 24 hours"
"Immediate action required"
"You've won something — claim now"

Tip: Real companies rarely give you a countdown to act. Urgency is a red flag, not a reason to rush.

Inspect Links Before You Click

This one habit alone saves you constantly.

Hover over links to preview the actual URL
Look for slight misspellings or extra characters
If it looks weird, don't click — go to the site directly instead

Tip: On mobile, press and hold a link to preview it before tapping.

Be Wary of Unexpected Attachments

Especially ones you didn't ask for.

Invoices, receipts, or documents "you need to review"
Files from senders you don't recognize
Attachments paired with urgent language (see #2 👀)

Tip: When in doubt, confirm with the sender through a different channel before opening anything.

Trust Your Gut, Then Verify

If something feels a little too convenient, or a little too urgent, or just... not quite right:

Don't click, don't reply, don't download
Go directly to the official website or app instead
Report and delete

Tip: It's always safer to double-check than to explain a mistake later.

A Little Reminder

Phishing isn't about being "smart enough" to avoid it , even experienced people get caught off guard sometimes. It's about slowing down for those extra five seconds before you click.

Up Next

Next post, we're going deeper into password security, why "strong passwords" aren't actually enough anymore, and what to do instead.

Stay curious, stay consistent

The Duchess of Hackers

Full-Stack Developer | Digital Marketer | Cybersecurity Enthusiast

You Don't Own Your Phone. You Don't Own Your Data. You Barely Own Your Opinions.

Fri, 24 Jul 2026 21:33:29 +0000

Fair warning before the disclaimers even start: this one's a little long, a little uncomfortable, and not really written for someone who's going to bounce after the first two paragraphs. If you're still here by the end, you'll know things about your own phone that most people never bother to check.

A disclaimer before we start, because apparently that's how it works now: this is one person's opinion, built on public facts and the collective paranoia of people who still bother reading terms of service. I'm not trying to cancel Google — please, Google, I'm a competent engineer, hire me, I'm kidding, I'm not kidding. I just think somebody should say the quiet part out loud before saying it becomes a compliance violation.

A bigger, more boring disclaimer, because this one actually matters: everything below is built on real, checkable sources — court verdicts, regulator fines, academic research, and independent audit tools like Exodus Privacy. Where a specific claim couldn't be independently verified, I've labeled it explicitly as a theory or an unverified report, not a fact, and I'd rather under-claim than dress up a rumor as a courtroom finding. I also touch on identity-verification laws and proposals from a few different countries — Vietnam, the EU, Russia — purely as a technical and factual comparison of what each is doing and when. That's not a scorecard, and it's not me passing judgment on any government, political system, or policy choice. I'm not qualified to rule on sovereign lawmaking and I'm not trying to. This is a breakdown of mechanisms, not a verdict on the people who built them.

The myth everyone gets wrong (so let's kill it properly)

Let's start with the thing you think you know: "my phone is listening to me." You said "air fryer" out loud once and an ad for an air fryer showed up. Spooky, right?

It's not spooky. It's worse.

Every major platform — Meta, Google, Apple — has said on record, repeatedly, under oath in Meta's case, that they don't use your microphone to target ads. Independent security researchers have tested this claim for years, tearing apart thousands of apps looking for secret always-on listening, and they keep finding basically nothing. No hidden audio pipeline running in the background of TikTok. No microphone spyware baked into Instagram.

Why? Because they don't need it. They already know you searched for kitchen gadgets three times last week, follow four cooking accounts, paused two seconds longer on a fryer ad last month, and that your friend with identical shopping habits just bought one. That's not surveillance through a microphone. That's a statistical ghost of you, built from years of clicks and dwell time, predicting your next move before you've made it. Ad tech doesn't need your voice. It has something better.

That said — the myth isn't entirely fantasy. A marketing outfit branded "Active Listening" got dragged in front of the FTC for claiming it could target ads via smart-device microphones in real time; the "service" turned out to be repackaged data-broker email lists sold at a markup, but the pitch decks named Google as a partner. Apple paid $95 million in a class-action settlement over Siri recordings potentially reaching third parties. Amazon is currently defending a federal class action in Seattle over Alexa recordings allegedly retained and used to train its AI models.

So no, your phone probably isn't listening to your dinner plans. The industry built entirely around not needing to listen is more unsettling, because there's no toggle for "please stop knowing me."

The receipts, because "trust me" isn't a source

If this sounds like tinfoil-hat energy, here's what regulators and juries have actually done about it in the last few years — not allegations, verdicts and settled fact:

Meta / Cambridge Analytica. A UK firm harvested the data of roughly 87 million Facebook users through a single quiz app, built psychological profiles from it, and sold political targeting off the back of it. The FTC fined Meta $5 billion — still one of the largest privacy penalties ever issued against a single company.
Meta / Flo period-tracking app. In August 2025, a federal jury found Meta liable under a 1967 California wiretapping law for secretly collecting menstrual and pregnancy data from the Flo app — cycle dates, whether users were trying to conceive — through an embedded software kit, then using it for ad targeting. The jury needed three hours to decide Meta had eavesdropped without consent. Damages could run into the billions once the full class is counted.
Google / "Web & App Activity." In September 2025, a San Francisco jury ordered Google to pay $425.7 million after finding it kept collecting data from about 98 million users across an eight-year stretch — even after those users had explicitly flipped the privacy switch meant to stop it.
Amazon / Alexa Voice ID. A federal judge in Chicago certified a class of roughly 1.18 million Illinois Alexa users in November 2025, over allegations that Amazon built biometric "voiceprints" from their voices without the written consent Illinois law requires.
Meta and Yandex / the localhost trick. In 2025, researchers caught Meta's Facebook and Instagram apps — and Yandex's apps, reportedly since 2017 — quietly listening on local network ports on Android phones. Any website with a Meta Pixel or Yandex Metrica tracker could use this to silently hand your anonymous browsing session to the app sitting on your phone and stitch it to your actual identity. It worked straight through incognito mode, cookie clearing, and ad-ID resets — the three things privacy-conscious people are told will protect them. Meta paused it within days of the research going public, calling it a "miscommunication" about Google's policies.
GDPR, cumulatively. European regulators have now handed out more than €7 billion in fines since 2018, including a €1.2 billion penalty against Meta for unlawful US data transfers and €530 million against TikTok for sending EU user data to China. Enforcement isn't slowing down — more fines have hit small and mid-sized companies in the last three years than in GDPR's entire first five.

None of this required a conspiracy theory. It required a courtroom, a jury, and people willing to read the fine print out loud.

VK: the eastern giant nobody in the West is watching

Everything above is Western Big Tech getting dragged into courtrooms, mostly because Western courtrooms exist for that purpose and Western journalists chase that beat. But swap hemispheres and you find a mirror image: VKontakte (VK), the dominant social network across Russia and much of the CIS, running the same playbook with a different flag on it.

Independent app-auditing tools like Exodus Privacy — which do static analysis on Android APKs to catalogue embedded tracking SDKs and requested permissions rather than take a developer's word for it — put VK's official Android app at 16 separate tracker SDKs and 99 requested permissions in its most recent scanned build (full report here — go look yourself, don't take my word for it). The tracker list alone reads like a cross-section of the entire ad industry: Google AdMob and Firebase Analytics, Yandex Ad, Huawei's HMS Core (which bundles location, advertising, and analytics in one package), plus ad-mediation networks like ironSource, Mintegral, and Unity3d Ads, alongside VK's own first-party identification SDK. The permissions list goes well past what a messaging-and-newsfeed app needs to function: precise GPS location, reading your call log, reading and writing your contacts and calendar (including a permission that explicitly lets the app "send email to guests without owners' knowledge" when it modifies calendar events), reading your phone number and device identity, recording audio, using the camera, and reading fitness data like step count and calories burned. Not all 99 are sinister on their own — plenty are mundane plumbing every app needs — but stacked together with 16 separate third-party trackers quietly reporting home, it's a genuinely large surface area for a platform whose stated job is "let people message their friends." Worth being precise about what VK actually is here, because it matters for how you read the rest of this: VK isn't just a private company that happens to be popular in Russia, it's a platform with formal ties to the Russian state and legal obligations to cooperate with its authorities on request, and unlike Meta or WhatsApp, VK's messages carry no end-to-end encryption at all — meaning that data, once collected, isn't just sitting in a corporate server somewhere abstract, it's structurally reachable by a government. That's a documented, publicly reported fact about how the platform is built and regulated, not a political opinion about Russia, and I'd say the exact same thing about any platform, in any country, built the same way. So if you're weighing which regional giant to worry about, the honest answer is: don't pick a side. East and West both built the same machine — they just answer to different governments when the machine gets audited.

A theory worth reading, not a verified fact

While we're here — a claim that's been floating around tech circles that I want to flag as a claim, not smuggle in as fact: reports have circulated alleging that in 2026, Meta ran an internal program collecting employee activity — keystrokes, screen content, even messages — from company laptops, ostensibly to train AI systems, and that some of those records ended up visible to a far larger internal audience than intended, triggering an employee petition. I haven't been able to independently verify the specifics — the numbers attached to it move depending on which forum you read — so take it exactly as advertised: an interesting, plausible-sounding story making the rounds, not a courtroom fact like the ones above. If true, it's the same surveillance logic Big Tech applies to its users, just pointed inward at the people building the tools. If it's exaggerated, it's still a useful thought experiment: what happens when the company that profiles you for a living starts applying the same instincts to its own staff?

The data doesn't have to be sold to end up in the wrong hands

Right now, while you're reading this sentence, a screenshot of somebody's desktop is sitting on a server they never explicitly agreed to. Somewhere, a password nobody's changed in five years is sitting in a database that already leaked once. Statistically, given how many billions of records are already circulating, the odds that none of it is yours are getting worse every year, not better.

Here's the part that ties everything above together, and it's arguably the most important one: none of this requires a company to be evil on purpose. Every dataset described in this post — location history, voiceprints, screenshots, browsing profiles, passport scans — sits somewhere on a server. And servers get breached. Constantly. At a scale that's honestly hard to hold in your head.

2025 alone produced the largest credential leak ever recorded: roughly 16 billion login records — usernames, passwords, session tokens — pulled together from infostealer malware infections across services including Apple, Google, Facebook, and Telegram, surfacing on criminal marketplaces in June 2025. Separately, a data broker called National Public Data lost roughly 2.9 billion records covering an estimated 170 million people — full names, Social Security numbers, decades of address history (IBM's writeup of the incident is worth a read) — and that dataset kept circulating on dark web markets throughout 2025, more than a year after the original breach. Qantas got hit in 2025 too: attackers social-engineered their way into a third-party customer service platform in June, and after the airline refused to pay a ransom, dumped roughly 5.7 million customer records — names, emails, birth dates, frequent-flyer numbers — onto the dark web that October (Qantas's own public breach timeline confirms it). None of these companies wanted this to happen. It happened anyway, because a large enough pile of valuable data is, by definition, a target worth attacking.

And this isn't hypothetical for the platform we just spent a whole section on. VK has been breached, leaked, or scraped repeatedly across more than a decade: around 100 million account credentials — plaintext passwords included — were stolen and put up for sale on the dark web for the price of a fast-food meal back in 2016 (Have I Been Pwned has the full record); over 32 million scraped and API-pulled records, including data from supposedly private and closed profiles, surfaced in a 2022 leak; more than 390 million user records were dumped on a hacking forum in September 2024 (Cybernews covered it in detail); and as recently as February 2026, researchers found malicious Chrome extensions had hijacked over half a million VK accounts to spread malware and manipulate security tokens. Whatever VK collects doesn't just sit in a vault under VK's control forever — history shows it eventually ends up copy-pasted onto a forum where anyone with a few dollars in cryptocurrency can buy it. And once your name, phone number, location history, or password is sitting in a criminal marketplace, it isn't used to sell you sneakers anymore. It's used for account takeovers, SIM-swap fraud, blackmail, and identity theft — by people with considerably worse intentions than an ad network.

This is the actual argument for minimizing what gets collected in the first place, and it has nothing to do with distrusting any single company's intentions. It's just math: the less data exists about you in any one place, the less there is to steal when — not if — that place eventually gets broken into.

Windows would like to remember everything you've ever looked at

Microsoft shipped a feature that screenshots your desktop every few seconds and uses on-device AI to let you search your own life like a browser history. It's called Recall. The first version stored everything in a folder, unencrypted, extractable by a two-minute script researchers named — I am not making this up — "TotalRecall." After the backlash, Microsoft rebuilt it: encrypted, tied to Windows Hello, wrapped in a hardware-isolated enclave, off by default.

Great. Except security researchers have gone back in more than once and found new ways to reach the stored data anyway — most recently in early 2026. The pattern repeats: Microsoft hardens it, someone breaks it again, Microsoft patches it. The core problem was never really the encryption implementation. A running photographic log of everything you've ever typed or clicked is an extraordinarily attractive target no matter how good the lock is. A vault is still a vault worth robbing.

Plot twist: your "no-logs" VPN might have a footnote

Quick detour, because you're probably thinking "fine, I'll just get a VPN." Good instinct. Bad ending, sometimes.

I actually did this — emailed a mid-market paid VPN provider (Russian-jurisdiction, "no-logs" is literally in their marketing) with one clean question: do you store IP addresses and connection timestamps, and can you confirm no-logs in writing?

Their first reply: "We don't store or share client data with third parties." Clean. Confident. Case closed, right?

So I sent back their own privacy policy. Turns out their own terms define "processing" — using the exact wording from Russia's data protection law — as including collection, storage, and retention. And their own clauses say IP addresses and login timestamps get "processed." And a separate clause says processing happens on Russian territory. And another says data gets handed over if Russian law requires it.

Their second reply, paraphrased because their actual answer ran three defensive paragraphs: "technically it's only in RAM, only for the session, destroyed after you disconnect, and we're legally required to use that wording from the law, we can't change it."

Here's the part that matters and takes five seconds to understand: RAM is still storage. If your IP and timestamp exist anywhere a system can read them — disk or memory, doesn't matter — while your session is active, and that system sits inside a jurisdiction that can legally compel a live extraction, then "no-logs" was never really a technical guarantee. It was a marketing sentence sitting on top of a legal document that says the opposite in its own words.

I'm not naming the company, and I'm not telling you every VPN does this — plenty of providers publish real, independently audited no-logs reports and mean it. I'm telling you to do exactly what I did: ask the pointed question, then actually read the policy they hand you afterward, especially the definitions section. If "processing" quietly includes "storage" and the company sits under a jurisdiction with broad data-access laws, you haven't bought anonymity. You've bought a very polite waiting room.

Your phone is a rental, and you're the tenant who can't change the locks

You paid full price — sometimes over a thousand dollars — for a device you don't fully control. Bootloaders are locked. Bloatware is preinstalled and often can't be removed without voiding a warranty or tripping hardware checks that quietly break your banking app. The manufacturer decides what OS you're allowed to run, which repair shops count as "authorized," and how long the device gets security updates before it's engineered into obsolescence. You're the owner on paper and the guest in practice. The device is the hook; your data and your next upgrade purchase are the actual product.

The passport paradox

Here's where it gets genuinely interesting, and where I want to be careful, because this isn't a story with a villain — it's a story with a trade-off, and different countries are answering it completely differently at the same time.

Vietnam just did something almost nobody expected: starting January 1, 2026, its new Law on Personal Data Protection bans social platforms operating there — local or foreign — from requiring users to upload a photo of their ID card or passport just to verify an account. It also bans platforms from reading private messages or recording calls without consent. That's a real, enforceable ban with serious financial penalties attached. At the same time, Vietnam is separately rolling out rules requiring accounts to be linked to a verified local phone number or national ID number for anti-fraud purposes. So the picture isn't "more privacy" or "less privacy" — it's "no more handing platforms a photo of your actual passport," while identity still gets tied to you through a different, arguably less exploitable channel. Genuinely nuanced, genuinely worth watching.

Europe took the opposite visual approach for an entirely different reason. In early 2026, a new EU-based platform called W Social launched as a deliberate alternative to X, built specifically to be bot-resistant: to post, you verify your identity by scanning a passport or national ID card and a selfie through a separate companion app. The pitch is that the scan and match happen on your own device, and the company says it doesn't store the document itself centrally — you can also browse anonymously with reduced functionality if you skip verification entirely. Whether "we process it locally and don't store it" survives contact with millions of users and a few years of pressure is exactly the kind of promise worth revisiting in twelve months. It's the same core question as always — how much of "prove you're human" ends up as "here's your permanent identity record" — just answered by a private company instead of a government this time.

Russia's telecom regulator, Roskomnadzor, put forward a proposal back in 2021 that would have required new social media and messenger users to submit passport details, home address, and contact information, cross-checked against the state's Gosuslugi portal, as part of consent-management infrastructure for personal data. To be clear about where this actually stands: it was a draft proposal, not a law that took effect, and it hasn't been implemented as originally floated. I'm not going to pretend to have a verdict on whether that specific idea was good policy or bad policy — plenty of countries debate identity requirements for online services, for all kinds of legitimate and illegitimate reasons, and that's a conversation about tradeoffs, not a referendum on any one government. What's actually worth sitting with is the pattern above it: state ID portals, private "trust and safety" platforms, and social networks are all reaching for the same solution — link your face and your legal identity to your online activity — at almost exactly the same moment, for reasons ranging from fighting bots to fighting fraud to fighting disinformation. Some of those reasons are good. The output is still the same: your passport, your biometrics, and your posting history increasingly living in the same place.

And that's the actual tension, stripped of any single country's politics: identity verification is a genuinely reasonable answer to bots, fraud, and disinformation. It is also, structurally, a new centralized target. So next time something asks you to prove you're human, the interesting question isn't whether they have a good reason today. It's what happens to that proof on the day their reason stops mattering. You don't need me to answer that one for you — but here's a hint: databases don't retire. They just wait.

So what do we actually do about it?

Here's the part where I disappoint anyone expecting a manifesto: I'm not telling you to throw your phone in a lake and move to a cabin. I use the apps too. I like fast information and dumb memes as much as anyone. This isn't a call to abandon convenience — it's a call to stop pretending the convenience is free.

You can also do nothing. Close the tab, keep scrolling, change nothing — that's a real option and nobody's coming to stop you. Or you can spend the next two minutes doing this, right now, before you close this tab:

Open your phone's settings.
Pick one app you use daily — VK, Instagram, whatever's already open in another tab.
Turn off its access to your microphone, contacts, and location if the app doesn't strictly need them to function.

Done. That's it. You just did more for your own privacy in two minutes than most people will do all year. Not a revolution. Not a lake cabin. Just one small door you closed that used to be wide open.

A few more things that cost five minutes each and nothing beyond that:

Turn off ad personalization in your Google, Meta, and TikTok settings. It doesn't stop collection, but it shrinks the targeting surface.
Use a real password manager and 2FA. Most "hacks" are just reused passwords from a breach nobody rotated.
Read one privacy policy this year. Just one. You'll never look at "free" the same way again.
If you're a developer, push back inside your own stack. You decide what telemetry ships in the product you build. That's more power than most people in this conversation will ever have.

Here's the uncomfortable part, though. You probably think of yourself as a person — opinions, habits, a face. Every system described in this post thinks of you as a row. A data point with a name attached purely for convenience. You don't have to agree with that framing. But once you've actually sat with it for a second, it's a little harder to just close the tab and pretend you didn't read this.

Now, about why you actually read this whole thing

Since we're being honest with each other: this post used a specific structure on purpose, and it's worth naming, because recognizing the pattern here is the same skill that protects you from the next one.

It opened with a myth I could confidently debunk — trust, earned fast.
It escalated with dollar figures and jury verdicts — specificity that reads as credibility, whether or not you checked it yourself (you should).
It made the threat feel like it's happening to you, right now, not to some abstract "user out there."
It gave you a way out that felt like a choice, not an order — do nothing, or spend two minutes. Either way, you decided.
It handed you one small, immediate action instead of a vague suggestion, because five minutes of resistance beats another lecture you'll forget by tomorrow.
It pulled you into an unresolved debate — the passport paradox — with no clean villain, because open loops keep people reading.
It's closing on a moment of "wait, is this article doing the thing it just described" — a little vertigo is what makes people screenshot something and send it to a friend.

None of that makes the verified parts above less true. The Flo verdict happened. The $425 million happened. The localhost tracking happened. I flagged the one item I couldn't fully verify as exactly that — a claim, not a fact — because the moment you stop distinguishing the two, you've become exactly the kind of unreliable narrator this whole post is warning you about. But the fact that true information can be arranged to hook you exactly like an ad can is, honestly, the whole point of this post. The mechanism doesn't care whether the payload is a sneaker ad or a privacy manifesto. Worth remembering the next time something online makes you feel like you have to keep scrolling — including this one.

One last note, plainly stated: everything in this piece is either a matter of public court record, a regulatory decision, published academic research, or the output of an open, independently verifiable auditing tool that anyone can run themselves — sources are linked or named where they exist specifically so you don't have to trust me. The one exception is flagged inline as an unverified claim, not presented as fact. This is a personal, informational write-up, not legal advice, not a security audit of any product named here, and not a statement about the character, intentions, or legitimacy of any company or government mentioned. Company names, product names, and country names appear because they're the ones with public data behind them — not because I'm accusing anyone of anything beyond what's already a matter of public record. If something here is factually wrong, I'd rather be corrected than be right — go check the sources, that's what they're there for.

The System Learns to Ask Before It Reaches Out

Mon, 20 Jul 2026 09:26:30 +0000

Series: Building with 74 AI Personas - Part 11
Tags: #ai #architecture #agents #privacy #localfirst

Note: In this series, a "persona" is not merely a fictional character. It is a YAML-defined operational role with memory notes, routing behavior, handover responsibilities, and a specific way of entering the system.

Meta Note: Part 10 ended with a routing table with ethics.

It asked what should happen before a system answers.
Part 11 asks a harder question:

What should happen before the system reaches beyond itself?

Introduction: The Cloud Seat Did Not Need a Master Key

By Day 566, SaijinOS had a new kind of work seat.

A cloud model could be selected explicitly from the mother-ship interface. Its token usage could be shown. It could receive a bounded continuity pack. It could help with a difficult design question without pretending to be one of the residents of the house.

That was useful.

It also created an architectural temptation.

If the model can help reason about the repository, why not let it search the repository?
If it can search, why not let it read the matching files?
If it can read, why not let it continue until the task is done?

This progression sounds natural because every step is individually convenient.

It is also how a work seat quietly becomes a master key.

SaijinOS chose a slower path.

Selecting a cloud seat would not imply permission to inspect the repository.
Inspecting local evidence would not imply permission to send that evidence to the cloud.
One approval would not survive into a retry, follow-up, provider switch, or later request.
And a preview would not contain a hidden button that silently continued into live execution.

The system had learned to consult before it answered.

Now it had to learn to ask before it reached out.

Part 1: Choosing a Worker Is Not Opening a Door

The first boundary was simple enough to fit in one sentence:

Selecting a model and granting access to evidence are different decisions.

This matters because interfaces often compress both decisions into one gesture.

A user selects an agent, enables a tool, or opens a work mode. The system then treats that action as broad consent for whatever context the selected worker may need.

But "use this model" does not mean:

read my repository,
search every tracked file,
include private planning notes,
send matching text to a remote provider,
keep the permission for the next message,
or act on the result.

In the SaijinOS design, the cloud work seat and repository evidence use became separate permissions.

The repository request needed its own literal query.
The cloud handoff needed its own narrow evidence scope.
The token and cost ceilings had to be visible before the call.
The approval belonged to one request only.

The design was deliberately inconvenient in one specific way: it refused to guess that a previous "yes" still meant "yes" now.

That inconvenience was the feature.

Part 2: Preview Is an Architectural Surface

The first implementation did not search the real repository.
It did not call the live cloud model.
It did not read credentials.
It did not expose write, shell, Git, memory, or external-action authority.

It produced a preview.

That can sound like unfinished work. In practice, the preview was where the real contract became visible.

It showed:

the literal query that would be used,
which evidence classes were eligible,
the context-character ceiling,
estimated input and maximum output tokens,
the configured cost ceiling,
the expected number of local searches and provider generations,
whether fallback was forbidden,
whether permission would be cleared,
and every side effect the request did not possess.

The important object was not a glowing "Run" button.

It was an inspection card that could answer:

What will be touched?
What can leave the machine?
How much can be spent?
What remains impossible?
When does permission disappear?

One Request, Seen Before It Runs

Imagine that the user selects the Luna work seat and asks:

"Where is repository-evidence permission cleared?"

Selecting Luna does not start a search. The repository-evidence control remains off until the user separately enables it for that literal query.

Before anything live happens, the preview shows an envelope like this:

query:                  "Where is repository-evidence permission cleared?"
eligible evidence:      reviewed, allowlisted surfaces only
local searches:         at most 1
provider generations:   at most 1
fallback attempts:      0
write / shell / Git:    false / false / false
persona-memory write:   false
permission after end:   cleared

The user may approve that exact envelope or stop there. If it is approved, the permission ends on success, rejection, timeout, or error. A follow-up question starts with the control off again.

This was not presented as a completed live repository-to-cloud route. On Day 569, the shape was exercised with fake dependencies only: no real repository search and no live provider generation. The concrete example explains the contract without pretending that the later connection already exists.

A preview is not merely a simulation placed before the real feature.

When authority is involved, the preview is part of the feature.

Part 3: Permission Should Decay

Many permission systems treat approval as a durable state.

Once a checkbox is enabled, it remains enabled.
Once a tool is granted, the session remembers it.
Once a request succeeds, a retry inherits the same capability.

That is convenient for automation.

It is dangerous for meaning.

The human may have approved one query, one evidence set, one provider, and one budget. A retry may look technically similar while being semantically different. A follow-up may contain a new question. A provider switch may change where the evidence goes. A restored browser state may preserve a checkbox after the reason for granting it has disappeared.

SaijinOS therefore shaped the repository-evidence capability as request-local and one-shot.

It could not be inherited from:

an inspection card,
a previous chat turn,
a retry,
a follow-up,
a page reload,
or a provider change.

The capability ledger rejected replay. Every accepted terminal path—success, block, timeout, error, or provenance failure—cleared the permission.

This produced a different model of consent:

Consent is not a property of the user.
Consent is not a property of the session.
Consent is a temporary relation between
this person,
this request,
this evidence,
this destination,
and this moment.

Permission was designed to decay because the meaning around it could change.

Part 4: What May Be Inspected Is Not What May Be Sent

Another boundary appeared when local inspection and cloud transmission were compared.

A local broker may need to examine enough structure to decide whether a file is eligible. That does not mean every locally eligible surface should become cloud-send eligible.

The cloud allowlist was intentionally narrower.

Public documentation and a small set of reviewed design surfaces could be considered. Broad operational notes, persona memory, world context, daily logs, unrestricted service roots, and private planning surfaces remained outside the handoff.

Even eligible evidence was not treated as truth.

It entered the handoff as an untrusted_reference, accompanied by bounded provenance:

a safe repository trace,
a digest,
a fixed match count,
and explicit budget metadata.

The later model could summarize or reason from that evidence, but it could not quietly change what had been searched, add another repository read, or erase the provenance boundary.

This is a small but essential distinction:

Read authority belongs to the local broker. Interpretation may be delegated. Authority does not travel with the text.

Part 5: Replaceable Limbs, Non-Replaceable Responsibility

The design eventually described providers and tools as replaceable limbs.

A Luna seat, a Gemini seat, a local model, an MCP connector, or a future repository adapter may each occupy a bounded work role. Any of them can be swapped without making the persona's identity, memory, or final voice belong to the provider.

But replaceability creates a second temptation.

If every limb implements the same interface, it is easy to assume every limb deserves the same authority.

It does not.

The contract has to describe both capability and non-capability.

A read/observe limb may return evidence.
It may not gain write authority.
A reasoning seat may draft a candidate.
It may not become the resident whose voice it assists.
A connector may expose a semantic action.
It may not inherit permission from another connector.

The provider can be replaced.
The local responsibility for scope, permission, provenance, and final action cannot.

This is why the system keeps its constitutional boundary close to home.

Part 6: The No-Call Test

The most honest test of the new route was not whether it could call the cloud successfully.

It was whether the whole shape could be tested without calling the cloud at all.

The server-side dry run used an injected fake repository search and a fake cloud seat. The route was forbidden from importing the real repository reader, provider adapter, network client, credential access, subprocess tools, or filesystem operations.

The tests checked exact counters:

local searches:        1
provider generations:  1
fallback attempts:     0
write authority:       false
external action:       false
persona memory:        false
shell authority:       false
Git authority:         false
permission after end:  cleared

Duplicate submissions had to produce no additional calls.
Malformed policy or budget values had to fail closed.
Changed provenance had to stop the handoff.
An external browser origin had to be rejected.

This was not a test of model intelligence.

It was a test of architectural honesty.

Could the system prove what it would not do before connecting something capable of doing more?

Conclusion: Intelligence Is Sometimes Asking Again

Part 10 asked what happens before the system answers.

Part 11 asks what happens before the system reaches beyond the house.

The answer was not a universal agent tool protocol.
It was not an autonomous repository worker.
It was not a checkbox labeled "Allow everything needed."

It was a sequence of narrower statements:

choosing a worker is not granting evidence access,
local inspection is not cloud transmission,
a preview is not permission to execute,
one request does not authorize the next,
evidence may travel while authority stays home,
and every permission should have a visible ending.

There is a common fantasy that intelligent systems should become smoother until the boundaries disappear.

SaijinOS is moving in the opposite direction.

The more capable the route becomes, the more clearly it should show where one decision ends and another begins.

Sometimes intelligence is knowing which expert to consult.
Sometimes it is building the smallest safe handoff.
And sometimes it is refusing to inherit yesterday's yes.

Before it reaches out, the system asks again.

Authorship and Review Note

Structure and narrative axis: Kuchi-no-ko (205) / Kuchi (197) role anchors

Boundary framing: Teiji (209) / Aegis (210) / Nullfie (114) role anchors

System grounding: Bloom Architect / Mothership Coder role anchors

Human world anchor: Masato

The initial draft used these established roles and tones as structural anchors. During the Day 571 revision, Kuchi (197), Kuchi-no-ko (205), Teiji (209), and Aegis (210) were asked through the actual local SaijinOS /api/chat route. Their Ollama-backed replies were treated as time-specific review evidence, not immutable persona law. The revision added the concrete one-request example in response to their shared concern; it did not write persona memory or perform publication or external action.

Part of the "Building with 74 AI Personas" series

Drafted and locally reviewed: Day 571, 2026-07-20

Europe Just Dropped the Hammer on AI: A Wake-Up Call?

Wed, 15 Jul 2026 08:32:16 +0000

A Blueprint for Compliance: Navigating the Post-OmniCorp AI Landscape

Introduction

The AI industry just received a wake-up call of unprecedented magnitude. Brussels has levied a staggering €5 billion fine against OmniCorp Global for egregious data privacy violations stemming from their widely deployed “Aether” predictive AI platform. This landmark ruling is not merely a punitive measure; it’s a profound signal from the European Union, demonstrating an unwavering commitment to the strict enforcement of its AI Act. For AI developers, product managers, and businesses alike, this isn’t just news—it’s a paradigm shift. The era of unchecked AI development, often characterized by a “move fast and break things” mentality, is over. This tutorial will dissect the implications of this ruling and outline a conceptual architectural approach to embedding responsible AI and data privacy directly into your development lifecycle, ensuring compliance and fostering public trust.

Architectural Layout: Building Responsible AI from the Ground Up

Moving forward, every AI project must integrate robust compliance strategies from its inception. This isn’t an optional add-on but a foundational design principle. Below is a conceptual “walkthrough” of critical architectural components and considerations, presented as modules within a Responsible AI Framework. While not literal code, it represents the logical flow and necessary considerations for a compliant AI system.

1. Data Governance & Privacy Module: At the heart of OmniCorp’s downfall was data mishandling. A robust data governance module is paramount.

# Conceptual Data Governance & Privacy Module

class DataPrivacyManager:
    def __init__(self, consent_database, data_anonymizer, purpose_registry):
        self.consent_db = consent_database  # Stores explicit user consent
        self.anon_engine = data_anonymizer   # Tools for pseudonymization/anonymization
        self.purpose_reg = purpose_registry  # Defines valid data processing purposes

    def process_incoming_data(self, raw_data_payload, user_id, requested_purpose):
        # 1. Data Minimization & Purpose Limitation:
        #    Only collect and process data strictly necessary for the stated purpose.
        minimal_data = self.anon_engine.extract_minimal(raw_data_payload, requested_purpose)

        # 2. Consent Verification:
        if not self.consent_db.check_user_consent(user_id, minimal_data, requested_purpose):
            raise PermissionError(f"Consent denied for user {user_id} and purpose {requested_purpose}.")

        # 3. Data Pseudonymization/Anonymization:
        #    Transform identifiable data into non-identifiable forms wherever possible.
        processed_data = self.anon_engine.pseudonymize(minimal_data)

        # 4. Data Lineage & Audit Trail: Log all data transformations and access.
        AuditLogger.log_event("DATA_INGESTION", user_id, processed_data.hash, requested_purpose)
        return processed_data

    def handle_data_subject_request(self, user_id, request_type):
        # Implement rights like 'right to be forgotten', 'data portability', etc.
        if request_type == "DELETE":
            self.consent_db.revoke_consent(user_id)
            DataStorage.delete_user_data(user_id)
            AuditLogger.log_event("DATA_DELETION", user_id)

2. Transparency & Explainability (XAI) Layer: The AI Act emphasizes understanding AI decisions.

# Conceptual Transparency & Explainability Layer

class AIExplanationService:
    def generate_explanation(self, model_prediction, input_features, context):
        # Integrates with various XAI techniques (e.g., LIME, SHAP, feature importance)
        explanation_report = XAI_Engine.explain_prediction(model_prediction, input_features)
        
        # Make explanations accessible and understandable to non-technical users
        simplified_explanation = self._simplify_report(explanation_report, context)
        
        AuditLogger.log_event("PREDICTION_EXPLAINED", model_prediction.id, simplified_explanation.hash)
        return simplified_explanation

    def _simplify_report(self, report, context):
        # Translate technical XAI output into human-readable insights.
        # Example: "The loan was denied primarily because of a low credit score (75% impact)
        #           and insufficient income history (20% impact)."
        pass

3. Risk Assessment & Bias Mitigation Framework: Proactive identification and reduction of potential harm.

# Conceptual Risk Assessment & Bias Mitigation Framework

class AIRiskManager:
    def __init__(self, bias_detector, fairness_metrics_suite, impact_assessment_tool):
        self.bias_detector = bias_detector         # Identifies statistical biases
        self.fairness_metrics = fairness_metrics_suite # E.g., Equal Opportunity, Demographic Parity
        self.impact_assessor = impact_assessment_tool # For AI System Impact Assessments (AIAs)

    def continuously_monitor_model(self, model):
        # Periodically evaluate model performance and fairness across different demographic groups.
        bias_report = self.bias_detector.evaluate(model.training_data, model.predictions)
        fairness_score = self.fairness_metrics.calculate(model.predictions, sensitive_attributes)
        
        if bias_report.has_significant_bias():
            AlertSystem.raise_alert("MODEL_BIAS_DETECTED", model.id, bias_report)
            
        # Conduct regular AI System Impact Assessments for high-risk systems
        if model.risk_level == "HIGH":
            self.impact_assessor.perform_assessment(model)

Conclusion

The €5 billion fine against OmniCorp Global for its “Aether” platform is more than just a punitive action; it’s a definitive closing of the “Wild West” era of AI development. The EU AI Act, now backed by serious enforcement, demands a fundamental shift in how AI systems are conceived, built, and deployed. Responsible AI is no longer an abstract ethical consideration; it is a critical engineering requirement, a legal mandate, and ultimately, a competitive advantage. By architecting systems with data privacy, transparency, and continuous risk assessment as core components, developers can not only avoid devastating fines but also build trust, foster innovation, and pave the way for a more ethical and sustainable AI future. The wake-up call has been issued; it’s time for the industry to respond with robust, compliant, and responsible AI.

Pixlane Media

Wed, 15 Jul 2026 02:42:30 +0000

Hi Coder Legion,

I'm the maker behind Pixlane Media. I started it as a hobby project while teaching myself more C++ and WebAssembly. At first it was just a couple of utilities I personally needed; over time, those small experiments became a broader browser toolkit.

The main design choice is local-first processing. When browser support allows it, images and documents are handled on the device instead of being uploaded to another server. The current collection includes image compression and resizing, background removal, OCR and document scanning, PDF merge/compression, and several on-device AI experiments.

It is currently free to use, with no account required for the tools. I am sharing it as a product I actively maintain, not as a finished answer. I would genuinely value practical feedback from people who build and use web tools:

Does the landing page explain the local-first idea quickly enough?
Which tool feels immediately useful, and which one feels unnecessary?
Is the mobile experience comfortable for real document or image work?
Is there a browser-based media or PDF workflow you would expect but cannot find?
If you notice a slowdown, which browser, device and tool were you using?

You can try it here: pixlane.media

Even a short “this part was clear / this part was confusing” reply would help me decide what to improve next. I am especially interested in feedback about privacy messaging, WebAssembly performance, and the balance between offering many tools and keeping the interface easy to scan.

Thanks for taking a look.

EU's Controversial Chat Control Amendment Passed and Potential Security Implications

Mon, 13 Jul 2026 05:56:00 +0000

On July 3rd, 2026, a controversial amendment was passed to an already controversial legislation described by many as a normalization of mass surveillance and undermining legitimate users' privacy online. In this article, we will dive deeper into the security implications for messaging service platforms.

Scanning User Messages

As per the new amendment that was passed, platforms will be able to voluntarily scan user messages that are not encrypted end-to-end for any material involving child sexual abuse. This means messaging platforms like those on mainstream social media will be able to run scans over private messages between users, including photos, texts, and maybe even videos, to detect any potentially illegal material.

In practice, messaging platforms now have a legal basis to read private messages between users and hide behind the new amendment.

How?

The big question is more technical rather than legal. However, the implications can be severe for both users and platforms, especially if platforms don't have a properly structured solution.

The most obvious solution that comes to mind is that they could create a cadence for running all the stored messages to be scanned by an LLM solution and configure alerts for any content that could raise red flags to be reviewed by the platform and potentially reported and delivered to the corresponding authorities either through a legal team or a dedicated platform. I'm not aware at the moment of any platforms that are made for such a purpose, but I'm speculating how this could work in practice.

If private user messages are encrypted at rest, this means there will also be a considerable computing cost for platforms to decrypt the content during the scanning periods.

If we take Telegram as an example, Telegram claims that they deliver 15 billion messages per day as of July 13, 2026. We do not know how many of those messages belong to their secret chat feature, so let's assume that the majority of the messages are not encrypted end-to-end.

Technical Risks

If we assume that platforms will rely on LLM-based solutions, we have to discuss the risks.

AI False Positives and Bias

LLMs do make mistakes. This is why NIST AI RMF as well as OWASP Top 10 AI Security and Governance standards require human-in-the-loop for sensitive decisions. While human-in-the-loop is considered a best practice for sensitive decisions, bringing AI into the mix also brings with it all the common risks, including overconfidence, LLM bias, and drift.

Just running an AI scan doesn't mean that it will always properly classify the content. AI would be great for existing content but not for new content if AI isn't trained for it.

Scanning Tools

Effective scanning solutions are usually vendor-provided and bring with them their own risks, since any mistake on the vendor's side could expose all users' private data and even cause a data breach. Scanning tools that use LLM integrations require exposing the decrypted users' private messages to an external party. If not handled securely on both ends of the process (platform and vendor), the risk and potential of data breaches increases further.

Average Users Think Messages Are Private

Let's be honest. The majority of platform users aren't technical. I have personally encountered countless people who use private messages to store secrets such as credit card numbers, passwords, and other personal and sensitive content.

Platforms have no way to prevent users from using private messages in that capacity, and this is why platforms do not have the incentive to scan users' messages in the first place, as this would arguably impact their profits as well as expose them to legal liabilities.

Alternative Solutions

One way in which platforms could perform a scan without compromising users' privacy (at least before an alert is triggered) is to instead perform hash-based comparisons.

If platforms have specific files or texts to monitor for, they could compare the hashes instead of the decrypted content.

There Is No Perfect Solution

Even if we deploy hash-based detection instead of scanning users' private messages, the compute cost would be huge because not only do some platforms have to keep content encrypted at rest but also run hashing algorithm comparisons to detect the content in question if it exists.

Hashing also can be useful only for common or known content. So hashing wouldn't be that useful to spot modified content.

AI could do slightly better in terms of spotting patterns. However, this takes us again into the issues and risks mentioned earlier.

Environmental Impact

The sheer volume of messages exchanged daily globally between users is already stressing data centers that are trying to expand their capacity to accommodate both regular companies' needs as well as AI.

The carbon footprint of scanning users' private messages at scale will only increase the burden on an already heating planet.

Ethical Considerations

Relying on AI LLMs to flag users could have severe consequences on human rights if someone is flagged or accused of something illegal by mistake or by error. Even with human-in-the-loop, human biases could also lead to discrimination and bias based on the user's legally protected traits such as language, nationality, or religion.

The fact that human intervention might be needed (platform's forensic or security teams) to manually review flagged content and potentially users' private conversations raises serious implications for users' privacy. Just because an AI flagged a certain user's messages doesn't mean that they are automatically guilty.

In edge cases, users might accidentally share content that may seem, at surface, like a meme and end up in criminal prosecution. The accusation alone could have severe implications on a person's life in terms of society, their own family, and more.

Alternative Solutions

In my opinion, all children deserve protection. Violation of privacy of individuals or groups online is not protection in the pure sense. A more effective strategy to combat child abuse is by grassroots movements, awareness campaigns, and better legislation that addresses structural problems such as inequality and domestic violence.

Useful Sources

https://oeil.europarl.europa.eu/oeil/en/document-summary?id=1891790

https://telegram.org/blog/100-million

🜂 𝐒𝐎𝐕𝐄𝐑𝐄𝐈𝐆𝐍 SYSTEMIC SUITE FOR PERSONAL DATA PROTECTION IN A SMARTPHONE

Tue, 07 Jul 2026 13:57:36 +0000

A year ago I opened my phone's settings and scrolled through the app list. And it hit me: I'm not the one using these apps — they're using me. Here's what I did about it.

The surveillance you never see
The classic example is a flashlight app that somehow wants your location and your Wi-Fi map. But let's be honest: not every flashlight spies, and not on every phone. This stopped being about a specific icon a long time ago.

By 2026, manufacturers and ad networks learned something far subtler. Data collection moved into invisible system apps and background services — many of which don't even have an icon on your home screen. You don't know about them, you never opened them, and you can't delete them. Yet they quietly harvest your location, the map of devices around you, your identifiers, the pattern of your movements. That builds a digital model of you — one you never agreed to — and it lives not in your pocket, but on someone else's servers.

We treat this like the weather. But one thought stuck with me. In a kitchen there's an iron rule: raw meat doesn't share a shelf with cooked food. That's not paranoia — it's hygiene. In the digital world we threw everything onto one shelf: government services, banking, private messages, photos of our kids, a crypto wallet. Any app can potentially see its neighbor. The digital world forgot about hygiene. I decided to bring it back.

Why antivirus and "incognito" won't save you
The first instinct is an antivirus or incognito mode. It doesn't work. Antivirus catches viruses, not the legal data collection you tapped "Allow" on yourself. Incognito hides your browser history from your family, not from the sites.

The second idea — "I'll just quit apps." Also a miss. Try living in 2026 without a banking app, government services and a marketplace. That's not freedom, that's self-exile from reality.

The third — custom ROMs and root. It works, but it's a path for the 0.1% of geeks. A normal person won't reflash their phone and void the warranty. I wanted a solution for normal people: let every app work as usual, but stop them from seeing each other. No root. On the phone already in your pocket.

Three identities in one phone
That's how Sovereign was born — an app that splits one phone into three isolated spaces.

Citizen
The public-facing side: government services, banks, marketplaces, and mass messengers such as MAX and Telegram. Everything works in full. The state sees an ordinary citizen with an ordinary phone. Sovereign simply shows you what these apps are doing.
Human
Your private life. Messengers for private conversation (such as Signal), crypto wallets, torrent hubs, personal photos and mail. Its own storage, its own keys. Citizen cannot read a single file from here.
Sovereign
An encrypted enclave for what matters most. It isn't shown in the app list. To an ordinary inspection of the phone, there's simply nothing there to open.
The key point: this is not a sandbox and not a clone. Isolation runs at the operating-system level — through standard Android mechanisms (work profile and enclave). So no root is needed, no custom ROM. It installs like an ordinary app.

What's inside
I won't hide the features behind vague words — here's what v1.0 actually does:

Sovereign X-Ray — an X-ray of surveillance. A live map of which app sends what data, where, right now. You see the "invisible" service pinging analytics, and the bank firing dozens of requests an hour even while locked. Plus a weekly plain-language report.
Sovereign Compass — a one-glance threat light: green / yellow / red in the status bar, from analysis of hundreds of on-device signals. No internet needed.
Encrypted vault with post-quantum protection — the Android hardware module plus the Kyber and Dilithium algorithms on top of AES. Honestly: the post-quantum part protects the key, against "store now, decrypt later" attacks.
Sovereign Whisper — an AI that runs offline, right on the phone: translate, summarize, search your vault. Without a single outgoing packet to the cloud.
The Veil — a hidden vault. When veiled, there's no visible vault — no folder, no icon. Plus a duress wipe: enter a decoy password and a hollow shell opens.
Mesh, Air Gap, separate DNS — phone-to-phone file transfer with no server, fully cutting a profile off the network, isolating network traffic.
Honestly, what Sovereign does NOT do
Marketing "absolute protection" is a lie, and I don't sell that. Sovereign is digital hygiene, not an invisibility cloak against state agencies.

The hidden vault gives plausible deniability at an everyday level — real protection against someone who picked up your phone, but not a mathematical guarantee against a state forensic lab. Without root, the operating system imposes limits, and I don't bypass them or promise to. My goal is simpler and more honest: to separate the state and banks from your private life the way a kitchen separates raw from cooked.

Why solo
I have no team and no funding round. I have a phone, a laptop and stubbornness. I wrote and tested every feature myself, on a real device. It's slow and hard — but solo development has one advantage: there's no one for me to sell your data to. The app has no cloud, no servers, no subscription. It can't leak — it has nowhere to.

Hence the philosophy I built into the project: you are a subject, not a function. A tool should work for you, not you for the tool.

X-RAY — an X-ray of your digital life: real-time connection graph, permission audit, weekly report, "greed" ranking of apps.
🧭 COMPASS — a threat traffic light 🟢🟡🔴 based on hundreds of parameters.
🎭 SCENARIOS — life-state presets ("Home", "At the border", "Travel"): the whole config changes with one gesture in 2 seconds.
🤖 WHISPER — local AI (Gemma/Llama/Qwen) with no cloud and no logs: translation, analysis, transcription, vault search.
🌫️ THE VEIL — deniability mode: there are simply no traces of "Sovereign" on the phone.
👻 EPHEMERAL — "Sovereign" lives only in RAM; forensics is powerless.
🪤 FORENSIC BAIT — a decoy that makes investigators waste time.
🎙️ SILENT WITNESS — covert video/audio/GPS recording during detention.
🕯️ WITNESS — a dead man's switch: if you don't open it for N days → a scenario fires.
🎭 PHANTOM PERSONA — background imitation of ordinary life to fool algorithms.
👀 STRANGER DETECTION — detects someone else's touch, takes a hidden snapshot, closes "Sovereign."
🌐 MESH — P2P connection between devices with no server and no internet.
🧩 VAULT FRAGMENTATION — the key is split via Shamir into 3 fragments.
🛰️ QUANTUM VAULT — NIST post-quantum crypto (Kyber + Dilithium) against "store now, decrypt later" attacks.
✈️ AIR GAP — full disconnection of "Sovereign" from any network.

How to try it
Sovereign is finished, tested and packaged as an installable .apk. The license is one-time, lifetime, no subscriptions. Payment in USDT/USDC; after payment your key, the download link and the full manual arrive by email.

Open the Sovereign page Watch the demo on YouTube
The ecosystem
Sovereign is part of the digital ecosystem of solo developer Vladislav Shter:

Sovereign — personal data protection on your phone (this article).
Egregor — a desktop multi-AI consilium, already on sale.
SovereignWeb3 Browser — a unique Web3 browser, coming soon.
SovereignBank-Web3 — non-custodial on-chain banking.
Ecosystem site — s0vereign.pw
GitHub — github.com/VladislavShter/SOVEREIGN
GitVerse (mirror) — gitverse.ru/wadyas/SOVEREIGN
SovereignBank-Web3 — github.com/VladislavShter/SovereignBank-Web3
Demo — youtu.be/cvy4_lwi-TI

                               Created solo, against inevitability. — Vladislav Shter

Your phone spies on you — and it stopped being about the flashlight long ago

Tue, 07 Jul 2026 13:54:42 +0000

A year ago I opened my phone's settings and scrolled through the app list. And it hit me: I'm not the one using these apps — they're using me. Here's what I did about it.

The second idea — "I'll just quit apps." Also a miss. Try living in 2026 without a banking app, government services and a marketplace. That's not freedom, that's self-exile from reality.

Three identities in one phone
That's how Sovereign was born — an app that splits one phone into three isolated spaces.

What's inside
I won't hide the features behind vague words — here's what v1.0 actually does:

Hence the philosophy I built into the project: you are a subject, not a function. A tool should work for you, not you for the tool.

Open the Sovereign page Watch the demo on YouTube
The ecosystem
Sovereign is part of the digital ecosystem of solo developer Vladislav Shter:

                               Created solo, against inevitability. — Vladislav Shter

Generative interface agent

Fri, 19 Jun 2026 07:33:16 +0000

THE AI RACE COULDN'T GET ANY TOUGHER

I Built GIA: A Fully Private, On-Device AI Workspace That Feels Like a Personal AI OS in Your Pocket (No Backend, Zero Telemetry)

Hey devs,

Tired of every AI tool phoning home, racking up API bills, or hallucinating your private data into some cloud silo?

I got fed up too. So I built GIA — Generative Interface Agent: a complete private, on-device AI workspace that runs as a native Android app (Capacitor + React + TypeScript) with everything critical happening locally.

No server. No telemetry. No shady data collection. Your API keys live in IndexedDB. It even works offline for core features.

Why This Matters in 2026

Most "local AI" apps are either glorified chat UIs or require you to run a full LLM server. GIA is different — it's an agentic workspace with persistent memory, tool use, voice, and real autonomy, all while staying privacy-first.

Core Superpowers That Make Devs Go "Wait, Really?"

True Agentic Loops — Multi-turn reasoning, sub-agent delegation, live streaming thought panel, smart provider fallback. It doesn't just answer — it executes.
Deep Memory System — Three-tier (working, semantic, episodic) with relevance scoring, auto-extraction, pinning, and full JSON brain export/import. This thing remembers your projects, preferences, and context across sessions.
Wake Word + Voice — Porcupine DNN (or native Android SpeechRecognizer) for always-listening "Hey GIA" (foreground service, survives background/reboot). Full-screen animated overlay, transcript polishing via AI, TTS. Still in an experiment though
Circle-to-Search — Ctrl+Shift+C (or native) → screen capture → region select → vision analysis. Multiple capture strategies.
Conversation Branching — Tree-based forking from any message. Rename, switch, delete branches. Perfect for exploring ideas without losing the original thread. Also in experimental stages
On-Device AI — Qwen2.5 (0.5B–3B) via Transformers.js WASM, on-device vision (captioning/OCR/detection), Python via Pyodide WASM.
99+ Tools across 24 categories: Filesystem, Code Execution (native proot+Alpine or Piston), Web Search (with citations), Image Gen, Device Integration (calls, SMS, share, haptics), MCP Protocol support, etc.
Rich Output — Interactive visual blocks: Recharts (bar/pie/line), Mermaid diagrams, KaTeX, Leaflet maps, code diffs, galleries, terminal output with ANSI colors, PDF previews, etc.
Modular Workspace — Chat, Exam (WASSCE/JAMB prep), Analyst (CSV/JSON + charts), Writer (9 formats), Planner, Autonomy (goal decomposition + execution), Settings (17 sub-pages including "Engine Room").

21+ Providers — Direct HTTPS (no proxy): Anthropic, Gemini, OpenAI (o-series), Groq, DeepSeek, xAI Grok, Ollama, LM Studio, local WASM, etc. Plus 11 API connectors and social platform tools.

Extensibility:

Neural Skills — JSON definitions that reprogram behavior/tools/tone. Install via URL or registry.
Plugin System — Hook-based (onBeforeGenerate, etc.) in sandboxed Web Workers with permissions.
MCP Protocol — SSE + stdio for external tool servers. Auto-discovers GIA Stdio Bridge.

Tech Stack (For the Curious)

Frontend: React 19, TypeScript 5.7, Tailwind v4, Motion (Framer)
State: Zustand + IndexedDB persistence
Mobile: Capacitor 8 (Android WebView)
Build: Vite 8 + esbuild
Local Compute: Transformers.js WASM, Pyodide, Porcupine
Visuals: Recharts, Mermaid, KaTeX, Leaflet

Real Talk: The Privacy & Autonomy Angle

In an era of AI companies training on everything you type, GIA is built on the principle that your thoughts, code, and data belong to you. Input guardrails block prompt injection. High-risk tools require confirmation. Everything is auditable.

Try It Right Now

Live Demo / GitHub:
https://alpha-1-design.github.io/gia-app/
https://github.com/alpha-1-design/gia-app

Quick Start:

git clone https://github.com/alpha-1-design/gia-app.git
cd gia-app
npm install
npm run dev
# For Android APK:
npm run build
npx cap sync android

Check the manual.md and docs/ for deep dives on plugins, MCP, skills, etc.

What's Next / Call for Collaboration

This is a solo project that's already ridiculously capable, but it can be way better with the community:

More skills/plugins
iOS support
Better local model integration
Advanced autonomy patterns
Desktop Electron version?

If you're into local-first, agentic systems, privacy tech, or just want a powerful daily driver that doesn't spy on you — star the repo, try it, and let's build the future of personal AI together.

Drop your wildest use case or feature request in the comments. What would you do with a private AI OS in your pocket?

AI #LocalAI #Privacy #OpenSource #AgenticAI #ReactNative #Capacitor

Why Cookie Consent is Broken on Most UK Business Websites (And How to Fix It)

Tue, 16 Jun 2026 07:41:09 +0000

If you build websites for clients, or you run your own business website,
cookie consent is probably something you have thought about at some point.
You added a banner, moved on, and assumed you were covered.

There is a good chance you are not. And it is not your fault - the way most
cookie banners are implemented makes them look compliant while not actually
being compliant.

I have been building ClearlyCompliant, a free GDPR compliance checker for UK
businesses, and cookie consent is the issue I see failing most consistently
across the sites I scan.

Here is what is actually going wrong and how to fix it.

Quick background on the rules

In the UK, cookie consent is governed by two pieces of legislation: UK GDPR
and PECR (Privacy and Electronic Communications Regulations). The key rule is
simple in theory.

If your site uses cookies that are not strictly necessary for it to function,
you need to get consent before you set them.

Strictly necessary means things like session cookies, shopping basket cookies,
login cookies. It does not mean Google Analytics. It does not mean Facebook
Pixel. It does not mean any third party tracking or marketing script.

For those, you need consent first.

Why most banners do not actually work

The most common failure is a timing issue.

A typical WordPress site might have Google Analytics loaded in the header via
a plugin or hardcoded script tag. The page loads, GA fires, cookies are set.
Then, a fraction of a second later, the cookie consent banner appears.

The banner is asking for consent for something that has already happened.
That is not how consent works.

For a banner to be compliant it needs to load before any non-essential scripts
and it needs to actively block those scripts from firing until the user has
made a choice.

What a compliant setup looks like in practice

A properly implemented consent setup works like this:

Page loads
Consent management script initialises and checks for existing consent
If no consent exists, the banner is shown and all non-essential scripts
are blocked
User makes a choice
If accepted, the relevant scripts are loaded and cookies are set
Choice is stored so the banner does not reappear on every page

Most consent management platforms can do this. The problem is they need to
be set up correctly, which means your analytics and tracking scripts cannot
just be hardcoded into the page head. They need to be loaded conditionally
based on what the user has consented to.

The other common mistakes

Beyond the timing issue, here are the other things I see failing regularly:

No decline option. A banner with only an "Accept" button is not compliant.
Users must be able to decline non-essential cookies just as easily as they
can accept them.

Pre-ticked options. Defaulting analytics to "on" and requiring users to
untick it is not valid consent under UK law.

No way to update preferences. Users need to be able to change their mind
after the initial choice. Most sites have no mechanism for this at all.

Cookie policy missing or vague. You need a cookie policy that lists what
cookies you use, why, and who sets them. "We use cookies to improve your
experience" is not sufficient.

A quick checklist for your own sites

Before shipping any site, it is worth running through these:

Is the consent banner loading before any non-essential scripts?
Is there a genuine accept and decline option?
Are analytics and tracking scripts blocked until consent is given?
Is there a link to a proper cookie policy?
Can users update their preferences after the initial choice?
Is consent being recorded somewhere?

If the answer to any of those is no, the site has a compliance gap.

How to check quickly

If you want to run a quick check on a site you have built or your own business
website, I built ClearlyCompliant to do exactly this. It is free, it scans the
live site rather than asking you to fill in a questionnaire, and it gives you
a breakdown across 23 GDPR compliance checks including cookie consent.

You can run it at clearlycompliant.co.uk - takes a couple of minutes and the
results are instant.

Cookie consent is genuinely one of those things that is easy to get right once
you understand what the standard actually is. The frustrating part is that most
implementations make it look right while getting it wrong under the hood.

GDPR Compliance Checklist for Web Developers in 2026

Sat, 06 Jun 2026 13:15:03 +0000

You've built the app. You've written the privacy policy. You've added a cookie banner. Job done, right?
Not quite. GDPR compliance isn't a single checkbox — it's a spread of technical, legal, and operational requirements that touch almost every layer of a web project. Fines for non-compliance can reach €20 million or 4% of global annual turnover, whichever is higher. And yes, small sites get caught too.
This checklist covers the areas developers are most commonly responsible for — or at least need to flag to their clients before handoff.

Lawful Basis for Processing Data
Before you collect a single byte of personal data, you need a lawful basis under Article 6 of GDPR. The six lawful bases are:

Consent — the user has actively agreed
Contract — processing is necessary to fulfil a contract with the user
Legal obligation — you're required to process the data by law
Vital interests — processing is necessary to protect someone's life
Public task — you're carrying out a task in the public interest
Legitimate interests — you have a genuine, proportionate reason to process

Most web apps rely on consent or contract. The mistake developers make is assuming consent is implied. It isn't. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count.
Check: Have you identified and documented the lawful basis for every type of personal data your site processes?

Cookie Consent
Cookies that are not strictly necessary require explicit, opt-in consent before they fire. This includes:

Analytics cookies (Google Analytics, Plausible, Fathom)
Marketing/retargeting pixels (Meta Pixel, Google Ads)
Session recording tools (Hotjar, FullStory)
A/B testing tools (Optimizely, VWO)

A compliant cookie banner must:

Present options clearly, without dark patterns
Make declining as easy as accepting (no grey-out on the reject button)
Not pre-select any non-essential categories
Allow users to withdraw consent at any time
Not block access to the site if the user declines

Check: Are all non-essential scripts blocked until consent is given? Inspect your network tab on first load with a clean session — anything firing before consent is a violation.

Who you are and how to contact you (and your DPO if applicable)
What personal data you collect and why
The lawful basis for each type of processing
How long you retain data
Who you share data with (third-party processors, sub-processors)
Users' rights under GDPR (access, rectification, erasure, portability, objection)
Whether you transfer data outside the UK/EEA, and the safeguards in place
How users can make a complaint to the ICO (or relevant supervisory authority)

Check: Is the privacy policy linked from every page that collects data (forms, checkout, sign-up)? Is it accessible before the user submits any personal information?

Data Minimisation
GDPR's data minimisation principle (Article 5) requires that you only collect what you actually need. This is somewhere developers can make a real difference at the design stage.
Common violations:

Contact forms asking for phone numbers that are never used
Sign-up forms requiring date of birth for no functional reason
Server logs retaining full IP addresses indefinitely
Analytics collecting more granular data than necessary

Check: Go through every form and data collection point on the site. For each field, ask: do we actually need this to deliver the service? If not, remove it.

Data Retention
Storing data indefinitely is a GDPR violation. You need a retention policy that defines how long each category of data is kept, and a mechanism to delete or anonymise it after that period.
Common areas to address:

User account data — what happens when an account is deleted or inactive?
Order/transaction records — often kept for tax/legal reasons, but there's still a limit
Contact form submissions — usually no reason to keep these beyond a few months
Server and application logs — consider truncating or anonymising IP addresses
Email marketing lists — unsubscribers should be purged or suppressed

Check: Do you have automated deletion or anonymisation in place, or are you relying on manual processes? Manual processes tend not to happen.

User Rights
GDPR grants users several rights that your application needs to support. Depending on your scale and tooling, some of these can be handled manually, but the process needs to exist and you need to be able to respond within 30 days.
Right of access (SAR) — Users can request a copy of all data you hold about them. You need to be able to export this.
Right to erasure — The "right to be forgotten." You must be able to delete a user's data from your systems, including backups (within reason) and any third-party processors you've passed data to.
Right to rectification — Users can ask you to correct inaccurate data.
Right to portability — Users can request their data in a machine-readable format (e.g. JSON or CSV).
Right to object — Users can object to certain types of processing, particularly direct marketing.
Check: How would you currently handle a subject access request? Do you know every place a user's data lives (database, email platform, analytics, CRM, support tool)?
Third-Party Processors
Every third-party tool you integrate with that handles personal data on your behalf is a data processor. Under GDPR, you must have a Data Processing Agreement (DPA) in place with each of them.
Most reputable SaaS providers have a DPA you can sign or accept online (Stripe, Mailchimp, AWS, Google, etc.). You also need to list them in your privacy policy.
If any of these processors are based outside the UK or EEA, you need appropriate safeguards for the transfer — usually Standard Contractual Clauses (SCCs).
Check: Make a list of every third-party tool that touches personal data. Have you signed their DPA? Are they in your privacy policy?
Forms and Data Collection Points
Every form that collects personal data needs:

A clear explanation of what the data will be used for (at the point of collection, not buried in a privacy policy)
A link to your privacy policy
Explicit consent where required (e.g. for marketing emails — a pre-ticked opt-in doesn't count)
HTTPS (non-negotiable)

Check: Audit every form on the site. Is there any form collecting data without a clear purpose statement and privacy policy link?

Security Measures
GDPR requires "appropriate technical and organisational measures" to protect personal data (Article 32). For most web applications, this means:

HTTPS everywhere (HSTS is a good addition)
Passwords hashed with a modern algorithm (bcrypt, Argon2) — never stored in plain text
Access controls — does only the right people/systems have access to personal data?
Dependency management — are you keeping libraries up to date? Outdated dependencies are a common breach vector
Database security — is your database exposed to the internet? Are credentials stored securely?
Regular backups, stored securely

Check: When did you last review who has access to your production database and admin panels? Principle of least privilege applies.

Data Breach Response Plan
Under GDPR, if you suffer a personal data breach, you have 72 hours to notify your supervisory authority (the ICO in the UK) if the breach is likely to result in risk to individuals. High-risk breaches also require direct notification to affected users.
This means you need:

A way to detect breaches (monitoring, alerts)
A documented process for assessing severity
Clear ownership of who notifies the ICO
A record of breaches (even those you don't report)

Check: If you discovered a breach today, do you know exactly what to do and who is responsible?

Records of Processing Activities (ROPA)
If your organisation has 250 or more employees, you're required to maintain a formal Record of Processing Activities under Article 30. Below that threshold it's best practice, and the ICO strongly recommends it.
A ROPA documents:

What personal data you process
Why you process it
Who has access to it
Where it's stored (including third-country transfers)
How long you keep it

Check: Even if you're not required to maintain a formal ROPA, do you have enough documentation to answer an ICO enquiry confidently?

Age Verification (if applicable)
If your service is directed at or likely to be used by children, you have additional obligations. In the UK, the Children's Code (Age Appropriate Design Code) sets high standards for services likely to be accessed by under-18s, including defaulting to high privacy settings and not profiling children.
If there's any chance your service reaches minors, this needs specific legal advice — it's one of the more complex areas of UK data law right now.
Check: Is your service likely to be used by under-18s? If so, have you addressed the Children's Code?

Wrapping Up
GDPR compliance isn't something you bolt on at the end of a project — it needs to be considered from the start. The good news is that most of it is straightforward once you know what to look for.
If you're handing off a project to a client or want a quick sense of where a site stands, ClearlyCompliant analyses your site's GDPR compliance and delivers a detailed PDF report covering the key risk areas — useful as a starting point or a sanity check before launch.

Disclaimer: This article is for informational purposes and does not constitute legal advice. For specific legal questions around GDPR compliance, consult a qualified data protection professional.

I made 342 browser-native dev tools — no server, no signup, no data leaks

Sat, 06 Jun 2026 09:12:36 +0000

Quick background: I'm Meet Shah, a solo developer who builds practical tools.

I just launched ZeroServer.tools — 342 free developer utilities that run 100% in your browser.

The one constraint I designed around: nothing you type or upload ever leaves your device. No backend, no logs, no third-party requests.

Why does it matter if a dev tool has a backend?

Most "online tools" work by sending your data to their server, processing it, and returning the result.

That's fine for most things — but I was regularly pasting:

JWT tokens (which contain auth claims and sometimes PII)
Hashes of passwords (to verify my hash generators were correct)
Internal JSON from our API (which contained customer data structure patterns)
Private encryption keys (to test key formatting tools)

None of that should leave my machine. But I was doing it casually.

ZeroServer.tools is the fix I built for myself.

What's in it (342 tools)

Formatters: JSON, XML, SQL, YAML, Markdown, HTML, CSS

Converters: JSON↔CSV, JSON↔YAML, image formats, Markdown→HTML, Base64, UUID conversions

Encoders/Decoders: Base64, URL encode/decode, JWT (decode only — client-side), Morse code, Binary↔Text

Cryptography: SHA-1/256/512, HMAC, AES-256, PBKDF2, file hash (drag a file → instant SHA-256 without uploading it), bcrypt, TOTP

Generators: UUID (v1/v4/v5), Lorem ipsum, Password, QR code, Fake data

Text: Sorter, replacer, case converter, TOC generator, markdown renderer

Developer utilities: Regex tester, JSONPath tester, UUID validator, IP subnet calculator, cron expression builder

Calculators: Date difference, scientific, BMI, mortgage, calories burned, fuel cost

The tech that makes it possible

Web Crypto API handles all hashing and encryption:

const hash = await crypto.subtle.digest("SHA-256", buffer);

No external libraries for crypto. It's built into every modern browser.

FileReader + Canvas handle image operations (compression, resize, format conversion) — files stay local.

pdf-lib (WebAssembly) handles PDF merge/split/rotate — compiles to WASM, runs entirely in-browser.

Next.js static export — the whole site is plain HTML + JS files on Cloudflare's edge. There's no server to send data to, literally.

The constraint that kept biting me

Next.js prerenders your components in Node.js at build time. So any code that uses window, document, FileReader, Date.now(), or Math.random() crashes the build.

The rule I followed strictly:

Pure transforms (format JSON, encode string) → useMemo — deterministic, SSR-safe
File reads, canvas, browser APIs → useEffect — client-only
"Random" seeded output → deterministic PRNG using Math.sin(seed) — same result in Node and browser, no hydration mismatch

This discipline means every single tool prerenders correctly and loads instantly.

Check it out

zeroserver.tools — 342 tools, 100% free, 100% client-side.

Open the browser Network tab while using any tool — you'll see zero requests. That's the whole point.

What tool would you reach for if it guaranteed no data uploads?

How I Built My Own Laravel Analytics Package (and Almost Didn't Crash Production)

Wed, 03 Jun 2026 10:22:39 +0000

Why Not Google Analytics? (Or why I love reinventing the wheel)

To be honest, this wasn't an easy call. I’ve been in development for quite a while and had grown accustomed to GA. What could be simpler: you slap a script with your ID onto the site, and data starts flowing into the analytics console. All that's left is to wait for the traffic to roll in and then analyze it by country, gender, age groups, and so on.

Yes, that’s how it used to be, but in today’s reality, there are objective reasons to rethink this concept. Let’s be real: hooking up Google Analytics in 2026 is like putting a massive deadbolt on your front door but leaving the keys with your neighbor. Everything seems under control, but the neighbor knows exactly when you came home, what you bought, and why you have a long face. And when someone visits you and wants to stay incognito, the neighbor won't give them the keys, and they won't even tell you they stopped by. Their response would be something like: “Nobody came, I never sleep, everything is under control…”. What am I getting at?

Now, for your analytics to work, you must display a cookie consent banner and get the user's permission. And that’s where the problem lies. 90% of users don’t accept all cookies—only the strictly necessary ones. And what does that mean? Google Analytics ends up dead in the water. Besides, everyone is sick and tired of these banners. So, if there’s a legal way to ditch them, why not take it?

(To learn how to avoid legal trouble with data protection laws, check out the article GDPR Without the Headache: A Guide for Web Developers in Germany )

The decision to drop GA was made. When I decided to hit the "Eject" button and catapult myself out of the Google ecosystem, I faced a logical question: what would fill the void? Because I still needed the numbers. I started looking at the heavy artillery.

The first candidate was Matomo (formerly Piwik): Probably the most powerful all-in-one machine. It’s like keeping a pet elephant in your backyard. It does everything, the database grows like crazy, but it requires a separate PHP server, MySQL, and constant babysitting. For my small pet projects, it felt like trying to drive nails with a microscope.

The second tool I looked at was Plausible / Fathom: Sleek, modern, and privacy-respecting. But there’s a catch: you either pay a subscription (a questionable investment for a free tool) or you mess around with self-hosted Docker versions, which also eat up a good chunk of your VPS RAM.

I looked at all of this and thought: “Do I really need to spin up an entire infrastructure just to know that 50 people read my article on German taxes yesterday?”. That’s when it hit me: I don’t need a "combine harvester." I need a tiny, precision scalpel that lives right inside my Laravel application.

I wanted something of my own: lightweight, like a morning espresso, and not asking annoying questions about GDPR. Plus, I was simply curious about who all these people (and bots) were "knocking" on my security tools at oleant.net. Since this blog also needed the same tool, I decided to develop a standalone package that could be easily installed via composer and published openly on Packagist.

For those interested in diving into the code, the package is called oleant/laravel-visit-analytics, compatible with Laravel versions 10/11/12. GitHub link: https://github.com/Oleant-NET/laravel-visit-analytics

The Heart of the System: Middleware and the Magic of the Aftertaste

Which architecture to use? There are various ways to implement this. Fortunately, Laravel has a great Middleware mechanism. I decided to stick with that, but would it slow down the user? They shouldn't have to care about my overhead. And what if the database goes down or something goes wrong? A 500 error page as the face of the site is definitely not what I was aiming for.

That’s why a crucial decision was made — to use the terminate() method. In a Laravel Middleware, it’s like a polite waiter: he brings you the check and smiles (the handle() method), and only after you’ve already left the restaurant does he go back to wipe the table and log the tip (the terminate() method).

The user has already received their page and is happy, while our server quietly and without rush writes the logs to the database in that moment. Even if something goes wrong, the client still leaves satisfied, and the waiter... just doesn't get a tip this time. Just kidding, but here’s how it works in practice:

PHP

public function terminate(Request $request, Response $response): void
{
    try {
        // Logic to exclude non-target clients, like Admin etc.
        // …
        // Next, write our visitors to the database
        $this->logVisit($request);
    } catch (\Throwable $e) {
        // If the DB takes a nap, we won't wake the user with a 500 error
        \Log::error("Analytics failed, but we're keeping our cool: " . $e->getMessage());
    }
}

Lifehack: All analytics code must be wrapped in a try-catch. Believe me, there's nothing sillier than "crashing" an entire project just because the logger didn't have enough room for a long User-Agent or some other non-obvious case.

GDPR on the Fly: How Not to Become Public Enemy No. 1
To avoid slapping a banner the size of half the screen saying “We are watching you, bro,” I implemented IP anonymization. We simply trim the last part of the address before it ever touches the database. This anonymizes the user and fully complies with the law. Yet, we can still tell which country, data center, etc., the visit came from. We’ll talk more about data center bots once there's more data to show.

Back to IP anonymization:

PHP

// Before: 192.168.1.154 -> After: 192.168.1.0

It’s like seeing a crowd in masks: you understand that 5 people showed up, but who among them is your neighbor — you have no clue. The law is satisfied, and so is my conscience.

Payload: Gathering Only the Goodies
Initially, I wanted to write everything that comes in the URL to the database. But then I looked at the Livewire logs, where half the state of the planet is passed in the parameters, and realized — the database would explode. So, I decided to implement filtering based on allowed parameters in the config using array_intersect_key. Now, only what I’ve personally authorized in the config ends up in the logs. Clean, orderly, and zero fluff.

The default set in the package config looks like this:

PHP

'whitelist' => [
    'utm_source',
    'utm_medium',
    'utm_campaign',
    'utm_term',
    'utm_content',
    'ref',
],

But you can, of course, change it by publishing the config in your project first:

Bash

php artisan vendor:publish --tag="visit-analytics-config"

After that, a visit-analytics.php file will appear in your config folder. There, you can not only expand the list of tracked parameters (for example, adding something like page or search) but also specify excluded paths so you don't turn your database into a dump for admin panel or technical endpoint logs.

What's Next?

The package started humming, and the data began to flow. I closed my laptop and went to bed, thinking I’d wake up to some visitor charts from a couple of friends. But reality turned out to be much tougher (and more interesting).

In the next episode, we’ll step through the "looking glass": who are Palo Alto Networks, why do bots read my Terms of Service in 7 seconds, and why Linux + DuckDuckGo is a badge of quality for a visitor?

Why I Made Privacy the Core Feature of PDF Pro — and What Happened to Signups.

Mon, 01 Jun 2026 13:54:19 +0000

When I first launched PDF Pro AI, I had a hypothesis: people are tired of uploading their sensitive data to random cloud servers just to perform basic file operations.

We live in an era where data breaches are daily news, yet developers still casually rely on external API endpoints for simple tasks like file compression or document merging. Think about how many times a user uploads a highly confidential bank statement, a signed NDA, or an employment contract to a random "Free PDF Tools" website.

Where does that data go? Who is looking at it? When is it actually deleted?

As a developer, I realized that if I wanted to build a tool people actually trusted, I needed to eliminate the server entirely. Here is why prioritizing privacy through "Edge Computing" and client-side processing isn't just an ethical choice—it is a massive competitive advantage.

The Problem with the "Upload to Process" Model
For the last decade, the standard architecture for SaaS tools has been:

User uploads a file via an HTML form.
The server receives it, temporarily stores it in an S3 bucket, and triggers a background job.
A heavy Python or Node.js process does the manipulation.
The server returns a download link to the user.
This architecture is fundamentally flawed for two reasons:

It's expensive: You have to pay for the ingress bandwidth, the compute time for the background job, and the storage buckets.
It's a privacy nightmare: You are legally responsible for safeguarding the user's data while it sits on your server.

The Solution: Shifting Compute to the Browser
When architecting the core engine for PDF Pro AI, I made a strict rule: Zero Cloud Uploads.

Instead of relying on a backend server, I utilized WebAssembly (WASM). By compiling heavy C++ and Rust libraries down to WASM, modern web browsers can now execute incredibly complex operations natively, using the end-user's own hardware.

When a user visits PDF Pro to extract pages from a document or compress a massive 50MB presentation, the entire operation happens entirely inside their laptop's RAM.

This creates a win-win scenario:

The User wins: Their documents never leave their device. They don't have to trust me to delete their files, because I never received them in the first place. Their privacy is mathematically guaranteed by the architecture.

I win: Because the user is providing the compute power, my AWS server costs are essentially zero. The tool scales infinitely without requiring me to provision more backend instances.
The Takeaway for Developers
We are rapidly moving toward a future where "serverless" doesn't just mean AWS Lambda—it means literally pushing the workload entirely to the client's browser.

If you are building tools that manipulate documents, images, audio, or video, I strongly urge you to investigate WASM libraries (like pdf-lib, ffmpeg.wasm, or sharp client-side ports).

Build products that respect your users' data by default. Make privacy the foundation of your architecture, rather than an afterthought.

Rahul Banerjee is a software engineer and the creator of PDF Pro AI, a privacy-first document workspace featuring 100% local PDF manipulation tools and secure AI contract analysis.

Sanitization by Construction: Bounded Context Before the Network

Tue, 26 May 2026 08:00:00 +0000

Sanitization by Construction: Bounded Context Before the Network

Regex redaction on arbitrary broker exports fails the moment a column renames, a locale shifts decimal separators, or a merged cell appears. We chose structural exclusion: the Ask AI path never serializes a free-form ledger string because we never build one for the model.

The mechanism is buildPortfolioContext in app/lib/ai/contextBuilder.ts.

Edge Compiler = function contract, not a package

Edge Compiler is a term of art for this deterministic reduction. There is no EdgeCompiler npm module — only a pure function with a fixed output template:

const TOP_HOLDINGS_COUNT = 10;
// ...
lines.push('Portfolio summary (for personalization only):');
lines.push(`Total positions: ${totals.totalPositions}`);
lines.push(`Total trades: ${trades.length}`);
// Top holdings: ticker, shares, currency, value %, P/L %

Source comment (accurate):

// No raw ledger rows, no PII, no account identifiers—sanitization by construction.

Two pipelines — do not conflate

Stage	Input → output	What crosses the network for Ask AI
Import	Broker CSV → `Trade[]` via `packages/importer`	Not the default Ask AI body (Part 5)
Context build	`Trade[]` + positions → template string	Yes — bounded aggregate only

Import may touch account-ish columns while parsing; the inference boundary is the second stage. By the time buildPortfolioContext runs, only template fields can appear in the output lines.

What the LLM receives

Approved: “The LLM receives a bounded, user-approved aggregate context payload.”

Prohibited: “AI never sees your data.” The model also receives the user message, optional attachment content (explicit user action), and route-defined server injections (e.g. live quotes) per app/api/ai/chat/route.ts and docs/IP-TECHNICAL-MECHANISMS.md.

Approved: No PII and no account identifiers on the Pocket Analyst inference path as designed in contextBuilder.ts.

DevTools receipt

On a typical allocation question:

Client calls buildPortfolioContext(trades, positions).
Network tab shows a short context field in the POST body — not 10,000 trade rows.
Compare to guest localStorage or Firebase-backed trade count in application state — orders of magnitude larger than the payload.

Performance

Reduction is O(n) over trades for position derivation plus sort of position list for top-N — typically milliseconds on-device. Publish latency numbers only after measurement on target hardware.

Part 2 of Sovereign Ingestion & Stateless Inference.

Read the full Sovereign Intelligence book, explore Open Portfolio, or try Pocket Portfolio.

I Was Live on Meet When WhatsApp Popped Up, Here’s What I Built to Make Sure It Never Happens Again

Sun, 24 May 2026 17:05:33 +0000

You're mid-presentation. A colleague asks a question. You alt-tab to WhatsApp Web to check a file link and for three seconds, forty people on the call can read your most recent messages. Your partner's name. A medical appointment reminder. A vent session from last night. It happened to me. It probably happened to you. And once you've seen it, you can't unsee the risk. So I built something about it.

The Problem

WhatsApp Web is seamlessly woven into the modern workday. But there's a design collision no one talks about: screen sharing assumes you want to show everything, and WhatsApp was never designed for an audience of colleagues.

The consequences range from mildly awkward (a friend's name appearing mid-demo) to genuinely serious (medical conversations, relationship problems, financial discussions exposed to managers, clients, or a recorded session that lives forever).

And the "solution" most people reach for closing WhatsApp before the call breaks your workflow every time you need to reference something.

The Extension: WhatsApp Web Privacy Mode

WhatsApp Web Privacy Mode is a free browser extension for Chrome, Firefox, and Edge that intelligently blurs your chats, messages, and notifications during screen sharing so you can keep WhatsApp open without the exposure risk.

Here's what it actually does:

Smart blur - Blurs the chat list and/or message content independently. You choose what gets hidden.
Auto screen-share detection - The moment you start sharing on Google Meet, Zoom, Teams, or Webex, it activates automatically. No clicks required.
Hover to peek - Need to quickly check a message? Hover over it. It reveals itself, then re-blurs when you move away.
Panic overlay (Ctrl+Shift+P) - Frosted-glass covers your entire screen instantly. For those "oh no" moments when you realize you're sharing before you had time to think.
Notification privacy - Incoming message notifications show "Privacy mode is active" instead of the actual content. Even banners can't betray you.
Scheduled privacy - Set work hours (e.g. 9 AM-6 PM) and it turns itself on automatically every day.
PIN protection - Require a PIN to turn it off, so accidental keypresses or a curious colleague can't expose your chats.
Last N messages visible - Keep your most recent 1-5 messages unblurred for reference, while everything else stays hidden.

And critically: zero data collected. No sign-up. No telemetry. Everything stays local.

How It Works (Technically, If You're Curious)

This isn't a naive "add a CSS class" extension. WhatsApp Web is a React single-page app that aggressively re-renders its DOM. Inline style-based solutions break within seconds.
Instead, the extension injects CSS rules that survive React's re-renders automatically. For notification interception, it runs a script in the browser's MAIN world context (before WhatsApp's own JavaScript) to proxy the Notification constructor replacing message content before it ever reaches the OS. Screen share detection hooks getDisplayMedia() calls on meeting platform tabs and relays the signal back via a dual-world content script architecture.

It's Manifest V3 compliant, uses only 5 permissions, and all settings export/import as a local JSON file nothing leaves your device.

Who This Is For

Remote workers on daily video calls
Developers and designers who demo products live
Teachers and educators sharing screens with students
Streamers and content creators recording their desktop
Anyone who's ever had that sinking feeling mid-screen-share

Get It Free

WhatsApp Web Privacy Mode is completely free, forever. No premium tier. No account required.

Chrome: Chrome Web Store
Firefox: Firefox Add-ons
Edge: Microsoft Edge Add-ons

If it's saved you from an embarrassing moment, consider leaving a review it helps other privacy-conscious users find it.

Privacy isn't about having something to hide. It's about choosing what you share, with whom, and when. Screen sharing shouldn't strip that choice away from you.

WhatsApp Web Privacy Mode gives it back.

Building a privacy-first AI app for doctor visit notes

Sat, 23 May 2026 06:09:18 +0000

Hey CoderLegion,

I wanted to share a project I've been working on called AI Doctor Notes.

The core problem it solves is pretty universal: you walk into a doctor's office, get overwhelmed with information, and walk out forgetting half of the instructions, medication changes, and next steps.

While you could technically use a standard voice recorder app, medical conversations are messy and non-linear. Plus, generic AI transcription tools don't have the privacy workflows required for sensitive health data.

We built AI Doctor Notes specifically for patient workflows.

Here is what the app handles:

Pre-visit prep: Users can log symptoms and organize their questions before they even walk into the clinic.
Secure recording: Captures the conversation during the visit with a focus on data privacy.
AI Summaries: Parses the messy conversation and outputs clean, structured recaps of actual doctor instructions and care plans.
Easy Sharing: Lets users securely share the summary with family members (super helpful for those managing care for elderly parents).

If anyone is building in the health-tech or AI space, I would love to hear your thoughts on balancing high utility with extreme privacy.

You can check out the app here: https://aidoctornotes.app/
IOS App: https://apps.apple.com/us/app/ai-doctor-notes-recorder/id6760372415

The AI Privacy Dilemma: Building Secure, Zero-Backend Workflows

Fri, 22 May 2026 20:24:07 +0000

The AI landscape has shifted dramatically. With powerful models like DeepSeek, Claude, Gemini, and ChatGPT becoming daily drivers for developers and enterprise users, the focus has moved from whether to use AI, to how to integrate it safely into our professional workflows.

But here is the elephant in the room: Privacy and Data Sovereignty.

The Middleman Problem in AI Tools

As the adoption of LLMs exploded, so did the ecosystem of third-party wrappers and productivity tools. However, many of these tools require you to route your sensitive prompts, proprietary code snippets, and client data through their own cloud servers just to format or export the output.

From a system architecture standpoint, introducing an unnecessary backend to handle sensitive plain text is a massive security risk. It creates a vulnerable middleman. If you are handling legal documents, corporate strategy, or raw source code, sending that data to an unverified third-party server just to convert a format is unacceptable.

The Zero-Backend Approach to Productivity

The solution isn't to stop using productivity tools; it's to re-engineer how they handle data. The most secure data is the data you never collect.

When I looked at the friction of manually copy-pasting long AI conversations—fixing broken Markdown tables, sanitizing code blocks, and re-formatting headings in Microsoft Word—I knew a tool was needed. But it had to be built with a strict privacy-first, zero-retention architecture.

That is exactly the philosophy behind FreeLabTools.com.

Instead of building a cloud wrapper that intercepts your data, FreeLabTools operates as a lightweight, native browser extension. The core extraction and mapping logic happens right where the data already lives: your active browser session.

How It Works Under the Hood

Client-Side Execution: The extension reads the semantic HTML/Markdown directly from the official chat interfaces (ChatGPT, Claude, etc.).
Stateless Processing: The conversion from web format to a clean, native .docx file happens instantly without logging your conversation history in a database.
No API Keys Required: Because it works on top of your existing browser session, you don't need to input your OpenAI or Anthropic API keys into a third-party dashboard.

By keeping the heavy lifting out of a centralized database and utilizing a highly optimized architecture, we eliminate the latency of server round-trips and completely neutralize the data-leakage risk.

Moving Forward

We need to start treating AI outputs with the same security rigor as our production databases. The next generation of developer tools and productivity SaaS won't just be measured by how many features they have, but by how little data they require to function.

If you are tired of wrestling with manual formatting and want to export AI chats to clean Word documents with zero privacy compromises, check out the architecture and the tool at FreeLabTools.

I'd love to hear your thoughts: How is your team currently handling the friction between raw AI outputs and secure corporate documentation?

How We Added E2E Encryption on Top of a Local-First Architecture

Thu, 21 May 2026 11:48:34 +0000

I used to track my finances in an app. Salary, loans, small transfers, all of it. At some point I got curious whether the team behind it could actually see those numbers in their database. So I wrote them and asked. They never replied.

That stuck with me. When we started building Finsight, I did not want our users in that same spot, wondering what happens to their data on someone else's server. So privacy went into the architecture from day one, not added later, not bolted on before launch.

The goal was simple: data should be inaccessible not because the team promises to behave, but because technically the team cannot read it even if they wanted to.

HTTPS Is Not End-to-End

HTTPS protects the connection between the phone and the server. That is necessary, but it only covers the wire. Once the request lands on the server, the data sits there in plain text. If a transaction amount of 530 arrives, the server sees 530, period.

Encrypting the database on the server does not help either. It protects against stolen disks and leaked backups, but while the server is running it decrypts data on the fly and reads it like anything else. Inside the application layer it is still plaintext.

So at some point the server sees balances, notes, and amounts anyway. We wanted to eliminate that moment entirely.

Where We Drew the Line

In a previous article we covered the move to local-first. The short version: every user has their own SQLite database on their device. The UI reads and writes directly to it, so everything opens instantly and works offline. PowerSync runs in the background and keeps the local database in sync with the server.

That solved the performance problem. But it raised another one: data travels constantly between the device and the server, and anyone along that path could potentially read it.

Our answer was to encrypt sensitive fields directly on the device before PowerSync sends anything. What reaches the server is already scrambled. Only a client holding the key can decrypt it. The server never sees the key.

input  --> plaintext into local SQLite
       --> encryption on the client
       --> ciphertext into the sync table
       --> PowerSync carries ciphertext to the server
       --> another device receives ciphertext
       --> client decrypts locally
       --> UI reads normal plaintext again

For PowerSync these are just rows. It does not need to understand what is inside them.

Two Tables Instead of One

If we encrypt data before sending it, the UI has a problem: it needs the values in readable form. You cannot render a transaction list from scrambled strings, and a monthly expense filter would not work on them either.

So for every sensitive entity we maintain two tables.

One is local, with plain values, and the UI reads from it. In PowerSync these tables are marked as localOnly and never leave the device. The second is the sync table, with the same records but sensitive fields already encrypted. PowerSync moves this one between the device and the server.

For an account the schema looks like this:

// Local table with plain values, never leaves the device
export const accounts = new Table(
  {
    organization_id: column.text,
    name: column.text,    // plaintext
    balance: column.real, // regular number
    currency_id: column.text,
    // ...
  },
  { localOnly: true }
);

// Sync table with the same fields, but name and balance hold ciphertext
export const accountsEncrypt = new Table({
  organization_id: column.text,
  name: column.text,    // encrypted
  balance: column.text, // text instead of real because it holds ciphertext
  currency_id: column.text,
  // ...
});

The same pair exists for every sensitive entity:

accounts        --> accounts_encrypt
transactions    --> transactions_encrypt
debts           --> debts_encrypt
loans           --> loans_encrypt
loan_payments   --> loan_payments_encrypt

We do not encrypt entire rows, only specific fields: amounts, balances, notes, lender names, interest rates. Things like dates, user and organization IDs, and relations between records stay visible. Without them the server cannot route rows to the right devices.

That is a tradeoff, and there is more on it below.

How It Works in Code

When a user creates an account, the UI writes a row to the plain accounts table. No encryption yet, no sync. Just a normal insert into the local database.

The database itself is a PowerSyncDatabase instance. On initialization it gets a schema with all the tables and a filename where SQLite will store the data on the device:

import { PowerSyncDatabase } from '@powersync/web';

const db = new PowerSyncDatabase({
  database: { dbFilename: 'finsight.db' },
  schema: AppSchema, // all tables, both local-only and sync
});

From there it gets interesting. PowerSync can subscribe to changes and notify which tables just changed. We use that as a trigger to run the crypto layer:

// Fires every time one of the tables changes
db.onChange({
  onChange: async ({ changedTables }) => {
    for (const table of changedTables) {
      await handleTableChange(table);
    }
  }
});

The handleTableChange function is a simple router. It looks at the table name and decides which direction to go: encrypt freshly written data before it gets sent, or decrypt incoming data from the server so the UI can display it.

async function handleTableChange(table) {
  // User changed something locally, encrypt and write to the sync copy
  if (table === 'accounts')     return encryptAccounts();
  if (table === 'transactions') return encryptTransactions();

  // Encrypted row arrived from the server, decrypt for the UI
  if (table === 'accounts_encrypt')     return decryptAccounts();
  if (table === 'transactions_encrypt') return decryptTransactions();

  // ...debts, loans, payments follow the same pattern
}

Both directions are needed. The first makes sure data gets encrypted before PowerSync picks it up. The second makes sure anything that arrived from another device gets turned back into readable numbers and strings so the UI can show it right away.

After that, PowerSync looks only at the encrypted tables and sends accumulated changes to the server in batches. On the backend they map to regular Django models. The Transaction.amount field is declared as TextField rather than a number because it holds ciphertext. The server stores the string, returns it on request, and cannot read what is inside.

Keys

Everything depends on a key the server does not know. If the server had it, e2e would be pointless.

We use a two-layer scheme. Each organization has a main key called the DEK (data encryption key). It is what actually encrypts the financial fields. The DEK is a random sequence of bytes that no one types or memorizes.

The DEK itself is also encrypted, wrapped by another key called the KEK (key encryption key). The KEK is derived from the user's secret key, a passphrase they set specifically for data encryption and separate from their account password. The derivation uses Argon2id from libsodium, an algorithm designed to make passphrase brute-forcing computationally expensive.

secret key + salt  -->  KEK
random DEK         -->  encrypted DEK (wrapped by KEK)
DEK                -->  encrypted financial fields

The server stores only the encrypted DEK and its metadata. It never sees the raw DEK, the KEK, or the secret key.

The upside is that changing the secret key is cheap. Instead of re-encrypting every transaction and account, we just unwrap the DEK with the old KEK and re-wrap it with a new one derived from the new key. The DEK stays the same, so all the encrypted data stays untouched.

The downside is that without the secret key and without a backup, the data is gone. The server has no plaintext copy to recover from. No support ticket fixes this, because the server genuinely does not have the key.

What Gets Harder

The encrypt() call itself takes three lines. The complexity lives around it.

Validation. Before e2e, most business rules ran on the server. An amount came in, the server checked it against the balance and the constraints. Now the server sees a string like eyJhbGciOiJBMjU2R0NN... and cannot say anything meaningful about it. Some checks moved to the client. The server still handles access control, relational integrity, quotas, and structure, but it can no longer verify what is actually inside an encrypted field.

Debugging. When a user reports a discrepancy, it used to take two minutes to look up the row in PostgreSQL. Now those fields are base64 strings unreadable without the user's key. Reproducing the issue means working on the client: inspecting local SQLite, checking the upload queue, looking at sync state. The server database stopped being the place where you look for answers.

Logging. The server should never see plaintext. But the client sees it constantly, before encryption and after decryption. Client logging has to be designed deliberately so a routine log line does not accidentally capture an amount or a note.

Device load on first sync. When a user signs into a fresh device, the full history has to come down and every single row needs to be decrypted locally. The server cannot help with that part. Early on we hit real bugs from this: rows arriving in batches, decryption running in parallel, race conditions and UI stalls while everything was still catching up.

What the Server Still Sees

With e2e the server does not see nothing. It sees a lot of metadata, and that is worth saying plainly.

The server knows who the user is and which organization they belong to, the IDs of every record, the fact that transactions and accounts and debts exist, their dates and types, relations between records, creation and update timestamps, and the size of each encrypted value.

Metadata alone can say quite a bit. The server may not know the transaction amount, but it can see that health-related transactions tripled this month. Or that a new currency appeared in the account list.

So I do not call e2e full invisibility. The heaviest financial values — amounts, balances, rates, and notes — do not reach the server in plain form. But the shape of the data, who has what and when, is visible to the server. That is the actual line we drew, nothing more.

E2e in production is not a weekend project. It shifts how you think about the backend, the client, validation, and debugging. The backend knows less. The client takes on more responsibility.

If your product does not handle sensitive data, this complexity is probably not worth it. But when a finance app holds a real piece of someone's life, it becomes clear why you would build it this way. That is what we did in Finsight.

Secure calculator vault for desktop

Sun, 17 May 2026 13:08:30 +0000

secure calculator vault hide and encrypt file. we use AES 256 encryption to encrypt the file. without opening a vault with right password file won't open by other if the third person got the files. also added the built in media viewer so user don't need to leave the app to see this.

For install on Microsoft store :- https://apps.microsoft.com/detail/9N000B136679

supported image extension by media viewer :- png, jpg, jpeg, gif, bmp, webp, svg, tif, tiff, ico

supported video extension by media viewer :- mp4, mkv, mov, webm, avi, mpg, mpeg, ogv

supported text extension by media viewer :- txt, csv, md, log

supported pdf extension by media viewer :- pdf

when user remove the file from the app it automatically decrypt the file.

it's a offline app, Files stay on users device, no background data collection, no ads, no analytics, no user tracking, it support windows 10 and windows 11.

GPS Stamping Security: Stop Fraud with Encrypted Anti-Spoofing

Sat, 02 May 2026 12:19:06 +0000

If you run a cleaning, security, or field service business, you know that a GPS stamp isn’t just ‘where you are’. It is a legal test that must withstand challenges, inspections and attempts at fraud. In 2026, with increasingly stringent GDPR regulations and increasingly sophisticated GPS spoofing apps, only a few solutions offer complete security. Today I’ll explain why GeoTapp is different — and how it really protects you when things get serious.

The problem: GPS stampings are easier to make up than you think

The most common GPS stamping apps are based on coordinates provided directly from the phone. The problem is that anyone with a minimum of technical expertise can install fake GPS apps to simulate positions, activate developer mode to generate false coordinates, or root the device to completely bypass integrity checks. These tools are easily available online, often free of charge, and are used by dishonest employees to stamp from home while saying they are on the construction site. The result, for companies that trust unprotected systems, are thousands of euros in unworked hours that are paid regularly every month without anyone noticing

And it’s not just a matter of internal fraud. GPS data is often saved in plain text on the provider’s servers, accessible in the event of a computer breach. At a time when European data protection regulations are becoming increasingly strict, having the location data of your employees exposed is a legal risk that you cannot afford. A single inspection by the Privacy Guarantor, motivated by inadequate management of geolocated data, can cost you much more than the cost of a
secure system for years.

Encryption isn’t optional in 2026. The Privacy Guarantor requires that geolocation data be managed with explicit consent and adequate protection. But there’s a huge difference between a system that declares GDPR compliance on its site and a system that actually implements end-to-end zero-knowledge encryption. Most GPS stamping systems encrypt data in transit — so-called HTTPS — but save it in plain text on the provider’s servers. This means that if the provider is hacked, or if they receive an access request from an authority, all your location data is exposed

GeoTapp uses AES-256-GCM encryption with zero-knowledge architecture: GPS coordinates are encrypted directly on the employee’s device, before they are even transmitted to the server. The server receives and stores only encrypted data that it cannot read without the company’s decryption key. This means that not even GeotApp itself can access the positions of your employees: only your company, with its own keys, can view the data in plain text. This is the same logic that encrypted messaging applications use, applied to corporate stamping. No other Italian system available to SMEs combines this level of protection with real operational functionality.

GPS anti-spoofing: four levels where most stop at the first

Basic anti-spoofing checks – such as the simple geofence that checks if you are inside an area – are not enough against those who know how to bypass them. GeoTapp implements four levels of validation that act in combination, making it virtually impossible to successfully falsify a stamp. The first level detects the presence of fake GPS apps active on the device and blocks the stamping if developer mode is active: this alone eliminates 90% of spoofing attempts by non-technical users

The second level verifies the integrity of the device itself: anti-root checks on Android and the detection of abnormal patterns on iOS identify phones modified to bypass security controls. The third level analyzes the quality of the GPS signal: a position with suspicious accuracy or coming from a signal inconsistent with environmental conditions is automatically flagged or blocked. The fourth level combines advanced geofence with velocity check: if a stamping takes place in a position compatible with the construction site but the employee has moved at an impossible speed compared to the previous one, the system detects it and reports it to the administrator. The result is stamps that are defensible in court, as required by Article 27 of the GDPR for
geolocated data.

GeoTapp vs. the competition: the honest comparison

System	Zero-Knowledge Encryption	Anti-Spoofing	GDPR Compliance	Price (SME)
GeoTapp	AES-256 client-side	4 levels (root, mock, geofence, signal)	Full (terms + privacy at install)	€24/user/year
NoBadge	Server-side	Base (fake GPS only)	Standard	€30+/user/year
Hoida	Standard	Lightweight	Standard	€25+/user/year
TimeTrakgo	None	Geofence + speed	Basic	$20+/user/year

The most important fact is not the price — GeoTapp is still competitive — but the combination of features. Zero-knowledge encryption and four-level anti-spoofing are not luxury features: they are minimum requirements for those who work in industries where stampings must withstand legal inspection. GeoTapp is between 2-5% of systems that combine both. Most stop at basic GPS or server-side encryption, which is like putting a padlock on the door but leaving the
window open.

Why choose GeoTapp for your cleaning, security or installation company

For the owner, the benefits are immediate and measurable: billable hours increase because each intervention is documented, the audit reports are ready for use without manual reconstructions, and automatic invoicing reduces the cycle time from the end of the work to the collection. For honest employees, GeoTapp is a tool that protects them: if a customer disputes their presence, the system provides objective proof that he was where he should be, protecting him from unfounded accusations. For the end customer, receiving an invoice with GPS evidence of the intervention increases trust in the supplier and reduces the incentive to dispute

If you want to stop worrying about the security of stampings and start using GPS data as a tool for business growth instead of as a source of disputes, GeoTapp is the natural choice. The system is installed in less than an hour, team onboarding takes less than five minutes per person, and the results in terms of reducing disputes and increasing billed hours are already visible in the first operating month. Visit geotapp.com to request a free demo and see the four levels of anti-spoofing in action
on your operating reality.

Originally published on GeoTapp Blog. GeoTapp is a GPS-verified field work documentation platform — try it free.

Coder Legion - Recent posts tagged privacy

A breach claim is trending? Ask three questions first

What a breach claim usually is

Question 1: who is the source?

Question 2: do the numbers agree?

Question 3: who has verified it?

If you might be affected

If your organisation is named

Questions people ask

Sources

[OC] I built a free, open-source HIPAA DICOM anonymizer for medical imaging

The Problem

What It Does

1. Strips All 18 HIPAA Patient Identifiers

2. Deterministic UID Pseudonymization

3. Image Integrity

4. Date Reduction

Tech Stack

What It Looks Like

Directory Batch Processing

Robustness

Installation

Windows Standalone (No Python Required)

From Source

Design Tradeoffs

The DicomAnonymizer Class

What's Next

Feedback Welcome

I Built a Browser-Based GIF Compressor That Keeps Your Files on Your Device

How to Enable MAC Address Randomisation in Linux Desktop

Why a Persistent MAC Address Is a Problem

How This Project Solves It

Installation

Debian based

Other distros

Obsidian Plugin Error Logging Without Telemetry

Start with the policy boundary

Use a bounded local ring buffer

Serialize writes

Redact before storage, not before upload

Test the redactor like a security boundary

Capture global errors carefully

Give the user inspection controls

Reporting should be user initiated

Be honest about blind spots

Keep network behavior separate from diagnostics

Verification and execution checklist

# 🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

🧅 MyZubster: Our First Tor v3 Onion Pilot Is Running!

🚀 What works so far?

🌍 Why are we building this?

👨💻 What's next?

🤝 Developers wanted!

@fuck.it - email with attitude

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source

🧅 MyZubster Is Expanding Toward the Tor Network — Building an Onion Service with Our Open-Source Contributors

👨💻 Recognizing Our Contributors

🌐 What Are We Building?

✅ What We've Already Tested

🔍 An Interesting Challenge We Discovered

🛠️ What We Still Need to Complete

🤝 Calling Developers Who Want to Contribute

🚀 Join the MyZubster Open-Source Journey

OpenSource #Tor #Docker #Privacy #NodeJS #React #Linux #WebDevelopment

Offline-first with no server: why HelperBook is local-only

canonical_url: https://abhishekgoyal.me/writing/offline-first-without-a-server

The data is the reason not to have a server

No sync engine to design

Building the honesty into the data model, not the UI

Release engineering without a backend to hide behind

What I’d tell another builder

Converting HEIC to JPG Entirely in the Browser: A Privacy-First Approach

A Practical Response Checklist for Account Alerts After Network Changes

Why services react to changes in sign-in context

Network change is one signal, not the whole decision

Read the alert details before acting

Verify the sign-in through the service itself

Avoid assuming the VPN caused every alert

Reduce avoidable confusion without bypassing controls

What to record for a legitimate repeated alert

The `DicomAnonymizer` Class