Privacy & Security Glossary

This is the clearest sign of whether the key model is real. If the provider can restore your files after a forgotten password, it holds a copy of the key or a way to rebuild it. If it cannot, the data is gone when the password and any recovery key are gone. The honest answer is neither good nor bad: it is the price of the protection, and a review states it plainly so the choice is made before the files are uploaded, not after the lockout.

This is a narrower claim than "anonymous" — a product with no account requirement can still log your IP address or run analytics on your session; it just doesn't tie your usage to an identity you registered. Treat it alongside IP anonymization and the storage model as three separate facts, not one privacy score: a product can require no account at all and still store every conversation in plaintext on its servers.

An account ties your codes to an identity the vendor can see: an email address, a phone number, or an account on a platform you already use. That is not a flaw in itself, but it is something the app asks for in exchange. When an app needs an account only for an optional sync, the review shows it as optional next to the backup setting; when it is needed to use the app at all, the review shows it as required.

The point is that the keys sit on a device with no path to the internet, so malware on your computer cannot reach them. Signing then needs a few more steps: the transaction is prepared on a connected device, carried across as a code or file, checked on the signing device's screen and carried back. Not every hardware wallet works this way; many connect by USB or Bluetooth.

Almost no provider is fully anonymous in practice. An email-free account still leaves a payment trail unless you paid in cash or with a coin that is not trivially traceable, and card or PayPal payments hand the provider a name regardless of what the signup form asked for. Check the details rather than the claim: some providers accept crypto but still require an email for the receipt; some accept an alias email but store it indefinitely. This reduces what the provider could disclose if compelled, which is a different and narrower thing than hiding your traffic — the connection itself still reveals your IP to the provider while you are connected.

The two strategies are not interchangeable. Uniformity (Tor Browser, Mullvad Browser) puts you in a large identical crowd and is the stronger defence, but it costs letterboxed windows and blocked customization, and it weakens the moment you resize a window, install a font or add an extension that changes your surface. Randomization (Brave's approach) is easier to live with and does break naive fingerprints, but shifting values can themselves be a signal. A single browser-only fix does not settle it: your IP address is the identifier that persists across every defence here, which is why fingerprinting resistance and a VPN address answer different halves of the same problem. Test scores from PrivacyTests.org or EFF's Cover Your Tracks are a useful cross-check, not a verdict.

An antivirus sees files, addresses and installed software, so the vendor's policy on this data matters as much as detection. The review reads the privacy policy and records whether the data is used only to protect you, also for the vendor's own analytics, or is allowed to reach advertising or partner companies. When the policy does not make this clear the review says so instead of assuming the milder answer.

A messenger can encrypt every message in transit and then store an unencrypted copy in a cloud backup, which gives the backup provider and anyone with a legal order access to the same content. Cloud storage that is encrypted but whose keys the provider holds is better than plaintext, yet the provider can still read it or be compelled to hand it over. Check whether the backup is encrypted with a key only you hold.

A larger number is not automatically better: brokers differ in how many people they hold records on, and the number says nothing about how many requests succeed. Only a third-party test shows that.

The engine sets the ceiling on what a browser can change about privacy. Anti-fingerprinting, tracker blocking and cookie policy are mostly layered above it, but anything requiring engine changes — Gecko's resistFingerprinting, for one — is unavailable to a browser that only skins someone else's engine. It also determines who decides which web APIs exist: a Blink-based browser inherits Google's choices there and can only disable features after the fact. On iOS the distinction largely collapses, because Apple requires third-party browsers to use WebKit, so an iOS "Firefox" or "Chrome" is a different engine from its desktop namesake.

A VPN only changes your IP address — it does nothing about fingerprinting, because fingerprinting doesn't rely on your IP in the first place. Reducing fingerprinting risk requires the browser itself to normalize or randomize these signals (Tor Browser's shared-profile model is the most thorough current approach), not a network-layer tool.

A bounty shows that a vendor expects reports and has a way to handle them. It does not show that the product is free of flaws, and the payouts and scope vary: a programme that covers only the website tells you less than one that covers the wallet's code. Absence of a bounty is not a flaw in itself, especially in small community projects.

Built-in is not automatically stronger than uBlock Origin — the useful advantages are that it works before any extension loads, survives on mobile where extension support is limited or absent, and cannot be removed from the extension store. The weaknesses are that filter lists are usually fewer and less current than the community-maintained ones, and per-site control tends to be coarser. Ad blocking and tracker blocking also get conflated: a browser can hide ads while still allowing the analytics requests behind them, so read which lists are enabled rather than the headline. Note separately that a blocker changes the requests your browser makes, which slightly changes how you look to a fingerprinting script.

This is a real limitation, not a knock against the feature existing — a browser-only proxy is still useful for changing your apparent location inside that one browser. But it's not a substitute for a device-wide VPN if the goal is protecting all of a device's traffic, and free tiers often offer only a handful of general regions rather than specific countries.

A bundle can be good value, but each extra tool is a separate product with its own privacy questions, and the antivirus review covers only the antivirus. The list shows what is included; it does not say how good any extra is.

In an encrypted storage service the certificate authority is often run by the provider itself. That is simpler for users, but it moves trust back to the provider: if its servers or its signing process were compromised, an attacker could get a certificate for a key of their own and hand it to you as your contact's key, then read what you share afterwards. Comparing a key fingerprint with the other person over a separate channel closes that gap, where the app offers it. Files you never share are not exposed this way.

It covers the core use case well for a lot of people, but it's tied to one browser (no cross-browser vault) and offers a narrower feature set than dedicated password managers — no secure notes, no shared vaults for a family or team, and no independent security audit history of its own to point to.

Many products ask a server before judging a file, because the server knows about threats seen minutes ago. The privacy question is what travels. Sending a hash (a short fingerprint of the file) or a web address reveals less than uploading a suspicious file in full, but an address list over time still describes where you browse. Some products can upload whole files, and a document that was only flagged by mistake then leaves the computer. A review records what the vendor's documentation says is sent and says so plainly when the documentation does not answer.

Without coin control the wallet picks the inputs for you, and it may combine coins you would rather keep apart, for example coins received from a shop and coins received from an exchange. With it you decide. The feature is meaningful only on networks built from separate outputs; on account-based networks such as Ethereum there is nothing to choose, and a review marks the field as not applicable.

When a document is edited in the provider's web editor, the server has to process its content, so the provider can technically read it even if the files you merely store are encrypted. Some services build editing into an encrypted workspace, which usually means fewer features. A review separates the two: whether the documents you edit together stay unreadable to the provider, or are processed on its server.

Hashing a phone number gives little protection on its own, because the number of possible phone numbers is small enough to enumerate. Phone-based discovery also exposes your address book to the operator, and storing the address book as-is exposes it most. Username-based discovery avoids both, but you have to exchange identifiers with each contact yourself.

When you share an encrypted folder, the app encrypts the folder's key with the recipient's public key, which it gets from the provider's server. If that server is compromised, it could hand you a key that belongs to an attacker, and everything you share afterwards would be readable by them. Comparing key fingerprints with the other person rules this out for that contact. Where verification is optional, the protection applies only to the contacts you have actually verified.

Deduplication saves the provider disk space. The side effect is that the fingerprint of a file is the same for every user who uploads it, so a provider holding the fingerprint can tell whether you store a file it already knows, such as a document that circulates publicly, even though it cannot open your copy.

This is the main defence against lock-in, and on most privacy-focused providers it sits behind a paid plan. Setup means DNS records — MX to route mail, plus SPF, DKIM and DMARC so your mail is not filed as spam — which the provider generates but you add at your registrar. Two things to check: how many domains and how many addresses per domain the plan allows, since catch-all addressing is what makes per-service aliases on your own domain practical; and whether the provider supports the domain in its encrypted-mail features and not just as forwarding. The domain registration itself is separate from the mail provider, and the registrar's WHOIS privacy is its own question — an owned domain can publish your name and address unless privacy protection is on.

Judge three things. What was actually taken: source code and internal documents are one class of loss, customer metadata another, and copied vault or mailbox contents another again. How the disclosure went: a timeline that expands after the first statement is a pattern worth weighing, and LastPass's 2022 incidents are the reference case — the August disclosure reported source code and technical information taken with no evidence of access to customer data or encrypted vaults, and the December update then described a threat actor copying a backup of customer vault data, using credentials obtained in the earlier incident [1]. What the architecture contained: in that same case the sensitive vault fields stayed AES-256 encrypted under a key derived from each user's master password, while unencrypted fields including website URLs, names, billing and email addresses, phone numbers and IP addresses were in the copied backup [1] — a concrete illustration that zero-knowledge encryption protects the secrets and not the metadata around them. A clean record is weak evidence on its own, since it also describes every provider too small or too young to have been targeted yet.

Brokers come in two broad kinds: people-search sites that show a profile to anyone who types a name, and companies that sell lists for marketing, risk scoring or background checks. The brokers a service lists are the ones it files requests with; a broker outside the list is not touched.

Whether a product ever shared user data is a fact about the past; what the vendor does now is a separate question, covered by its current policy. The review describes the case with sources, without judging words, and states what the vendor changed after it came to light.

A removal service has to hold the same details it is trying to remove from brokers, which makes it one of the most data-heavy products a reader will sign up for. What it asks for and what it keeps are listed in each review.

Sync is what makes cloud storage behave like a normal folder. It is also where private services differ: encrypting and decrypting on your machine takes work the provider's server does not do for you, so some services have sync only for some systems, or none at all and only a web interface. The review lists the platforms the app runs on.

It only limits what stays on devices; it cannot stop a recipient from taking a screenshot or copying the message first. It does not remove copies in backups unless the backup follows the same rule.

The protection is real only if the two hops are meaningfully separated — different datacenters, ideally different jurisdictions and different hosting providers. When both hops sit in infrastructure the same operator controls, an adversary with access to that operator gains both halves at once, which is the scenario multi-hop is supposed to prevent. Some providers let you choose both endpoints; others offer fixed pairs only. This is a defence against a network observer at one end, not against a provider that logs, so it does not substitute for a credible no-logs record.

The label "encrypted" hides this difference more than any other. Encryption in transit (between your phone and the operator's server) is not end-to-end: the operator can read the message on the server. When end-to-end encryption exists only as an opt-in mode, the everyday chat — and almost always every group — stays readable by the operator, and most people never switch the mode on. A review should always say which chat types are covered, not just that an encryption feature exists.

A password manager offering this is usually reselling or integrating a separate service (SimpleLogin, Fastmail's masked email, DuckDuckGo's Email Protection), so the alias provider is a party you are trusting with your mail flow even though the feature appears inside the manager. Check two things: whether replying from an alias works, since forwarding-only aliases break any conversation you need to answer; and whether aliases live on a shared provider domain or your own, because a recognizable alias domain gets blocked by some signup forms and marks you out. Aliases separate identities, they do not encrypt anything — the mail still arrives in whatever inbox you forward to, under that provider's terms.

A backup solves one problem and creates another. It protects you from losing access to your accounts when the phone is lost, but each extra copy of the secrets is another place they can be read. Four things separate backups: whether one exists at all, where it goes (a file you save, your own cloud storage, or the vendor's servers), whether it is encrypted with a password or key only you have, and whether it is on by default or off until you turn it on. A backup encrypted with a key the vendor can reach protects against outsiders, not against the vendor. A review states each of these separately instead of calling the app "synced".

Almost every cloud service encrypts data at rest, so the phrase on its own says little about privacy. The question is who holds the keys. When the provider manages them, its systems decrypt your files whenever they serve, scan, preview or index them, its authorized staff can reach them, and a court order or government request can make it hand them over. Encryption that keeps the provider out has to happen on your device, with keys the provider does not hold, which is what a review means by keys held by the user.

The key-derivation function matters as much as the cipher: a weak KDF with too few iterations makes a stolen encrypted vault easier to brute-force offline, even though the cipher itself (AES-256, XChaCha20) is not the weak point in that scenario.

Sharing is where the key model is tested, because the recipient needs a way to decrypt. Services that keep protection typically put the decryption key in the part of the link after the # sign, which browsers do not send to the server, or exchange keys between accounts. Others switch off the protection for shared items, or only keep it for some modes, such as sharing with another user of the same service but not by public link. Whoever you share with also matters: a link that anyone can open is only as private as wherever the link ends up.

This is separate from zero-access encryption on an email or password vault — it's specifically about the browser's own sync feature, and some browsers only encrypt certain data types (passwords, say) while syncing others (like open tabs) in the clear.

Most authenticators build on an open standard, so the secrets themselves are portable in principle: the otpauth link that a QR code carries holds the account name, the secret and the code settings. Whether you can get them out is a separate decision by the app. A review lists whether all codes can be exported, in what formats (an encrypted file, a plain file, QR codes, otpauth links), and whether the app reads files from other apps, without naming those apps. An export file in plain text holds every secret unprotected and should be treated that way.

This is the difference between encryption that works only between accounts on the same service and encryption that works with anyone. Within one provider, end-to-end encryption is automatic and invisible; the moment you write to a Gmail address it is PGP or nothing. The practical friction is real: the recipient needs a key and a client that uses it, and getting a correct key is the hard part. Two limits hold regardless of provider. Subject lines and headers — who wrote to whom, and when — are not encrypted by PGP, so the metadata stays readable. And check whether you can export your private key: a provider that manages PGP for you but will not release the key has made your encrypted archive unreadable anywhere else.

False alarms cost time and can lead people to switch protection off or to delete a harmless file. Independent labs publish a count of false alarms in their tests next to the protection score; a protection score should be read together with it.

An uploaded file is a different — often larger and more sensitive — payload than a typed prompt, so it's worth checking whether the product's storage-model and retention claims explicitly cover uploaded files, or only chat text. Some products handle the two differently (for example, deleting chat text on a schedule but retaining uploaded files separately for longer).

Versioning is the main protection against ransomware that encrypts synced files and against accidental overwrites, since a sync folder copies the damage to the cloud. Check the retention period and whether it applies on your plan. Under client-side encryption, versioning is a design cost for the provider, because old versions take space it cannot deduplicate, so private services sometimes keep fewer versions or keep them for a shorter time.

Without it, an attacker who records encrypted traffic now and obtains a long-term key later can read everything recorded in between. Forward secrecy limits the damage of a key leak to the future, not the past.

The scan is useful for seeing the scale of the problem, and it is also how the service shows what it would charge you to fix. A free plan that does file removals is labelled a limited free tier instead.

A free tier that is genuinely usable long-term (Bitwarden's unlimited items with sync across devices) is a different proposition from one shaped to push you to pay (single device, a handful of aliases, 1 GB of mail). Check how the provider funds it, because free plans paid for by advertising or data use are the ones that conflict with what you came for — though in the privacy tools worth considering, free tiers are normally cross-subsidized by paid users instead. Two practical traps: a free email address on the provider's own domain is hard to move later, so a custom domain restricted to paid plans is a lock-in decision, not a feature gap; and free tiers sometimes exclude export, which is the one function you need if you ever leave.

Running a node is the strongest way to keep your addresses to yourself, and it also means you do not trust a server's answer about your balance. It takes disk space, time to sync and some technical knowledge. Wallets differ in how well they work with a node of your own: some connect to it directly, some only through an extra layer, and some do not allow it.

The funding model shows what the service is under pressure to do. An advertising-funded service has a reason to collect data; a donation-funded one depends on a small number of donors and may be fragile. Neither is automatically better, and a stable subscription is not a privacy guarantee.

The distinction that matters is between "doesn't currently use content for ads" and "technically cannot read it at all." A zero-access-encryption provider removes the second possibility structurally, not as a policy choice that could change.

Group encryption is technically harder than one-to-one encryption, because every member's keys have to be managed as people join and leave. Products differ: some cover every group, some only small ones or only groups created in a special mode. Check the product's own documentation for the group size and mode it applies to.

This is a categorically different kind of guarantee from where data is stored at rest: it's about who can access the data while it's actively being processed by the model, during the brief window it exists in memory in a readable form. What makes it stronger than a policy promise is that a remote-attestation protocol lets a client (in principle) verify the claim itself, rather than trusting the operator's word. In practice, whether that verification is easy, automatic, or something only a security researcher would actually do varies by product — a claim of hardware attestation is worth checking against the operator's own technical description of the attestation mechanism, not just the existence of the phrase "TEE" on a marketing page.

An HSM protects keys from theft: someone who copies a server's disks does not get the keys with them. It does not decide who may use the keys. When a cloud service keeps your file keys in its HSMs so it can restore your account or show your files on the web, the provider's own systems can still ask the HSM to unlock your data. The question for a reader is therefore not whether a provider uses HSMs, but whether your keys are in them.

Signature matching only recognises what has been seen before. Heuristics and behaviour monitoring try to catch the new, and are why labs run tests with threats found in the last days rather than only old samples. The review does not rate a product by its use of the word; it relies on named lab tests.

Self-hosting moves the trust, it does not remove it — you take on patching, backups, uptime and, for email, the deliverability work of keeping your domain out of spam folders, which is the part people underestimate. Local-only files avoid a server breach entirely but give you no recovery if the device and its backups are lost, and sync becomes your problem. Cloud hosting is the realistic choice for most people, and the questions that then matter are whether encryption happens before upload, which country the servers sit in, and who the underlying host is — a provider renting from a large cloud operator inherits that operator's jurisdiction alongside its own.

Because the code depends on a counter, the app and the site can drift apart if codes are generated and not used, so sites that accept HOTP allow a small window of counter values. HOTP is less common than TOTP and is mostly met with hardware tokens. Some authenticator apps read it, some do not.

A wallet that lets you buy coins in the app usually passes you to a partner company, and that partner may ask for a name, documents or a selfie. Whether the wallet itself collects any of it, and who the partner is, differs. Using only the parts of the wallet that hold and send coins usually involves no identity check at all.

The question is not whether a product ever had a flaw, because nearly every long-lived product has had one, but what happened and how the vendor responded. A review states what exactly was affected, when, and what the vendor did. A product with no recorded incident has not necessarily had none; it may be small or young.

Your ISP, your employer's network, and the websites you visit can all still observe an incognito session exactly as they would a normal one — the browser itself says as much in its own documentation. It doesn't hide your IP address or make you anonymous to anyone outside your device.

A test by a consumer-research organisation or an academic study counts. An audit commissioned and paid for by the service itself does not, even when the auditor is a well-known firm; reviews label it vendor-commissioned. Where none exists, the review says so.

An infostealer usually runs once, takes what it finds and leaves, so there may be no visible sign of infection. After a theft, the stolen passwords and sessions are the problem to fix, not only the file that carried the malware.

This is a narrower claim than zero-access encryption: a provider can offer this between its own users while still storing mail from outside senders (who don't have the same encryption built in) in a way it can technically read. External PGP support is the separate mechanism that extends encryption to recipients on other providers.

This protects one specific link in the chain — between you and the model provider — not your connection to the front-end product itself, which can still log your IP unless it separately commits not to. Verify this against the product's own technical documentation describing the proxy architecture, not a bare privacy-policy assertion: the mechanism (a stripping proxy layer between the user and the model API) is what makes the claim checkable at all.

The certificate covers processes: risk assessment, access control, incident handling and the like, within a scope the company defines. It is not a review of a product's encryption design or code, and it does not say who can read your files. The company chooses and pays the certification body. Two things are worth checking: which services and which customers the scope covers, and whether the certificate or audit report is public or available only on request.

"Based outside the 14 Eyes" is a marketing line, not a guarantee — a provider that keeps no logs has nothing to hand over regardless of jurisdiction, while a provider inside a favorable jurisdiction but with weak logging practices is still exposed. Jurisdiction is one input into how trustworthy a provider's no-logs claim is, not a substitute for it.

Three cases are worth telling apart. Keys held by you: the provider cannot read the content by default, which is the claim behind "zero-knowledge". Keys that depend on a setting: the keys are with you only when a setting is right, either because end-to-end protection is a separate feature you have to enable, or because the service keeps a copy of your key for password reset unless you turn that off. Until then the provider holds, or can use, a key. Keys held by the provider: files are encrypted on its servers, which guards against stolen disks but not against the provider itself, its staff or a court order. Custody also has limits that the label hides. A web version gets its encryption code from the provider every time the page loads, so a compromised or compelled provider could in principle serve altered code, and the provider still sees file sizes, access times, IP addresses and payment details whatever the key model.

A password is too short and too predictable to use as a key directly, so the app runs it through a key derivation function together with a random salt. The function is made slow on purpose: a guess that takes a fraction of a second for you takes the same time for an attacker, multiplied by billions of guesses. PBKDF2 is the older standard; it repeats a hash many times, and its strength depends on the number of iterations, but graphics cards and specialised hardware can run it in parallel cheaply. Newer functions such as scrypt and Argon2 also require a lot of memory per guess, which makes that kind of mass guessing much more expensive. Whichever function is used, a long, unique password is the main protection: no derivation method saves a password that is easy to guess.

Storage services offer escrow as a password reset by email: you click a link, set a new password, and your files are still there. The price is that the provider, or its automated systems, can use the stored key, so a court order, a rogue employee or an attacker inside its servers has a route to your files that a service without escrow does not offer. Turning escrow off usually deletes the stored copy; after that, a forgotten password means losing the files unless you are still signed in on a device that can set a new one.

End-to-end encryption protects a chat only if you are encrypting to your contact's real key. Safety codes let two people compare keys by hand, but few do. Key transparency automates that check: if a server tried to give you a different key for someone, the mismatch would show up in the record. It does not replace verifying a safety code for high-risk conversations, and it says nothing about what the app does with the messages once they are decrypted.

Implementation quality varies a lot between providers and even between platforms from the same provider — a kill switch that reliably survives an app crash doesn't always survive a full system reboot or a forced network-adapter disconnect. Independent lab testing has found leaks in some kill-switch-enabled configurations, so it's a mitigation, not a guarantee.

Independent labs such as AV-TEST and AV-Comparatives run the same set of threats against many products and publish scores for protection, false alarms and system load. A result belongs to one product version, one operating system and one period; a good score on Windows says nothing about the same product on Android. A review states which tests it relies on and for which systems, and a product the labs do not publish at all is marked as having no independent results rather than filled in from the vendor's own detection claims. These tests are repeated every few months, so a result is a snapshot, not a standing verdict.

Lifetime plans suit buyers who value a flat cost, and they are paid for by the provider's other customers and growth. Check what the plan includes, whether a larger tier can be added later, and what the company promises if it winds down. A lifetime purchase is still a bet on the company staying in business, so keep a copy of anything you cannot lose.

Reports under the ISAE 3000 standard can be either. A limited-assurance report on a removal process says less than one that tests actual results, so a review quotes the level and who paid for it.

It changes who the broker deals with, not what is removed. Services that ask you to sign one need your name and often a signature, which is one more piece of personal data they hold. Services that do not use it send requests as ordinary customers on your behalf.

A protocol's name says less than how it is used. A well-regarded protocol only protects chats in which it is switched on, and an in-house design (such as MTProto) has had less independent cryptographic scrutiny than the Signal protocol, which is not the same as being broken. Judge the protocol together with whether it is on by default and whether it covers groups.

A file called tax-return-2025.pdf in a folder called Divorce gives away a lot without anyone opening it. Some services encrypt names and folder structure with the same keys as the content, some encrypt only the content, and some do not document it at all. Even full metadata encryption leaves what the server must see to function: how large each file is, when it changes and from which IP address. When a review says nothing is known, that means the provider has not described it, not that it is safe.

Message content is only half the picture. The record of contacts, times, group membership and IP addresses is often more revealing than any single message, and it is the part most often handed over under a legal order. A claim of protected metadata should name the mechanism and be backed by the product's own technical documentation.

MPC stands for multi-party computation. In a typical setup you hold one part and the provider holds another, so the provider cannot spend your funds alone, and you cannot spend them without the provider's cooperation. That sits between holding all the keys yourself and handing them to a company. There is usually no seed phrase to take elsewhere, so what you do if the provider disappears depends on a recovery method the provider has to support.

Multi-device support has a privacy cost: every extra device holds keys, and linking one is a point of attack. It is a usability gain, not a security one, and products that avoid it are sometimes doing so on purpose.

This is a features/usability convenience, not a privacy signal on its own — switching models doesn't change how the front-end product handles your account, IP, or stored history, and different models available through the same product can still carry different training-data policies from their respective providers. Check the provider training claim separately for whichever model you actually use.

Multisig spreads the risk across keys that can sit on different devices or with different people. It also adds work: each key needs its own backup, and the setup (the number of keys needed, the wallet files describing it) must be kept as well, because the keys alone may not be enough to rebuild the wallet. Support differs a lot: some wallets build multisig in, others allow only a few combinations, and many do not offer it.

Most audits are a snapshot of the infrastructure at one point in time, not continuous ongoing monitoring — a provider can pass an audit and still change its logging practices afterward without another audit catching it. Whether the audit was a one-time check or a repeated annual engagement, and what scope it actually covered, matters more than the fact that a provider says 'independently audited.'

An audit is a point-in-time examination. Infrastructure, ownership, internal tooling and data practices can all change after the report is signed, and a new SDK or feature can introduce logging that no past audit covers [1]. Scope is the other variable: the depth of any audit depends on how much access the provider grants, so an audit that never touched the systems where logs would actually be written is worth less than its headline suggests [1]. Read three things before treating the badge as verification — who performed it, when it closed, and whether the full report is public rather than a summary the provider paraphrased. Treat it as one signal alongside jurisdiction, ownership and any real-world test such as a subpoena or server seizure that produced nothing.

Notarization works on known malware, and Apple can revoke the ticket of an app later found to be malicious. A notarized file can still be harmful: AV-Comparatives reports a Mac stealer that was distributed in notarized files.

Three gaps matter more than the label. Coverage: many products publish clients and keep the server side closed, so "open source" can describe a quarter of the system you depend on. Reproducibility: unless builds are reproducible, the binary in the app store cannot be checked against the published source, and most are not. Review: published code that nobody audits is a possibility of scrutiny, not scrutiny. Closed source is not automatically worse — an audited closed-source product with a public report can be better evidenced than an unaudited open one. Treat this as one input to trust, read alongside audit history and who owns the company.

Each broker has its own form, identity checks and waiting time, which is what the services charge to handle. Filing a request is not the same as the record being gone: the broker may confirm and delete it, hide it, or ignore the request, which is why proof of removal and re-checks matter.

Read the specifics, because "supports passkeys" covers several different levels: creating passkeys in the manager, syncing them across your devices, using them in a mobile browser (which needs OS-level autofill integration and lags desktop), and exporting them out again. Cross-manager portability arrived late and is still uneven, so passkeys can be the hardest part of your vault to move. The reason to want a manager holding them rather than Apple, Google or Microsoft is the same reason you left browser password storage: your passkeys work across platforms and are not tied to one ecosystem's account. Also treat the provider's coverage claim as separate from the sites' — many services still only accept a passkey as a second factor, not instead of a password.

A passphrase protects against someone who finds or copies the written seed phrase, because the words alone no longer give access. The cost is that it must be remembered exactly: it is not stored in the wallet and cannot be recovered, and a mistyped passphrase opens a different, empty wallet without any warning. Some people keep a small amount under the plain phrase and the rest under the passphrase.

The value is specifically in eliminating password reuse — a large share of successful account takeovers rely on the same credentials working across multiple sites. It doesn't protect against every attack (phishing, malware on the device itself, a compromised master password), which is why two-factor authentication on the vault remains a separate, additional layer.

Read three things in a penetration test announcement: the scope (the encryption, the web app, the mobile apps, the servers), the method (testers given accounts and some inside information, called gray-box, or none at all), and who commissioned it. Most are commissioned and paid for by the provider and only a summary is published; that is common practice, but it is not independent verification. Findings are usually graded by severity, and a fair summary says which were fixed.

These sites are the part of the data-broker market a reader can see for themselves: search your own name and the profiles appear. A result there can be checked by searching again, which is not true of brokers that sell data privately.

Protection on the device is a separate question from protection in a backup. An app can keep its secrets in the operating system's keystore, lock them with its own password, rely only on a screen-lock for the app, or store them with no protection at all. A keystore ties the secrets to the phone and to its unlock method; an app-specific password does not depend on the phone's lock. Neither helps if the secrets also sit in a backup protected more weakly.

Also called self-healing. It is a stronger property than forward secrecy: forward secrecy protects the past, post-compromise security recovers the future. It only helps if the attacker's access to the device has ended, and it does nothing against malware that stays on the phone.

The practical risk is recording encrypted traffic now and decrypting it years later, once quantum computers exist. Post-quantum protection applies mainly to the key exchange that sets up a chat, and it only helps chats in which it is actually switched on. A claim of post-quantum protection should say which part of the protocol it covers and whether it has been formally analysed.

A status of 'completed' is the service's own statement. Screenshots of the listing before and after let a reader see the result, though they are still produced by the service. Only a check by an outside party counts as independent.

This is separate from the front-end product's own privacy policy. Even a product that promises never to sell your data is passing your prompts to a third-party model provider (OpenAI, Anthropic, Meta, or others) to generate the response — and what that model provider is contractually allowed to do with the traffic is a separate question with a separate answer, often buried in an API terms-of-service document rather than the product's own privacy page. "Contractual no-train" is a stronger claim than a reversible opt-out default, and "unknown" should be used honestly rather than assumed favorably when the contract language isn't public or isn't clear.

A hardware wallet shipped to your home from the maker's shop leaves a record that you bought it, in the shop's data and with the carrier. Some makers sell through shops that accept cash or do not need an account, and some require an account or a delivery address. A record of the purchase does not reveal your coins, but it tells anyone who gets the data that you probably hold some.

Because profiles reappear, a service that checks monthly or continuously catches a re-listing sooner than one that checks twice a year. When a service does not state the frequency, the review says it is not disclosed rather than assuming one.

Removal is not permanent for this reason, and it is the reason services re-scan and re-file on a schedule. How often a service checks again is a separate fact in each review.

A remote node never receives your private keys, so it cannot spend your coins. What it can see depends on the network and the wallet: usually your IP address, the transactions you send through it and, on some networks, the addresses you ask about. A dishonest operator can also send your wallet wrong or incomplete data. Connecting to the node over Tor hides your IP address from it; running your own node removes the third party altogether.

Automation is faster and cheaper per request; human handling can deal with brokers that reject automated forms or require extra identity steps. The method says how the work is done, not how well.

Open source alone does not guarantee that the app you install matches the code that was published. Reproducible builds close that gap. Few messengers offer them for every platform, so check which platforms are covered.

An outside observer sees the real input and the decoys side by side and cannot tell them apart, as long as the wallet picks decoys that look like real spending. If the wallet's choice of decoys has a pattern, the real input can stand out: this is why bugs in decoy selection count as privacy vulnerabilities even though no funds are at risk.

It breaks IP-based correlation only. A site that has already set a cookie, has you logged in, or fingerprints your browser follows you straight through an address change, so rotation does nothing about the tracking most people actually encounter. It can also work against you: rotating mid-session logs you out of services that bind a session to an address, and triggers CAPTCHAs and fraud checks. Worth distinguishing from a dedicated IP, which is the opposite trade — a stable address that is easier to allowlist and easier to associate with you.

Most wallets on Ethereum-style networks ship with one default endpoint run by the wallet company or a partner, and most people never change it. The server cannot move your coins, but it can link all addresses in one wallet to each other and to your internet connection. Some wallets let you replace the endpoint with another provider or with a node you run yourself; on some networks inside the same wallet that option is missing.

Phones and Chromebooks run every app in a sandbox. It limits what a malicious app can read or change, and for the same reason an antivirus app inside a sandbox cannot look into other apps. Sandboxes are software and have had flaws; operating-system vendors fix them in security updates.

The point is what it does to a stolen vault file: without the key, a copied vault cannot be attacked by guessing the master password, because guessing is no longer enough. That closes the exact gap a provider-side breach opens, where the master password is the only thing standing between an attacker and the data. The cost is recovery — lose both the key and your access, and there is no reset, only whatever emergency kit or family/team recovery the provider designed. Managers without this model compensate with a strong key-derivation function and high iteration counts, which raises the cost of guessing rather than removing the option; treat the derivation settings as the thing to compare when a secret key is absent.

A secure element makes it harder to pull keys out of a stolen device. It also has a cost: the chip's design is usually closed, so a reader cannot check what the maker says about it, and trust moves from open code to the chip's maker. Some hardware wallets have one, some do not, and some have it only in certain models. The label "has a secure element" is a description of the hardware, not a measure of safety.

An audit covers a defined scope and a date, not the whole service forever. Read what was examined (the encryption design, the web client, the mobile apps), whether the report is public, and whether the findings were fixed. Most providers commission their own audits; that is normal and still useful, but it is not the same as independent verification, and a review does not call it that. A service without any audit is not marked down elsewhere: the lack only limits what the Trust & Transparency score can reach.

Three things about a phrase decide how much freedom you have. Format: a standard phrase (BIP39) can be typed into many other wallets, while a vendor's own format may be restorable only in that vendor's software, unless the vendor publishes the format or lets you export the keys. Where it is shown: a phrase displayed on a computer or phone screen passes through a device that may be infected, while one shown on a hardware wallet's own screen does not. Backup variants: some wallets can split the phrase into shares (SLIP39, Shamir backup), so that several parts are needed to restore it. A phrase is also the single point of failure: it cannot be reset by anyone.

The secret is handed over once, as a QR code or a text key, when you turn on two-factor login for a site. After that the site and the app each keep a copy, and the codes are computed from it, not sent over the network. That is why the question that matters for an authenticator is not whether the codes are random but where the secrets are kept: only on your phone, in a backup file, in your own cloud storage, or on the vendor's servers, and whose key protects each copy. A copy the vendor can read lets the vendor, or anyone who breaks into the vendor, generate your codes.

Three cases are worth telling apart. Keys held by you: the provider technically cannot spend the funds, and losing the seed phrase means losing them. Keys that depend on a setting: you hold them only after you change something, and by default the provider has access or a copy. Keys split with the provider: a design where the key is cut into parts and neither side spends alone, often called an MPC wallet. "Self-custody" is also a claim vendors make about themselves. Until someone independent has looked at how the keys are generated and stored, it is the vendor's statement, and a review shows it that way.

Self-hosting moves trust from the vendor to whoever runs the server — which may be you, with the cost of maintenance and security updates. It also means the people you talk to must be able to reach your server, which depends on the server model.

Each model puts trust in a different place. A centralized service concentrates data and legal exposure in one operator; a federated one spreads it, but each server operator can see the metadata of the accounts on it; peer-to-peer and relay models remove a central operator at the cost of speed, reliability and sometimes features.

Three arrangements are common. The vendor's servers: simple for the user, and the vendor can link your addresses to your IP address. Public servers, such as Electrum servers that anyone runs: the wallet picks one, and its operator sees the same information. Your own node: nobody else sees the requests. On public blockchains the transactions themselves are visible to everyone with any wallet; this term is about what the wallet adds on top, namely who gets to see which addresses are yours.

Official stores review apps before they are listed; other sources usually do not. On Android, sideloading is possible on every phone; on iPhone it is available only in Brazil, Japan and the European Union. Google reports far more malware in sideloaded apps than in apps from Google Play.

A phone number is the weakest identifier for privacy: it ties the account to a SIM registered, in many countries, to a real name, and it lets the service match your address book. Usernames and random IDs avoid that, at the cost of finding contacts less conveniently.

This is why an authenticator app that ties your codes to a phone number deserves a closer look. If the number is the identifier for the account that holds the codes, moving the number can open that account. An app that does not ask for a phone number does not have this exposure, which is the reason text-message codes are considered the weakest form of two-factor login.

Some wallets now upgrade an ordinary key-controlled address into a smart account instead of creating a new one, using the EIP-7702 standard. The private key still controls the address, but the account also follows the code of the contract it points to, so the safety of that contract matters too. Switching the upgrade on or off is itself an on-chain transaction with a network fee.

A company saying it is 'SOC 2 compliant' is a statement about itself. What can be checked is the report: who the auditor was, which period it covers and whether it is published or given only under NDA. A SOC report is not the same as an audit of a product's encryption: it covers the controls the service says it runs, so a review says which of the two it is looking at.

A service sold only inside a bundle has no separate price, so the cost of the removal part cannot be compared with services that are sold alone. The review names the bundle.

For checking a product, the difference is smaller than it sounds: anyone can still read the code and look for flaws. The difference shows when the company changes direction. With an open-source licence others may take the code and keep a version going; with a source-available licence that right is limited or absent. As with open source, published code does not prove that the app in the store was built from it unless builds are reproducible.

Anything you exclude from the tunnel is exposed exactly as it would be with the VPN off — your real IP, your ISP's DNS resolver, your ISP's view of the traffic. Availability is uneven: on most providers it exists on Android and Windows, is rarer on macOS, and is usually absent on iOS because of platform restrictions. Check whether the implementation splits by app or only by IP range or domain, since app-based splitting says nothing about where an app's background requests go.

The distinction that matters most in practice is between "the operator promises not to look" (server-encrypted, server-plaintext) and "the operator mathematically cannot look" (zero-access-encrypted, client-local-only). A privacy policy can change; a key the operator never held cannot be handed over under compulsion. Client-local-only has its own trade-off — it typically means no cross-device sync, since there is nothing on a server to sync from. Verify a zero-access claim against the provider's own technical documentation or a published architecture description, not a marketing phrase like "military-grade encryption."

Zero-knowledge (client-side) encryption means the vault that leaves your device is already encrypted — a breach of the provider's servers exposes encrypted blobs, not plaintext passwords, provided your master password itself is strong and not reused elsewhere. A weak or reused master password remains the single biggest way this model fails.

Every claim here is perishable, which is why it belongs with a test date and a named service rather than a checkmark. Platforms detect VPNs by identifying IP ranges registered to hosting providers, so the contest is the provider rotating addresses against the platform blocking them, and results differ per service and per server location on the same subscription. Two things matter more than a long logo list: whether the provider publishes or supports specific streaming servers, and whether support will tell you which ones currently work. This is a convenience feature, not a privacy one — unblocking capability says nothing about logging, jurisdiction or leak protection, and a provider marketing mainly on streaming access is worth checking harder on all three.

For a hardware wallet the worry is a device opened and altered in transit, or a fake one. Makers answer with tamper-evident packaging, a check of the device's authenticity at first start, and firmware that can be verified. For software the same worry applies to the app you download, which is why reproducible builds, signed releases and downloading from the vendor's own site matter. A review quotes what the maker says it does and does not claim the risk is gone.

Getting onto a suppression list is what makes a removal last. Not every broker keeps one, and it only blocks the exact details you submitted, so a profile built from a different spelling of your name or an older address can still come back.

Two distinctions carry most of the weight. First, diagnostic telemetry (a crash stack, a startup time) is not the same as behavioural telemetry (which sites you visited, which items you opened), and products often describe both with one word. Second, off by default is a much stronger position than a settings toggle, because a toggle only helps the minority who find it. Watch for the connections that are not labelled telemetry and stay on anyway: update checks, safe-browsing lookups, extension-store pings and bundled search suggestions all reach a server on their own schedule. Privacy-focused forks such as LibreWolf and Mullvad Browser exist largely to strip these out of upstream builds.

A wallet can route its requests through Tor itself, work through a Tor proxy that you set up, or not support it at all. Tor hides your IP address from the server that answers your balance requests; it does not make transactions on a public blockchain private. It also slows requests down, and a wallet that uses it for some functions may still contact other services directly.

The label covers policy, not capability. Two things matter beyond the yes: whether port forwarding is available (without it, you connect to peers but accept no incoming connections, which limits you to leeching on many trackers), and what happens to a copyright complaint the provider receives — a provider with nothing to hand over answers differently from one keeping connection records. Providers that allow P2P on a handful of locations concentrate that traffic, which is a common cause of the slow speeds people blame on the protocol.

TOTP is built on HOTP (RFC 4226), which uses a counter instead of the time. Both are open standards, which is why codes from one app can usually be reproduced by another that holds the same secret. Some apps also support push approvals, where the phone asks you to confirm a login, or vendor-specific codes such as those for Steam. A TOTP code can be typed into a fake site as easily as a real one, so it does not protect against phishing the way a hardware security key does.

Storage is how much you can keep; transfer is how much can be sent out. A service with a transfer quota may let you store far more than you can download in a month, and the limit also applies to people who open your shared links, sometimes counted per IP address rather than per account. It matters most for files shared widely and for restoring a large backup in one go; check how the quota is counted on the plan you choose before relying on the service for either.

The report shows how often a service is asked to hand data over and how often it does, by country and by type of legal process. It does not change what the company is able to hand over: if the provider holds the keys to your files, a valid order can reach their contents. In the United States, companies may disclose national-security requests only in broad ranges, so the exact number of those requests is not in any report.

The methods are not equivalent. A hardware security key (FIDO2/WebAuthn) resists phishing because the key checks which site is asking; a TOTP app does not, and SMS is weakest of all because a number can be moved to someone else's SIM. Note what 2FA does and does not cover on a zero-knowledge password manager: it guards server-side login, so it stops someone reaching your vault through the provider, but an encrypted vault file copied from the provider's storage is decrypted with your master password, and 2FA has no part in that. Which is why master-password strength and the key-derivation settings behind it still matter after 2FA is on. Storing your 2FA codes in the same manager as your passwords also collapses two factors into one — keep the manager's own second factor elsewhere.

WireGuard's smaller codebase and modern fixed cryptography (ChaCha20-Poly1305, Curve25519) generally give it faster speeds and better battery life than OpenVPN, but OpenVPN's longer track record and configurability still matter in some network environments. IKEv2 has been dropped by several major providers in recent years.

Each hides different things from different watchers: a plain proxy hides your IP from the destination site but not from your ISP; a VPN hides your traffic from your ISP but the VPN provider itself can see it; Tor removes any single party's ability to see both who you are and what you're visiting, at a real cost to speed.

A canary works only by its absence: the law in some countries can forbid a company to say it received a secret order, but it cannot easily force the company to keep publishing a false statement that it received none. It is a signal, not a guarantee. Courts have not tested how far it protects a company, it says nothing about requests the company did choose to answer, and a missed update can also mean someone simply forgot. Check how often it is updated and whether it is signed, so a forged copy is harder to pass off.

A search-enabled query typically means your prompt (or a version of it) is sent to a search backend in addition to the model — a separate data flow worth considering alongside the product's core IP-anonymization and storage-model claims, since the search step doesn't automatically inherit the same protections as the chat request itself unless the provider says so explicitly.

Encryption alone doesn't make one VPN as trustworthy as another — the provider running the server can see your traffic the way your ISP normally would, which is why jurisdiction, no-logs audits, and the provider's own track record matter as much as the protocol used.

This comes from the service's privacy policy. When the policy does not let a reader tell whether the data is used for anything besides removal, the review records it as not clear rather than as 'removal only'.

Apple says XProtect checks an app when it is opened for the first time, when it changes and when the signature list is updated, and that it also has tools that look for unknown malware by its behaviour. AV-Comparatives' 2026 Mac test covers antivirus products from other companies and does not include XProtect.

Incoming mail from outside arrives unencrypted and is encrypted on receipt, so the provider handles the plaintext for a moment before storing it — the guarantee covers storage, not the whole path. Message metadata is the bigger gap: addresses, timestamps and, on most providers, subject lines stay unencrypted because the server needs them to sort, search and deliver. That means a court order can still yield who corresponded with whom and when, which is often the information being sought. Also check what a password reset does: if the provider can restore your mailbox after you forget your password, some key escrow exists; if it cannot, a lost password means lost mail, and that trade-off is the honest sign the model is real.

The phrase is marketing, not a standard, and providers use it for different things: some mean all content, some mean content but not file names, some mean it only for a folder you set aside. Read it as a question with parts. Who holds the keys? What is covered besides file content? Does the protection survive when you share a file or edit a document with someone? What happens if you lose the password? A review marks the claim as the provider's statement until an independent audit has confirmed it, and says who paid for any audit.