Shield Assistant
User Privacy Guide
Shield Assistant
User Privacy Guide
You are using an AI chat application that was built from the ground up to keep your conversations private.
Shield NOYB involves three separate parties:
The system is designed so that the server never sees your message content, and the AI enclave processes your messages without knowing who you are.
This guide explains, in plain language, what privacy protections are in place, how they work, and what they can and cannot do. No technical background is required. Where a technical term is unavoidable, it is defined in the Glossary at the end of this guide.
This guide covers:
Every AI chat application faces the same unavoidable constraint: the AI cannot think about encrypted text. To understand your question and write a reply, it must read your actual words in plain, unscrambled form. There is no way around this – it is how the technology works.
In most AI chat apps, this reading happens on the company’s servers. That means the company – and anyone who breaks into those servers, or any government that issues a legal demand – can see every message you have ever sent and every reply you have ever received. Even if the company promises not to look, the data is right there, readable, on machines they control.
You might wonder: can’t the AI just work on encrypted data without decrypting it? A technology called homomorphic encryption could theoretically do this, but it is far too slow and expensive for real use today. So every AI app that exists today must, at some point, read your actual words.
The question is not whether the AI reads your messages – it must. The question is where that reading happens, and who else can see it.
Shield NOYB encrypts your messages before they leave your browser. They remain encrypted as they pass through the server. They are only decrypted inside a hardware-protected enclave – a sealed environment that even the server operator cannot see into. Replies follow the same path in reverse: encrypted inside the enclave, relayed through the server, decrypted only in your browser.
This is end-to-end encryption from your browser to the AI enclave, verified at every step:
Understanding who is involved helps clarify why this design works:
Your browser is the only place where your data exists in readable form. All your conversations, memories, documents, and settings live here. Your browser encrypts messages before sending and decrypts replies after receiving.
The server sits in the middle. It handles your login, checks that you are authorized, and relays encrypted messages between your browser and the AI enclave. It can see that you are using the app, when, and the approximate size of your messages – but it cannot read them. Think of it as a postal service that delivers sealed packages without being able to open them.
The AI enclave is where the AI model runs. An enclave is a special hardware-protected environment – like a sealed room with no windows. Code running inside the enclave can process data, but nothing outside the enclave (including the server operator) can see what is happening inside. Before your browser sends any data, it verifies the enclave’s identity to confirm it is running the expected, audited software. Only after this verification passes does your browser establish the encrypted connection.
Analogy: A locked safe, a courier, and a sealed vault.
Imagine you write a letter, lock it in a safe, and hand the safe to a courier. The courier can see the safe – its size, when you sent it, where it is going – but cannot open it. The courier delivers the safe to a sealed vault: a special room that nobody can look into, not even the building owner. Inside the vault, an assistant opens the safe, reads your letter, writes a reply, locks the reply in a new safe, and places it outside the vault for the courier to pick up. The courier carries it back to you, still locked. Nobody except you and the assistant inside the sealed vault ever sees the letter.
In this analogy:
The courier is just a delivery service. The building owner (server operator) cannot see inside the vault. The assistant inside the vault does not know who sent the letter.
Here is the journey your message takes, step by step:
At no point does the server ever see the actual text of your message or the AI’s response. The AI enclave sees the content temporarily to generate a reply, but it does not know who you are (the server strips your identity before forwarding) and does not store your messages after processing.
Before your browser sends any data, it verifies that the AI enclave is genuine and running the expected software. This verification is automatic and happens every time you start a secure conversation.
Your browser:
If any verification step fails, your browser refuses to send data and displays an error message explaining what went wrong. This protects you even if someone attempts to replace the genuine enclave with a fake one.
When encryption is active, you will see “Secure (EHBP)” displayed in the Session panel under Transport mode. The status bar at the bottom of the screen also confirms the connection state.
If encryption is not active (for example, during development or testing), you will see “Legacy (JSON)” instead, and a status message will inform you that the secure transport is not available.
If you see “Legacy (JSON)”, your messages are not encrypted in transit. This mode exists only for development. In normal use, you should always see “Secure (EHBP)”.
Even though your conversations are stored only on your device, someone with access to your device (or your browser profile) could potentially read them. The Local Vault adds another layer of protection: it locks your stored data with a passphrase that only you know.
Without the passphrase, your stored conversations, messages, and memories are unreadable – even if someone copies your browser’s data files.
Analogy: A filing cabinet with a combination lock.
Your browser’s local storage is like a filing cabinet in your home. Without the vault, the cabinet is unlocked – anyone who walks into your home can open it. With the vault enabled, the cabinet has a combination lock. Only you know the combination.
Setting up the vault (first time):
Unlocking the vault:
Locking the vault:
What “Locked conversation” means:
If you see “Locked conversation” in your conversation list, it means the vault is locked and the data is encrypted. Enter your vault passphrase to unlock and view the content.
There is no “forgot password” option. If you forget your vault passphrase, your encrypted data cannot be recovered. Shield NOYB deliberately does not store your passphrase or any way to reset it – this is what makes the vault secure. No one, including the developers, can recover your data without the passphrase.
Recommendation: Choose a passphrase you can remember, or store it in a trusted password manager.
Encryption is only as good as the system running it. If someone tampered with the app’s code, or if the server were not following the privacy rules, encryption alone might not protect you. The verification panel lets you check, on demand, that each part of the system is working as expected.
The verification panel displays three independent checks. Each one verifies a different part of the system:
What it checks: The code running in your browser is compared against a known-good copy stored on a public, tamper-proof network (IPFS). If the two match, you can be confident that the code has not been modified since it was published.
How it works: Your browser downloads its own code files and the published reference copies, then compares their digital fingerprints (hashes). If they match, the check passes.
Why it matters: If the server operator (or an attacker) modified the code served to your browser, this check would detect it.
Auditing the source: The compiled code you see in your browser is built from source files that are also published to IPFS. A technical auditor can fetch the source by its IPFS fingerprint, compile it using the documented tools, and confirm the result matches the compiled code fingerprint. This closes the loop: you can verify both what code runs and where it came from. The most critical source pin covers the Rust programs that generate the mathematical proofs (used in Check 2 below).
What it checks: The server generates a signed or mathematically proven receipt that attests to its current privacy policy. Your browser verifies this receipt against a list of approved policies that was published with the app.
How it works: Your browser sends a random challenge to the server. The server responds with a receipt that says “I am operating under the audited privacy policy, and this receipt is tied to your specific session.” Your browser then checks:
Two levels of proof:
The app can produce two kinds of receipt, and it uses the strongest one available:
The app requests a mathematical proof first. If the proof service is temporarily unavailable, it falls back to a signed receipt so that verification is never completely blocked.
What the proof specifically covers:
When the receipt is valid, it confirms that at the time the receipt was issued:
In the strongest version of this check, the app also verifies one measured challenge on the server’s privacy-critical forwarding path. That extra proof checks that the encrypted test message going into that measured path matched the encrypted message coming out, and that the measured path reported no decrypt call and no enabled decrypt capability for that challenge. This is a stronger spot check than a policy receipt alone.
What routes this currently covers most strongly:
POST /api/proxy/secure/v1/chat/completions POST /api/proxy/secure/v1/embeddings
Those two secure request paths now have the strongest route-level coverage. The
chat/completions route remains the main interactive AI path, and the embeddings route is
covered by a supplemental route proof attached to the same verification session.
Web search and image attachments currently travel through the same chat/completions
endpoint. That means they inherit the route-level proof for that endpoint, but they are not
yet separately proved as distinct request-body variants.
Why it matters: Even if the server cannot read your encrypted messages, you may want assurance that it is not doing anything unexpected with the metadata it can see (like logging when you use the app, or routing your messages somewhere unexpected). This check provides that assurance.
What the proof does not cover:
POST /api/proxy/document/convert route is not covered by this proof family. What it checks: The AI processing environment (the enclave) provides a certificate of its identity, which your browser verifies against expected measurements.
How it works: Before any data is sent, your browser verifies the enclave’s attestation document – essentially a tamper-evident seal on the AI environment. This happens automatically when you start a secure conversation.
Why it matters: This confirms that the AI environment is running the expected software and has not been replaced or tampered with.
Look at the status indicator in the top area of the interface. It shows the current verification state.
Click the indicator to open the verification panel with detailed information about each check.
Run the checks:
Read the results:
| Indicator | Meaning | Action needed |
|---|---|---|
| Verified Private (green) | All three checks passed | None – system is verified |
| Check Shield (gray) | Enclave is verified, but client/proxy checks not yet run | Run the client and proxy checks when ready |
| Client Check Needed (amber) | Enclave and proxy OK, but client not checked or mismatched | Run the client check |
| Proxy Check Needed (amber) | Enclave and client OK, but proxy receipt missing or expired | Run the proxy check |
| Full Check Needed (amber) | Enclave OK, but both client and proxy need checking | Run both checks |
| Unverified (red) | Enclave verification failed or not attempted | Do not send sensitive data until resolved |
Client check fails (mismatch): The code in your browser does not match the published reference. This could mean the server is serving modified code. Do not enter sensitive information. Try refreshing the page. If the mismatch persists, contact the administrator.
Proxy check fails: The server’s privacy receipt could not be verified. This could mean the server configuration has changed or the receipt has expired. Try running the check again. If it keeps failing, the server may not be operating under the expected privacy policy.
Enclave check fails: The AI environment could not be verified. Your browser will not send any data in this case. You will see an error message with details. This could be a temporary network issue. Try again later.
All of the following are stored exclusively on your device:
The server stores only what it needs for authentication:
The server does not store and cannot access:
Even with encryption active, the server can observe certain metadata:
| Data | On your device | On the server | Server can read it? |
|---|---|---|---|
| Conversation text | Yes | No | No |
| AI responses | Yes | No | No |
| Uploaded documents | Yes (parsed locally) | No | No |
| Memories and context | Yes | No | No |
| Persona settings | Yes | No | No |
| Learned profile | Yes | No | No |
| Vault passphrase | In your memory only | No | No |
| Login email | Yes (cookie) | Yes | Yes |
| Auth tokens | In browser memory | Yes (issued them) | Yes |
| Message timing | Observable | Observable | Yes (metadata) |
| Message size (encrypted) | Observable | Observable | Yes (metadata) |
| Your IP address | N/A | Observable | Yes (metadata) |
When you attach a document to a conversation (PDF, Word, Excel, PowerPoint, or text files), Shield NOYB parses the document entirely in your browser. The server never receives the file or its contents.
Supported formats:
| Format | How it is parsed |
|---|---|
| Plain text (.txt, .md, .csv, .html, .htm, .asciidoc) | Read directly by your browser (no extra tools needed) |
| PDF (.pdf) | Parsed using a specialized library loaded in your browser |
| Word (.docx) | Parsed using a specialized library loaded in your browser |
| Excel (.xlsx, .xls) | Parsed using a specialized library loaded in your browser |
| PowerPoint (.pptx) | Parsed using your browser’s built-in capabilities |
Analogy: Reading a book at home, then calling a friend to discuss it.
Imagine you read a book in your living room, take some notes, then call a friend to discuss it. Your friend hears your summary and notes, but never sees the book itself. The phone company (the server) carries your call but cannot understand it because you are speaking in code (encryption). The book never leaves your home.
For PDF, Word, and Excel files, your browser loads a small specialized tool (library) from the internet the first time you use that file type. These tools only read files – they do not send data anywhere. After loading, they work entirely within your browser.
Shield NOYB comes with five built-in communication styles (personas) that change how the AI responds to you:
| Persona | What it does |
|---|---|
| Default | Balanced, standard assistant behavior |
| Verbose | Detailed, thorough responses with examples and explanations |
| Concise | Short, direct answers – gets to the point quickly |
| Friendly | Warm, conversational, and encouraging tone |
| ICANNOTTELLALIE | Maximum honesty mode – prioritizes accuracy over agreeability |
Creating custom personas:
You can also create your own personas with custom instructions. For example, you could create a “Teacher” persona that explains things as if you are a student, or a “Coder” persona that always includes code examples.
Where personas are stored:
All persona settings – both built-in and custom – are stored on your device in your browser’s local storage. The server does not know which persona you are using or what custom personas you have created.
How to change personas:
Select your preferred persona from the Persona dropdown in the settings panel. The change takes effect immediately for your next message.
Shield NOYB can learn about your communication style and preferences over time. This is entirely optional and happens on your device.
How it works:
Your control over profile learning:
Privacy of profile learning:
Shield NOYB is available in four languages:
| Language | Code |
|---|---|
| English | en |
| Japanese | ja |
| Indonesian | id |
| Traditional Chinese | zh |
The interface language can be changed in the Settings panel. The AI itself responds in whatever language you write to it, regardless of the interface language setting.
All language translations are built into the app and work entirely in your browser. No translation requests are sent to the server.
Shield NOYB works on mobile devices (iOS and Android) through a dedicated app wrapper. The mobile version uses the same browser engine and the same code as the desktop version.
All the same privacy protections apply on mobile:
There are no additional privacy trade-offs when using the mobile version.
You can download your conversations as a file for backup or personal records:
shield_conversations_YYYY-MM-DD.json. Because your data is stored only in your browser, there is no automatic cloud backup. If you clear your browser data, switch browsers, or use a different device, your conversations will not be there. Use the export feature to create backups.
No security system is perfect. Here is an honest account of the limitations:
If your computer or phone has malware (a virus, spyware, or a malicious browser extension), it could potentially read your data before it is encrypted or after it is decrypted. Private Assistant’s encryption protects data in transit and at rest, but it cannot protect against software that has access to your browser’s memory.
What you can do: Keep your device and browser updated. Avoid installing untrusted browser extensions. Use antivirus software.
If you set up the Local Vault and forget your passphrase, your encrypted data is permanently inaccessible. There is no recovery mechanism – by design. This is the trade-off for genuine security: no one else can recover your data either.
What you can do: Use a memorable passphrase or store it in a trusted password manager. Export your conversations regularly as a backup.
When the AI processes your message, it necessarily sees the unscrambled (decrypted) content inside the enclave. This is by design – the AI cannot respond to a message it cannot read. The enclave is hardware-protected so that nobody outside it (including the server operator) can observe this step. However, you are trusting that:
The enclave also does not know who you are – the server strips your identity before forwarding. So even inside the enclave, your message is anonymous.
The server can see when you use the app, how often, and the approximate size of your encrypted messages. It cannot read the content, but these patterns could theoretically reveal usage habits. For example, someone observing the server could tell that you had a long conversation at 3 PM, but not what it was about.
When you load Shield NOYB in your browser, you are trusting the server to send you the genuine, unmodified application code. If the server were compromised, it could potentially send modified code that undermines the privacy protections. The Client check in the verification panel (Section 5) is designed to detect this, but it requires you to actively run the check.
When you first parse a PDF, Word, or Excel document, your browser downloads a small specialized tool from the internet. While these tools only process files locally and do not send data anywhere, they come from a third-party source. A theoretical attack on that source could deliver modified tools. The impact would be limited to the document parsing step – it could not bypass the encryption system.
| Feature | What it protects | How to check or enable |
|---|---|---|
| Secure transport (EHBP) | Messages in transit between you and the AI enclave | Check the Transport mode in the Session panel – should show “Secure (EHBP)” |
| Local Vault | Stored conversations on your device | Enable in Settings > Local Vault. Enter a passphrase. |
| Client verification | Detects modified application code | Open verification panel, run Client check |
| Proxy verification | Confirms server privacy policy | Open verification panel, run Proxy check |
| Enclave verification | Confirms AI runs in genuine, sealed hardware enclave | Automatic when starting a secure conversation |
| Local document parsing | Keeps uploaded files on your device | Automatic – just attach a file |
| Profile learning control | Your learned preferences | Toggle in Settings > Profile Learning |
| Data export | Backup your conversations | Use the Export panel in the menu |
| Persona selection | AI communication style | Select in the Persona dropdown |
| Language selection | Interface language | Select in Settings > Language |
Attestation A tamper-evident certificate that proves a secure computing environment (enclave) is running specific, expected software. Like a notarized document that confirms identity.
Enclave A hardware-protected computing environment where the AI runs. The protection is enforced by the hardware itself, not just by software promises – even the operator of the server cannot see what is happening inside. Think of it as a sealed vault with no windows: data goes in, results come out, but nobody outside can peek in or tamper with the process. Your browser verifies the enclave’s identity (via attestation) before sending any data.
Encryption The process of scrambling data so that it is unreadable without the correct key. Like converting a letter into a secret code that only the intended recipient can decode.
End-to-end encryption Encryption where the data is scrambled by the sender (your browser) and can only be unscrambled by the intended recipient (the AI enclave). No one in between – not the server, not the network provider, not even the server operator – can read the content.
EHBP (Encrypted HTTP Body Protocol) The specific encryption method used by Shield NOYB to scramble message bodies. It uses industry-standard cryptographic algorithms (the same family of algorithms used by major security protocols worldwide).
IPFS (InterPlanetary File System) A public, decentralized network for storing files. Files on IPFS are identified by their content – a unique fingerprint (hash) of the data. This means if the content changes, the fingerprint changes too, making tampering detectable. Shield NOYB publishes both its compiled code and its source code on IPFS so you can verify you are running the genuine version and auditors can confirm the code was built from the published source.
Passphrase A password used to lock your data vault. Unlike a typical password, a passphrase can be a longer phrase that is easier to remember (e.g., “correct horse battery staple”). Private Assistant uses your passphrase to derive the encryption key for your local vault.
Proxy The server component that sits between your browser and the AI environment. It handles login, routes your encrypted messages, and adds the necessary credentials – but cannot read the message content. Like a mail carrier that delivers sealed packages.
Receipt (verification receipt) A digitally signed or mathematically proven statement from the server that attests to its current privacy policy. Your browser can verify this receipt to confirm that the server is operating as expected. A signed receipt is like a notarized stamp — you trust the key holder. A mathematical (ZK) receipt is stronger: the math itself is the guarantee, and no private key is involved.
Zero-knowledge proof A mathematical method that proves a statement is true without revealing any additional information. In Shield NOYB, zero-knowledge proofs can be used to prove that the server is following the correct privacy policy, without requiring you to trust the server’s claim directly. It is like proving you know a password without ever saying the password out loud. Crucially, the proof can only be generated if the audited program actually ran and all its checks passed — no private key is needed to produce it.
*This guide describes the privacy features of Shield NOYB as implemented in March