{
  "schema": "org-writing@v1",
  "slug": "privacy-is-a-different-product",
  "kg": {
    "id": "org:writing:privacy-is-a-different-product",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "Privacy is a different product",
  "subtitle": "A system that cannot read your words cannot search them for you, so the private version is a second product rather than a setting",
  "abstract": "Why a private version of a product is a second product rather than a setting, and what an honest presentation of that choice owes the person making it. The canonical treatment of the plaintext condition.",
  "kind": "brick",
  "topics": [
    "Privacy"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:privacy",
      "topic": "Privacy",
      "wall": "org:walls:engineering",
      "position": 1,
      "total": 6
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "Products present a private mode as a switch inside one product, which implies everything else survives the switch, and everything else does not survive it wherever the intelligence runs on a server.",
      "claims": [
        "end-to-end encryption and server-side AI processing are mutually exclusive"
      ]
    },
    "mechanism": {
      "text": "Encryption removes the readable text that server-side intelligence consumes, so the private version and the capable version are two products rather than two settings of one, and the control between them is a boundary.",
      "claims": [
        "builds its message content search index in the browser"
      ]
    },
    "move": {
      "text": "Price the fork inside the interface, naming which capability degrades, by roughly how much, and on whose measurement rather than on nobody's.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/50-database/65-sync/privacy-modes-architecture.md"
    },
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/50-database/65-sync/e2ee-memory.md"
    }
  ],
  "canonicalPath": "/writing/privacy-is-a-different-product/",
  "body": "A privacy setting implies that the product on either side of it is the same product. Flip it on, keep everything you had, lose only the part where a company can read your files. That implication is false wherever the intelligence runs on a server, and it is false for a reason no engineering budget reaches.\n\nServer-side intelligence has to read what it works on. An embedding model reads the text before it makes a vector of it. A search index reads the text before it can rank it. A database cannot match a pattern inside a blob it holds no key for, and a distance operator cannot measure between two things it cannot decode. End-to-end encryption is precisely the decision that the server holds no key. So the mechanism is a subtraction rather than a dial: encryption removes the readable text that server-side intelligence consumes, which makes the private version and the capable version two products rather than two settings of one, and the control between them a boundary.\n\nProton ships the honest form of this and documents it in public. Message content search in Proton Mail is built in the browser and the index never leaves the device, because the server holds every message in a mailbox and no key to any of them, while the client can decrypt anything it holds but never holds the whole mailbox at once. The consequences appear in Proton's own support pages rather than in someone else's review. The index is bounded by what the browser will store, so a large mailbox displays a date past which its own contents cannot be searched, and a person on an older machine waits while the index builds. None of that is a defect. It is the product that end-to-end encryption makes possible, described accurately by the people who built it.\n\nOur own architecture notes reach the same finding in blunter language, that end-to-end encryption and server-side processing are mutually exclusive and cannot be had at once, alongside a figure for how far on-device search would fall short of the server-side path. We grade that figure as what it is. It is an engineering estimate written down before anyone measured it, and the capability it describes is not something we ship; the design sits in our documentation under an explicit ruling that it is not an active product claim. That is the part worth keeping. A fork you have not built is still a fork you can describe honestly, and describing it honestly now is what stops a flattering sentence from being written about it later.\n\nThe trade underneath is not really cryptographic. Someone choosing the private version is exchanging search that finds the thing they half remember for the certainty that nobody else can find it at all, and both of those are real goods whose prices move with what a person is carrying that year. The dishonesty is never in the tradeoff. It is in the checkbox, because a checkbox is a claim about size, and it says the thing on the other side is small. Price the fork out loud, name the capability that degrades and by roughly how much and on whose word, and the choice stops being something done to a person and becomes the thing it always was, someone deciding what their own words are for.",
  "apparatus": {
    "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.",
    "references": [
      {
        "id": "org:references:privacy-is-a-different-product:r01",
        "author": "Proton AG",
        "work": "Behind the scenes of Proton Mail's message content search, and the message content search support documentation",
        "year": 2021,
        "relevance": "The shipped public case. A production end-to-end encrypted mailbox that builds its content search index in the browser, publishes why a server-side equivalent is not available to it, and prints the resulting limits in its own support pages rather than leaving them to reviewers."
      },
      {
        "id": "org:references:privacy-is-a-different-product:r02",
        "author": "MNSTRY platform documentation",
        "work": "Privacy modes architecture, and E2EE memory (Secret mode)",
        "year": 2026,
        "relevance": "The internal source. States the exclusivity finding directly and carries the on-device search estimate the brick grades as an estimate. Both documents sit under the 2026-07-11 operator ruling that local-first delivery is reversibly mothballed, which is why the brick claims no shipping capability."
      }
    ],
    "claims": [
      {
        "id": "org:claims:privacy-is-a-different-product:c01",
        "claim": "Our platform architecture documentation states that end-to-end encryption and server-side AI processing are mutually exclusive and cannot both be had at once.",
        "basis": "The document's own executive summary, quoted in its own terms; the phrase is the source's wording rather than a paraphrase of what it measured.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:privacy-is-a-different-product:c02",
        "claim": "Encrypted content columns cannot be searched with SQL text operators, ranked by vector distance operators, or indexed, because each of those operations requires reading the stored value.",
        "basis": "Follows from the construction, and set out at length in the same architecture document's rejection of column-level encryption.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:privacy-is-a-different-product:c03",
        "claim": "Proton Mail builds its message content search index in the browser and the index never leaves the device.",
        "basis": "Proton's own engineering write-up and support documentation for message content search.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:privacy-is-a-different-product:c04",
        "claim": "Proton Mail's client-side index is bounded by the browser's storage capacity, so a large mailbox displays a date past which its own contents cannot be searched.",
        "basis": "Proton's support documentation, which states the limit and the displayed date.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:privacy-is-a-different-product:c05",
        "claim": "Our internal documentation estimates on-device search quality in a local-only mode at roughly 70 to 85 percent of the server-side hybrid path.",
        "basis": "A comparison table in the internal Secret-mode document. It is an engineering judgment recorded during design, with no benchmark, dataset, or measurement procedure attached, which is why the brick names it as an estimate and does not print the figure as a finding.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:privacy-is-a-different-product:c06",
        "claim": "The local-first and end-to-end-encrypted capability described in our privacy-mode documentation is reversibly mothballed by operator ruling and is not a shipping capability.",
        "basis": "The 2026-07-11 launch-posture ruling carried at the head of both source documents, which states that the launch profile is online-required and server-authoritative.",
        "confidence": "verified",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:plaintext-condition",
        "name": "The plaintext condition",
        "definition": "Server-side intelligence requires readable content, so any capability that runs on a server is itself a statement that the server can read what it runs on. Embedding, ranking, indexing, and reasoning all consume the text before they produce anything, and encrypted values cannot be matched, measured, or indexed by a party holding no key. The consequence is that end-to-end encryption and server-side processing are mutually exclusive rather than tunable against each other, which makes a private mode a second product rather than a setting inside one, and makes an interface that presents the choice as a checkbox a claim about size that is not true.",
        "provenance": "canonical"
      }
    ],
    "researchContext": "Harvested from two internal privacy-architecture documents, both of which\nsit under the 2026-07-11 mothball ruling. The arguments in them survive the\nruling and the implementation claims do not, so the brick carries the\nfinding and explicitly disclaims the capability. The public anchor was added\nat authoring time because the internal documents are not citable: Proton is\nthe case because it ships the fork rather than describing it, and because\nits limits are published by the vendor rather than discovered by a reviewer,\nwhich is the behavior the brick is arguing for.\n\nThe 70 to 85 percent figure is deliberately not printed in the body. It is\nan internal estimate with no measurement behind it, and printing a range\nthat precise would import a false confidence into a piece whose whole\nsubject is honest pricing. The body says a figure exists, says what kind of\nfigure it is, and moves on; the apparatus carries the number and its grade.\n\nBoundary with what-your-claim-excludes, kept on purpose: that brick argues\nfor publishing the edge of a claim. This one argues that in this particular\ncase the edge is a product boundary rather than a caveat, so the two do not\noverlap even though both touch the same documentation set."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "c7d2ba61610501b974dbbf8b2151fa3dad419ecc6387606be90b82e9880f97e7",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, privacy wave",
      "visibility": "published",
      "path": "/writing/privacy-is-a-different-product/",
      "contentHash": "sha256:b4bb994730384992",
      "releaseHash": "c7d2ba61610501b974dbbf8b2151fa3dad419ecc6387606be90b82e9880f97e7"
    }
  ]
}