Editorial guidelines

Why this page exists

Most "privacy blogs" on the open web are content marketing wearing a journalist's coat. They are written quickly, often by a freelancer who has never used the products they recommend, then edited just enough to rank for a search query. The result is the kind of article that says "in today's digital age" three times and recommends whichever VPN paid the highest affiliate commission that month.

We do not want to be that. The whole point of building Privvert was that the existing tools and the writing about them treated readers as traffic, not as people. So we wrote this page first - before we had much of a blog - to commit publicly to how the writing is going to work. If we ever drift, you can hold us to it.

Who writes the blog

Articles are written by the people who build Privvert. There is no freelance content team, no SEO agency feeding us briefs, no offshore writer farm. Every post you read on this blog has gone through someone who has spent real time inside the format, the tool, or the threat model being discussed.

We use "we" rather than personal bylines because the same small group drafts, reviews, and ships everything, and we would rather you trust the work than collect names. If a specific external expert reviewed a piece, we credit them in that piece directly.

How we research and verify

Every claim in an article falls into one of four categories, and each has its own standard of proof.

1. Technical claims about how a format or protocol works(for example, "JPEG can carry an embedded thumbnail in the EXIF segment"). We verify these against the primary specification - the ITU/ISO standard, the IETF RFC, the W3C recommendation, the vendor's own documentation - and, where possible, by writing or running code that demonstrates the behaviour.
2. Claims about what specific products or platforms do(for example, "WhatsApp strips EXIF when you send a photo, but not when you send it as a document"). We verify these by testing, with current versions, on more than one device when the behaviour might differ, and we date the observation in the article. Platform behaviour changes; "we tested this on May 2026" is more honest than "WhatsApp does X."
3. Historical or news claims (for example, the 2012 John McAfee EXIF incident, the FBI's 2025 advisory on malicious converters). We cite the original primary source - the agency advisory, the court filing, the contemporaneous reporting from a named outlet - not a secondary blog summarising it.
4. Opinion and judgement (for example, "the server-upload model has structural problems no operator can fully solve"). We label this as opinion in the prose, and we try to give the strongest version of the counter-argument before rejecting it.

Sources we trust

When we cite outside material, we try to stay close to primary sources:

• Specifications: ISO, IETF, W3C, WHATWG, ITU-T, TC39, JPEG group, Khronos, Adobe XMP and PDF specs, MPEG-LA, vendor APIs.
• Government and regulator material: NIST publications, ENISA guidance, FBI / CISA / ACSC / NCSC advisories, EDPB and ICO opinions, FTC enforcement actions, court filings.
• Academic and peer-reviewed work: USENIX Security, ACM CCS, IEEE S&P, PETS, NDSS, journal papers we can read directly.
• Reporting from outlets with a real fact-checking track record on technology and security topics, with the named reporter and the publication date.
• The actual product, document, or codebase being discussed, opened and inspected.

We do not cite content farms, scraped "tech tips" sites, undated listicles, or AI summaries of any of the above. If we cannot find a primary source for a claim, we either drop the claim or label it explicitly as "widely reported but unverified."

How we use AI

We do not generate articles with a language model and post them. Every piece on this blog is written by a person, sentence by sentence, including this one.

We do use AI tools the same way many writers now use a search engine or a thesaurus: to look up syntax for a code snippet, to remind ourselves of the name of a standard, to draft the first version of a terminal command, or to spot a sentence that has gone on too long. When AI helps, a human still has to verify and own the output. The factual claims in our articles are the writer's responsibility, not the model's, and "the model said so" is never a citation.

You can tell AI-generated privacy content from a hundred metres away: it is fluent, repetitive, oddly cheerful, and full of generic structural tells - "in today's digital landscape," "it is important to note that," tidy bullet lists with five items each starting with a gerund, no specific dates, no specific products, no opinions that could get anyone in trouble. If you ever read something on this blog that feels like that, please tell us. We will rewrite it.

Conflicts of interest and how we make money

Privvert is a product. The blog exists partly to explain the problems our product is built to solve, and we are not going to pretend otherwise. But there are lines we hold:

• No paid placements. We do not accept money, credits, free product, or "exposure" in exchange for coverage, links, or reviews.
• No affiliate links in editorial content. If a tool we recommend has an affiliate program, we still link the plain URL.
• No SEO link sales. We do not host guest posts, sponsored articles, or "you can write for us" link bait. If you email asking, the answer is no.
• Our own product gets criticised when it deserves it. Where Privvert has limits - file-size ceilings on weak devices, a tool we have not built yet, a workflow where a desktop app is genuinely better - the article should say so. Pretending our product is the answer to every question is exactly the dishonesty we wrote this page to avoid.
• Where our money comes from is disclosed plainly. Today the answer is: display advertising on the site, and that is it. If that ever changes - subscriptions, a paid tier, sponsorships, anything - we will update this page and say so in the next article.

Our privacy stance, applied to ourselves

It would be embarrassing to write about file privacy from a site that quietly logged everything you read. The blog runs on the same infrastructure as the rest of Privvert and follows the same privacy policy. In particular:

• We do not require an account to read anything.
• We do not embed third-party trackers whose business model is building a profile of you across the web. The third-party scripts we do load (analytics, advertising) are listed in the privacy policy with their purpose.
• Comments, if we ever add them, will not require handing your email to a third-party comment platform.
• The tools the blog links to are local-first by construction. The file you upload to a Privvert tool from a blog post is processed in your browser tab and never reaches our servers, the same as every other tool on the site.

Corrections and updates

When we get something wrong, we fix it visibly:

• Substantive corrections - a claim that was wrong, a recommendation that was misleading, a vendor whose behaviour changed - get a dated correction note at the bottom of the article describing what changed and why.
• Light edits - typos, broken links, a clearer phrasing - are made silently and reflected in the article's "last updated" date.
• Stale articles get a banner at the top noting when the technical landscape has moved on, with a pointer to the updated piece if there is one.
• Articles we no longer stand behind are not quietly deleted. They are updated, retracted with an explanation, or replaced - never disappeared.

What we will not write about

• How to do something illegal that has no legitimate use case. We write about defensive privacy, not operational security for crime.
• Hot takes on individuals - founders, journalists, researchers, employees - based on speculation rather than the public record.
• Vendor takedowns based on a single second-hand complaint. If we criticise a product, we have used it, read its policy, and checked our claims against the current version.
• Anything we have not done the work for. If the article would require expertise we do not have, we either get it or do not publish.

Tell us when we slip

The fastest way to make this page real, instead of decorative, is for readers to hold us to it. If a fact is wrong, a source is shaky, an article reads like a model wrote it, or a recommendation has aged badly - email us. We read every message and we would rather hear about a problem from you than from search-engine rankings.

You can read the rest of the blog here: privvert.com/blog.