Privacy Scoring Methodology

Each brand we cover is privacy-scored using the framework described here. The framework is conditional: different kinds of brands face different privacy threats, so different scoring categories and weights apply. Every score the current pipeline computes is stamped with the algorithm version that produced it, and changes to this framework do not retroactively alter past assessments: a score that predates versioning keeps its original number, is never recomputed under a newer algorithm, and is shown with its algorithm version marked as not recorded.

Current algorithm version: 2026.14

How a score is built

1. We classify the brand into a service archetype (see the catalogue below). The archetype determines which scoring categories are applicable AND how each category is weighted, so it changes the number, not just the label. The classification is proposed by an AI model and accepted automatically only when its confidence is at least 0.85; below that it waits for a person to confirm it. A grade is not published at all while the archetype is unconfirmed, because a score produced against a rubric nobody chose is a score with no stated basis.
2. We scrape the brand's privacy policy and terms of service, plus supplementary policies when available: cookie policy, GDPR and CCPA pages, security page, health-data notice, accessibility statement, lists of subprocessors and payment processors, data-deletion and access-request pages, the privacy policy of a companion app, and content moderation and scanning policies. Each supplementary document is scored for the categories it informs and no others, and every one we accept also goes into the material the summary is written from and the material a published claim is checked against. Each is checked in the same way as the main documents to make sure it is a real document, and is not counted again when it is the privacy policy or terms under another name. A grade requires the privacy policy itself: where we can find only a terms of service, no grade is produced.
3. For each applicable category, an AI model rates the brand 1 to 5 against documented criteria and reports its own confidence in the score.
4. A second AI pass independently fact-checks high-stakes claims (GDPR/CCPA policy-text signals, high-severity concerns) against the source policy text. Where the two passes disagree, the disagreement goes to a cross-provider tiebreaker where that check is enabled, and the field is downgraded to "unverified" only if the disagreement stands. Where the second pass could not run at all, the field still shows as unverified but is NOT demoted: the severity we assigned stands, and our own record says the check could not run rather than that the claim failed. The public marker is the same in both cases, so an unverified label never means, on its own, that a claim was contradicted.
5. Where the AI reports its own confidence in a category score, we check it against our floor, 0.6 by default. The core categories that apply to the brand's archetype are all required, so if any of them comes back below the floor we produce no score for that brand at all, and the run is held for review rather than published with a gap in it. From algorithm 2026.14 an answer whose confidence cannot be read is treated as not confident and triggers this check; in earlier versions a category returned with no confidence value was treated as confident and did not.
6. Independent of the AI: we run a Mozilla Observatory security-headers scan and check the brand against the Have I Been Pwned breach database.
7. The applicable category scores are weighted by the archetype's weight table, which already sums to 100 across the categories that apply, so a category the archetype marks not applicable carries no weight rather than one handed to its neighbours. Where a category that does apply could not be judged, in practice a security scan we could not run, its weight is dropped and the remaining weights are renormalised. That result is modified by transparency and terms-of-service quality, reduced for breaches we have confirmed belong to the brand, and expressed as a score with a letter grade.

How 1-5 ratings become percentages: Each category's 1-5 rating is converted to a percentage on a deliberately non-linear scale: 1 = 30%, 2 = 55%, 3 = 72%, 4 = 87%, 5 = 100%. The scale is chosen so that an "average" rating of 3 lands in the C-grade range, and it is more generous at the low end so a legitimate business with standard privacy practices is not pushed into the bottom grades. The weighted average of these percentages, using the archetype's weight table, is the base score that the modifiers below then adjust.

Service archetypes and their weight tables

Each archetype has a documented privacy threat model. The weight tables sum to 100 across each archetype's applicable categories: N/A categories are excluded entirely (no penalty, no zero contribution).

Archetype	Data Collection	Data Sharing	Data Retention	Security	Content Privacy
Hardware Product hardware-product	32%	22%	18%	28%	N/A
Connected Hardware hardware-connected	22%	22%	18%	22%	16%
Subscription Content subscription-content	20%	26%	22%	16%	16%
Live Interaction live-cam	18%	22%	18%	14%	28%
Dating / Hookup dating-platform	22%	30%	18%	14%	16%
Editorial / E-commerce editorial-ecommerce	26%	26%	18%	22%	8%
Sex-Tech / Health sextech-health	24%	22%	26%	16%	12%
AI Companion ai-companion	18%	18%	22%	14%	28%
Support / Advocacy support-advocacy	14%	24%	20%	18%	24%

Threat-model justifications

Hardware Product

Physical product with no companion app, user account, or cloud sync. Privacy footprint limited to warranty registration and customer-support contact.

Connected Hardware

Physical product paired with a companion app, cloud sync, or biometric/usage telemetry. User accounts present. Common in app-controlled toys.

Subscription Content

Pay-to-watch or pay-to-access content services. Identity, payment, and viewing history are central.

Live Interaction

Cam sites, real-time chat, and live performance platforms. Real-time audio/video and messaging amplify content privacy risk.

Dating / Hookup

Profile-based matching platforms. Photos, location, messaging, and biometric verification are common; data sharing with third parties is a known risk.

Editorial / E-commerce

Review sites, marketplaces, and editorial blogs. Account, payment, and ad targeting are typical; user-generated intimate content is rare.

Sex-Tech / Health

Cycle, fertility, or sexual wellness tracking apps. Health-grade special-category data; potential GDPR / HIPAA-equivalent regulatory exposure.

AI Companion

Conversational AI companions, virtual partners, and intimacy chatbots. The intimate conversation itself is the core asset: chat logs, emotional and sexual disclosures, and their reuse for model training drive the threat model. Persistent accounts and long-lived "memory" are intrinsic. Content privacy is weighted highest, with retention close behind because deletion that does not reach training data is the central failure mode.

Support / Advocacy

Non-commercial organisations: charities, advocacy campaigns, professional and accreditation bodies, universities, and support networks or helplines. No product is sold; the user donates, subscribes to updates, seeks support, or makes a sensitive disclosure. Protecting that disclosure, not over-retaining it, and not onward-sharing it to funders, partners, researchers or authorities is the core threat model.

Scoring categories

Data Collection

What user data is collected, how, and whether collection is minimised. Higher score = less collected, clearer disclosure.

Data Sharing

Whether data is shared with third parties (advertisers, analytics, processors), under what conditions, and with what user controls.

Data Retention

How long data is kept, and whether users can delete it. Indefinite retention without justification scores low.

Security

Independent: based on the Mozilla Observatory scan, which covers security headers and cookie flags. We also run our own direct TLS check; its results are recorded, the HTTPS check is shown on the scorecard, and they feed this score only when the Observatory scan is unavailable. Not derived from the privacy policy.

Content Privacy

How user-generated content (photos, messages, video) is protected. Not applicable to the Hardware Product archetype.

Brand pages show a compact scorecard without written category explanations. Detailed scorecards can include explanations when their category details can be opened. A category that comes back with no explanation at all is held for an editor rather than published. The explanation for Terms of Service fairness is shown only on assessments produced under algorithm 2026.13 or later. That is the first version whose instructions to the model told it to describe what the documents say and to frame an absent protection as something the reviewed text does not address, and we do not want an older explanation, written without those instructions, read as though it had them. An assessment made before that version shows its Terms of Service rating with no explanation beside it, as it always has. Where we found no terms of service to read, or the category does not apply to the brand's archetype, there is no rating and nothing to explain.

Confidence floor and verification

Per-category confidence floor: We ask the AI for its own confidence in every category it scores, and where it reports one we check it against our floor, 0.6 by default. From algorithm 2026.14 the AI chooses one of four descriptions of how far the documents support its score (settled, mostly settled, inferred, unsupported) and we convert that choice to a number ourselves, using a fixed table; an answer whose confidence cannot be read counts as below the floor. In earlier versions the AI reported a number directly, and a category returned with no confidence value at all was treated as confident and was not caught by this check. The core categories that apply to the brand's archetype are all required, so if any of them falls below the floor we do not score the brand at all: no letter is computed, and the run is held for a person to look at, under a hold no editor can simply approve. The withheld run and the categories that caused it are recorded in the assessment audit log. Two things are deliberately different from this: a category the archetype marks not applicable is excluded by design, its weight simply absent from that archetype's table, so nothing is redistributed; and security comes from an independent scan rather than the policy text, so its absence does not stop a score, its weight being dropped and the rest renormalised instead.

Two-pass AI verification: High-stakes claims, GDPR/CCPA policy-text signals and high-severity concerns, are sent through a second AI fact-check call against the source policy text. The second pass returns AGREE or DISAGREE. A genuine DISAGREE that survives the cross-provider tiebreaker, where that check is enabled, demotes the field and marks it "unverified" on the public scorecard. When the second pass simply could not run, whether from a temporary service outage, a missing key, or a source too short to check, the field is not demoted: the severity we assigned stands, and our internal record notes that the check could not run rather than that the claim failed. On the public scorecard both cases carry the same "unverified" marker, so that label never means, on its own, that a claim was contradicted. The claim and the verdict, with the reason for it, are kept on the stored assessment record; where a disagreement goes to the cross-provider tiebreaker, the verdicts are additionally written to the assessment audit log.

Quote grounding: Every quotation and every piece of concern evidence we publish is matched against the source policy or terms. Most appear there word for word. Where the wording differs slightly, we require the quotation's distinctive words to sit together within one short passage of the document rather than being scattered across it. Quotations we cannot match at all, or that turn out to be a geo-block or error interstitial rather than policy text, are discarded before anything is shown.

How the published wording is framed: The text we publish for each category is written by an AI model, and the instructions it is given tell it how to word what it writes: to describe what the documents say and attribute each point to the document it comes from, to frame an absent protection as something the reviewed text does not appear to address rather than as something the company does not do, not to state legal conclusions about the company, and not to apply the rubric's own judging words, such as unfair or harsh, to the company or its conduct. Those are instructions to a model, not a guarantee about every sentence it returns. What is checked afterwards is separate and is described above: every quotation and every piece of concern evidence we publish is matched against the source document, and a category that comes back with no written explanation at all is held rather than published.

Publication hold: An assessment is held back from publication and routed to human review, rather than shown automatically, when its own fact-checking flags it: when a majority of the checked claims genuinely failed verification, when the summary was contradicted and a high-severity concern was demoted, or when several quotations could not be grounded. While an assessment is held, the brand's page says a review is in progress and publishes no grade, no score and no category detail. A brand with no published grade should not be read as scoring badly: an assessment is most often held because our own retrieval, analysis or verification did not complete, not because of anything in the brand's policies.

Overall confidence: Each assessment carries an overall confidence rating drawn from the depth of the policy text, the completeness of the AI analysis, the security scan, breach data, and the agreement of the independent second pass. A "high" confidence rating requires a successful security scan in addition to strong policy and analysis coverage; brands whose security surface could not be scanned sit at a lower confidence even when everything else is strong. An assessment whose overall confidence rating falls below our publication threshold, currently 50 out of 100, is held for an editor to review rather than published. That threshold is a separate control from the per-category confidence floor above, which is a different measure on a different scale.

Cross-provider tiebreaker: When the first two AI passes disagree on a high-stakes claim (compliance label, severity), a third pass from a different provider casts a tie-breaking vote. The two-of-three majority verdict decides the public field. All three verdicts, including the disagreement reason from each provider, are kept in the audit log. Cross-provider checks are hard-capped at a small fixed number of calls per assessment so the cost is bounded.

Modifiers and adjustments

• Policy Quality Modifier (-5 to +5): Adjusts the weighted score based on Terms of Service fairness and overall transparency. Where we cannot find a brand's terms of service, the Terms of Service part of this adjustment is left out rather than estimated from the privacy policy.
• Breach Penalty (0 to -20): 3 points per breach we have confirmed is attributable to the brand, plus a severity weighting; capped at 20 points. Matches we have never confirmed contribute nothing.
• Coverage Bonus (0 to +5): Awarded for publishing supplementary policies (cookie policy, GDPR page, security policy, etc.), capped at 5 points. From algorithm 2026.11, a supplementary document counts toward this bonus only when we actually retrieved its content and that content is substantive. A document whose fetch failed, was blocked (for example by an age gate or bot check), or came back empty or near-empty earns nothing.

Breach history

We check each brand against the Have I Been Pwned breach database. A database match is not by itself evidence that a breach belongs to the brand: names and words collide, and a match on a company name alone can point at an unrelated organisation. Only an attribution we have confirmed lowers a score or appears on the page. Withdrawing a confirmation takes it off the page straight away, but it does not change a score that was produced under an earlier version of the algorithm: we never recompute a stored score against a newer one, so the published letter can keep a penalty from a withdrawn attribution until that brand is next assessed. A breach record naming the same registrable domain we assessed is confirmed automatically; a match on the company name alone is never enough by itself and stays out until a person confirms it. Unconfirmed matches are held back entirely: they are not scored, not counted, and not shown. Where we cannot establish that the brand and the domain we assessed are the same organisation, no breach detail is published for that brand at all.

GDPR and CCPA rows

The scorecard shows what the brand's published policy appears to say about GDPR and CCPA. These rows do not feed the score. They are a reading of the policy text, produced by an AI model and, where possible, checked against a quoted passage from the document itself; they are not a legal determination of whether a company complies with either law, which is not something we are in a position to decide. A row marked as unverified means the label is not backed by a quoted passage that passed our checks. That can happen for more than one reason: we could not match a supporting passage in the document, our independent re-check could not run, or the re-check did not confirm the label. It does not mean the brand is non-compliant.

Letter grades

A ≥ 85 · B ≥ 75 · C ≥ 55 · D ≥ 40 · E < 40

These are the bands used by algorithm version 2026.14, which is the version this page describes. A score keeps the bands it was assessed under: if the bands change, past assessments are not re-lettered.

The bands have not changed since scoring began, so there is no history to show. If they ever do, every past version will be listed here alongside the assessments it applied to.

What a letter can and cannot tell you apart

A score is a weighted average of category ratings that are judgements, not measurements. Two assessors could reasonably differ by a few points on the same evidence, so a difference of a point or two between two brands is not a real difference and should not be read as one. What the letter is meant to separate is a brand near the top of the scale from one near the bottom, not one brand from its neighbour. Because of that, any score landing within 2 points of a band threshold is held for a person to review before it publishes, rather than going live on the letter the calculation produced.

The checks that can stop a grade publishing

A score is computed automatically, and when every check below passes, so is publication: nobody re-reads a clean run before it goes live. An assessment is withheld from the site whenever any of the checks below does not pass. It stays withheld until either a person resolves the reason it was held, or a later scheduled re-assessment of the brand runs and passes every check, in which case the new result replaces the held one and publishes. The software never publishes a held result on its own; only a named person can, through the editorial holds below. The list below is generated from the software rather than written out by hand. It is not the whole of what stops a grade: publication is refused again at the moment of publishing, if no score was computed or if one of these conditions has changed since the assessment ran.

Holds that need the assessment re-run or repaired

Some of these mean the brand's evidence is missing, unusable, or cannot be attributed to it. Others mean our own run failed: it was interrupted, produced no score, or could not persist the source corpus it assessed. No editor can approve past any of them, and each has its own remedy: re-running the assessment, supplying the source text by hand, correcting the web address we use for the brand, confirming that the policy we read belongs to the brand, choosing the service archetype, or writing to the company and dealing with any reply.

Document to confirm: we have a score, and an editor has not yet confirmed that the document it was computed from is the company's own.

No score to publish · Score not attributable to its run · Snapshot missing · Fetch blocked · Policy unconfirmed · Identity unconfirmed · Archived copy on an unverified domain · Interrupted run · Re-run required · Incomplete run · Archetype unconfirmed · Notice pending · Manual text · Incomplete data · Explanation missing · Document to confirm

Holds that need an editorial judgement

These mean the assessment is complete but something about it warrants a person deciding whether to publish. An editor may publish it, and must write down why. That reason is kept permanently against their name.

Second reviewer needed: the grade is one of those we require two named editors to agree before publishing, and only one has so far.

Low confidence · Fact-check · Grade boundary · Source truncated · Grade changed · Second reviewer needed

Two reviewers for the lowest grade

A grade of E is the strongest adverse assessment we publish about a company, and it requires two different named people to approve it, each giving their own written reason. One person may publish it alone where a second reviewer is not available to them. We do not currently block that route on our own availability check: the software independently checks whether another eligible reviewer existed at that moment, writes what it found, yes, no, or that this could not be established, into the permanent record beside the decision, and lists every single-reviewer publication for later review rather than letting one pass silently.

We tell a company before we publish the lowest grade

Before a grade of E is published, we write to the company, tell them the grade, tell them which document we assessed and when we retrieved it, and give them 10 business days to correct anything we have got wrong. This is a rule that fires on the grade, not a decision we make case by case. If they reply with evidence, publication is held until an editor has dealt with that evidence and recorded what they did about it. We correct on evidence and require nothing in return, and we do not make, withhold or alter an assessment in connection with any commercial arrangement.

Data sources

Anthropic Claude

Reads the privacy policy and terms of service; produces per-category scores 1-5 with confidence values; runs the second-pass verification of compliance and severity claims. The policy documents are fetched afresh for a full assessment, subject to a short content cache of up to 7 days; any change in the retrieved text triggers a fresh analysis. Where the text is unchanged, cached analysis results may be reused for up to 30 days, and verification verdicts for up to 7 days.

OpenAI

Cross-provider tiebreaker. Only invoked when the primary 1st and 2nd verification passes disagree on a high-stakes claim. Returns AGREE / DISAGREE; the two-of-three majority decides. Hard-capped at a small fixed number of calls per assessment. The specific OpenAI model used for each assessment is recorded in the per-assessment audit log; we refresh model selections periodically as model capabilities improve.

Perplexity

Discovers the canonical URLs of the brand's privacy policy, terms of service, and supplementary policy pages. Used only for URL discovery, not scoring.

Mozilla Observatory

Scans the brand's domain for security headers, cookie flags, and related web-security tests. Free public service. Drives the Security category score; TLS and certificate checks are made by our own direct scan of the domain.

Have I Been Pwned (HIBP)

Checks the brand against the public breach database. Drives the breach penalty modifier. Cache refreshed weekly.

Policy discovery and scraping

To find a brand's published policies we use, in order: any URLs an editor has supplied; links found on the brand's own homepage and in the sitemap files its robots.txt advertises; a set of common policy paths; and, because legal documents usually sit side by side, the addresses next to a policy we have already found. If a privacy policy or terms of service is still missing after that, we ask an external search service for candidate addresses and check anything it returns the same way we check candidates from any other source. Requests to a brand's site carry a user agent that names this project and links back to it, and our policy fetching is paced: successive checks against the same host normally wait at least a second apart.

We fetch published policy pages only. The fetch surface is the brand's own domain and its subdomains, plus a short allowlist of well-known consent-management and policy-hosting providers that some brands use to publish their notices (for example OneTrust, Cookiebot, Termly, iubenda, TrustArc, Osano, Usercentrics and Didomi), and the Internet Archive for the fallback described below. We read robots.txt only to discover the sitemap files it advertises; we do not evaluate its crawl-exclusion (Disallow) rules. Every request to any of these hosts carries the same identifying user agent. Finding a policy can mean checking many candidate addresses; the number of checks in an assessment is limited, the checking is spaced out in the same way, and only pages that prove to be policy documents are kept.

A page that loads successfully is not assumed to be a policy. Many sites answer any address with their homepage or an error page, and a shop's footer alone can mention collecting email addresses, cookies and third parties. So before accepting a page we also fetch the site's homepage and the page it returns for an address that cannot exist, set aside the text the candidate shares with them (menus, footers, newsletter boxes), and reject the page if what is left does not meet the same minimum we apply to any policy text. Those two comparison requests carry the same user agent and pacing as every other request. The same document is never used as both the privacy policy and the terms of service, and narrower notices (for example a health-data, job-applicant or California notice) are not treated as the main privacy policy.

Some brands place their policies behind an age-verification wall. Because these are adult-industry services whose published legal documents we are reviewing for accountability, we take a limited set of steps to reach the public policy behind such a wall. When a page we request as a possible privacy policy or terms of service comes back as an age check instead of the document, we request the same address once more, this time sending a fixed set of cookies with names such as over18 and age_verified. These cookies say that the visitor is an adult who has already passed the age check, and two of them give a date of birth about 25 years before the day of the request. That date is calculated by our software and is not taken from any real person. The repeat request is otherwise the same as the first, including the user agent, which names STG-Privacy-Scorer and links to sextechguide.com. Where that repeat request is what produced the document, we send the same cookies when we fetch the site's homepage and its not-found page, described above, so that the two pages we compare the document with are read the way it was. The cookies are sent only to addresses under the same domain name as the page we requested, which is the page the cookies were first sent to: they go with a redirect from www.example.com to verify.example.com, but are not sent to any other domain, including the domain a document is published on when that is not the one we asked. A service that publishes policies for many businesses is treated more narrowly than a company's own site: there the cookies stay on the exact name we read the document from, so cookies sent while reading a document at business-a.example-service.com are not sent to business-b.example-service.com. Where such a service gives two businesses that same name and separates them only by what follows it in the address, our rule works on the name and cannot tell those two apart. A comparison page that falls outside all of this is fetched without them, which is what happens when we ask a policy-hosting service for a document directly and then compare it with the company's own homepage. We do not send them when fetching the supplementary documents listed above, or when reading copies held by the Internet Archive.

If the wall is still there, we may follow an "enter" or "I am 18+" link on it, trying up to 3 such links one at a time and stopping at the first that lets us through. Those requests carry only cookies the website itself has set, not the ones described above. For each document we try to read we make no more than 4 of these attempts in total, and the same limit applies separately to the search for candidate addresses. An attempt is either the repeat request with the cookies described above, which is one request, or one "enter" link followed together with the fresh reading of the policy page after it, which is two. So the most the whole of this adds for one document is 7 requests. We never submit forms on these websites, sign in to them or send them account credentials. Whichever way we get past the wall, we only score a fresh copy of the policy page we asked for, never the wall itself or the page an "enter" link leads to. The scorecard does not say when a policy could be read only after sending these cookies.

Before a grade is published, an editor confirms which document we assessed. Our automated steps find the candidate pages, read them and put one forward; they do not decide. The editor is shown the address the text was served from, the page title and main heading, the date the document gives for itself where it states one, and the opening of the text with the site's own navigation and footer set aside, and either confirms that this is the company's own privacy policy, and its terms of service where one was read, or gives the correct address. Confirmed addresses are reused for later assessments of the same brand, so in the ordinary case this happens once for each document rather than on every run. We ask again when the address changes, when the text at a confirmed address differs substantially from the text that was confirmed, when the company name we recorded in the text is no longer there, and when the document was read in a way the confirmation on record does not cover, for example where the confirmed copy came from the live site and this one came from an archive. Grades published before we began asking this question are a special case: their records do not say how the document was read, so the first confirmation of one of them covers nothing about how it was read and the next assessment asks once more. Where an assessment carries a grade but no longer holds the text it was computed from, no confirmation can settle it, and the remedy is a corrected address or a fresh assessment. While a document is waiting to be confirmed, no grade for that brand is published.

Confirming a document tells us which text we read. It does not by itself tell us that a company's own web address is the one we think it is. Where the confirmed document is published somewhere other than the company's own website, for example on a service that hosts policies for many businesses or on a parent company's domain, we record that separately and ask for it separately, and we do not attribute any reported data breach to the company until that second question has been answered.

When automated retrieval cannot reach a policy at all, we fall back in two ways. First, we look for the most recent working copy of the page in the Internet Archive (Wayback Machine) and, where a suitable snapshot exists, assess that archived copy. Second, an editor may paste the policy text they have obtained by hand. In both cases the source and its date are recorded, and where an assessment was produced from an archived copy the scorecard says so. For pasted text the source recorded is the one the editor gives us: our software does not check where that text was copied from.

An assessment our software made from an archived copy is held for an editor instead of being published if the same assessment finds that the brand's own domain does not resolve, resolves only to a private or unroutable address, shows a parking or for-sale page, or has a homepage that ends on a different domain. It is held in the same way if that check could not be made at all. An archived policy may not describe what the brand publishes now. The hold records what the check found and the date of the archived copy. If the next assessment of the same web address again relies on an archived copy and cannot read the brand's homepage at all, the hold stays in place. An assessment is not held by this check for a document whose text an editor pasted by hand, because a person has already read that text and chosen it. Where one document was pasted and the other still came from an archived copy, the assessment is held, and the hold names the document that came from the archive. We do not remove a brand or mark it as closed because of this check.

Framework and policy changelog

Changes to how we decide what to publish, as opposed to how a score is computed. These do not change any stored score. The algorithm changelog below covers changes that do.

4 October 2026

The lists shown beside the GDPR and CCPA signals, of what a policy text does and does not describe, are now checked before they are published. An item is listed as described only where we hold a word-for-word excerpt of the text that describes it and a second check has read that excerpt; an excerpt that says the item is not offered does not count. We no longer list items as not found under a signal that appears addressed, because a document can explain why an item does not apply to it and a bare list cannot say so. Assessments made before this change keep the lists they were published with until the brand is next assessed.

24 September 2026

An editor now confirms which document an assessment was computed from before any grade for that brand is published. Our automated steps find the candidate pages, read them and put one forward; a named person decides. The editor is shown the address the text was served from, how it was reached, where it is published, the page title and main heading, the date the document gives for itself where it states one, the size of the text once the navigation and footer are set aside, the opening of that text, and the doubts our automatic checks recorded. A confirmed address is reused for later assessments of the same brand, and we ask again when the address changes, when the text at it differs substantially from the text that was confirmed, when the company name we recorded in that text is no longer there, and when the document was read in a way the confirmation on record does not cover. There is no way to confirm a document in bulk and no command that confirms one, because confirming means somebody looked at the page. No stored score changes.

24 September 2026

A page a site put forward as its privacy policy that we could not attribute to the brand is now held for an editor with the page named, instead of the assessment ending as a report that no privacy policy was found. That report is now used only where no such page was seen, which is what makes the sentence true of the brand. No stored score changes.

24 September 2026

A scored category that comes back with no written explanation at all is now held for an editor rather than published. A rating with nothing said about it cannot be read, checked or disputed by the company it is about. Detailed scorecards with expandable category details can now show the written explanation for Terms of Service fairness. The compact scorecard on brand pages does not include it. This explanation is available on assessments produced under algorithm 2026.13 or later: that is the first version whose instructions to the model told it to describe what the documents say rather than to characterise the company. Earlier assessments show the Terms of Service rating with no explanation beside it, as they always have, and no stored score changes.

24 September 2026

Corrected two statements on this page about the supplementary documents we read. This page said we read each of them for its own scoring category alone. That was wrong: which categories a document is scored for is decided that way, but every supplementary document we accept also goes into the material our summary is written from and the material a published claim is checked against. The list of documents we look for also left out the accessibility statement, which we do read and do score. Nothing about how we fetch or score anything has changed, and no stored score is affected. We have also added a description of how we ask the model to word what it writes, and it says plainly that those are instructions rather than a guarantee about every sentence.

24 September 2026

Age-check cookies are now kept to the domain of the page we asked for. A comparison page outside that domain is fetched without them, and on a service that publishes policies for many businesses they are kept to the exact name the document was read from. The description above also now says how many requests an attempt is, because counting attempts in the unit the page itself gave came to more than the limit it stated. No stored score is affected.

24 September 2026

An assessment our software made from an archived copy of a brand's policy is now held for an editor instead of being published when the same assessment finds that the brand's own domain does not resolve, resolves only to a private or unroutable address, shows a parking or for-sale page, or has a homepage that ends on a different domain, or when that check could not be made at all. The hold records what the check found and the date of the archived copy. The brand is not removed or marked as closed because of this, and no stored score changes.

24 September 2026

Rewrote the description of how we reach a policy behind an age-verification wall so that it matches what our software does. It now says which cookies we send, that two of them give a date of birth, when they are sent and where to, and how many attempts we make. The earlier wording described one cookie and one "enter" link, and mentioned a setting for submitting forms that our software does not have. Only the description has changed: nothing about how pages are fetched or scored is different, and no stored score is affected.

22 August 2026

Published this section, the breach-history and GDPR/CCPA notes above, the human-review section, and the statement of what a grade is. The grade bands and the 1-to-5 scale on this page are now rendered from the code that applies them rather than written out separately, so the page cannot describe thresholds the software does not use.

22 August 2026

A grade of E now requires two different named reviewers, and we write to the company before publishing one, giving them ten business days to correct us. A reply containing evidence stops publication until an editor has dealt with it. Where a second reviewer is genuinely unavailable, one person may publish alone, but that is recorded as a single-reviewer decision.

21 August 2026

Publishing a held grade now requires a written reason, recorded permanently against the name of the person who published it. An assessment that fails several publication checks now records all of them rather than only the first, and every one of them has to be resolved before it can publish.

21 August 2026

Assessments now record which rubric produced them, and a grade is withheld where the brand has no confirmed service archetype. Where we cannot establish that the policy we read belongs to the brand, the whole grade is withheld rather than just the breach detail.

Algorithm version changelog

Changes to how a score is computed. An assessment keeps the version it was produced under and is not recomputed when a newer version ships.

2026.14 (current)

The AI no longer reports its confidence in a category score as a number. It chooses one of four descriptions of how far the documents support the score: settled, mostly settled, inferred or unsupported. We convert that choice to a number ourselves, using a fixed table, and compare it with the same floor as before. The previous instruction asked for a number in ranges that met at 0.55, and a large share of answers came back at exactly that value, just under the floor, for brands whose documents differed greatly. That pattern followed the wording of our instruction rather than the documents, so we replaced the instruction. The floor and the grade bands are unchanged. An answer whose confidence cannot be read is now treated as not confident; before, a missing value was treated as confident. Existing assessments keep the version they were produced under and are not recomputed.

2026.13

Scores are now computed only from documents we actually found. A privacy grade requires the brand's privacy policy; an assessment that finds only a terms of service produces no grade. Where no terms of service is found, the Terms of Service fairness score is left out, so it no longer adjusts the overall score; previously it could be estimated from the privacy policy. Policy discovery was also rebuilt: links are recognised by their address and their label separately, so a correct link labelled for example "Privacy and Security" is no longer discarded; pages next to a found policy are checked; pages found automatically are compared with the site's homepage and its not-found page to stop either being mistaken for a policy; one document can no longer count as both the privacy policy and the terms of service; text is recovered from pages whose markup previously caused most of the document to be lost; and four further supplementary document types are read where a brand publishes them (subprocessor and payment-processor lists, data-deletion routes, companion-app privacy policies, and content moderation policies), each scored for the categories it informs and no others, which can also change the coverage bonus. Supplementary documents now pass the same check as the main documents, so a page that is really the site's homepage or error page, or the privacy policy again under another name, no longer counts towards the coverage bonus. Grade bands are unchanged. Existing assessments keep the version they were produced under and are not recomputed; brands are brought onto this version by a fresh assessment.

2026.12

Content privacy rubric rewritten. The rubric now asks the AI to judge each checkpoint from what the published documents state or omit, and says plainly that where a subject applies and the documents do not address it, that silence is itself a finding rather than a gap in our evidence. The confidence instruction was rewritten the same way and applies to every category, not only content privacy, so a score resting on documented silence is now reported as well supported rather than as uncertain. One checkpoint was dropped from each version of the rubric, taking both from five to four. Grade bands are unchanged. Existing assessments keep the version they were produced under and are not recomputed.

2026.11

Coverage bonus now counts only supplementary policy documents whose content was actually retrieved and substantive; failed, blocked, or empty fetches earn nothing. Every assessment also now persists an immutable evidence snapshot (source URLs, retrieval method, fetch times) before it can publish.

2026.10

Cross-provider verification reliability fix. When the third, cross-provider tie-break check that resolves a disagreement between the first two AI passes cannot run, the claim now defers to the two-pass verdict (treated as unverified) instead of defaulting to verified, so a transient verification failure can no longer silently keep a claim the second-pass fact-check rejected. Existing archetypes, weights and stored scores are unchanged.

2026.09

Added the Support / Advocacy archetype for non-commercial organisations: charities, advocacy campaigns, professional and accreditation bodies, universities, and support networks or helplines, where a user's sensitive disclosure or support-seeking is the core asset rather than an account and ad targeting. Its weight table leads with content privacy (24) and data sharing (24), reflecting that protecting the disclosure and not onward-sharing it to funders, partners, researchers or authorities is the central threat. AI rubric refinements cover support-seeker anonymity and disclosure confidentiality, retention and deletion of support/disclosure records, and onward sharing with funders, partners, researchers and law enforcement. Existing archetypes and their stored scores are unchanged.

2026.08

Breach attribution hardened. A known data breach now affects a brand's score, and is shown publicly, only when it is matched to the brand by its registrable domain or has been editorially confirmed; name-only matches are treated as unconfirmed and excluded from the breach penalty (and from the public breach history) until reviewed. The breach severity penalty is computed from the confirmed breaches only. This prevents a brand whose name merely appears within an unrelated company's breach record from being penalised or labelled. Other archetypes, weights and category scoring are unchanged.

2026.07

Added the AI Companion archetype for conversational AI / virtual-partner / intimacy-chatbot brands, with a weight table led by content privacy and retention, and AI rubric refinements covering conversation-log handling and training-data reuse. Existing archetypes and their scores are unchanged.

2026.06

Per-archetype weight tables. Evidence-grounded policy-text signals replace legal-sounding compliance labels. Two-pass AI verification of policy signals and severity claims treats verifier failures as unverified. Source snapshots preserve the text used for each assessment.

2026.04

Per-archetype weight tables. Two-pass AI verification of compliance and severity claims. Confidence floor (0.6) per AI category. Per-archetype rubric refinements for dating platforms and sex-tech / health.

2026.03

Service-archetype framework introduced; N/A categories excluded from scoring; AI archetype classifier added; methodology page launched.

pre-2026.03

Shared fixed weight set across all brand types. No archetype awareness, no two-pass verification, no confidence floor. Assessments produced under this version retain their original score and are not retroactively recomputed under newer algorithm versions.

Limitations and disclaimers

What a grade is

A grade is our editorial opinion of how a company treats personal data, formed by reading the documents that company publishes about itself and scoring them against the rubric on this page. It is an assessment of published policy and observable security configuration. It is not an audit, not a certification, and not a finding of fact about anything the company does internally, which we cannot see. A high grade means the published policies read well against our criteria; it is not a guarantee of good behaviour. A low grade means those policies read poorly against our criteria; it is not an allegation of wrongdoing.

For information only. Privacy scores are published as editorial information to help readers compare brands. They are not personal advice, a recommendation to use or avoid any service, a warranty of any brand's privacy practices, or a guarantee against future incidents. A high score does not mean a brand is safe; a low score does not mean a brand is unsafe. Decisions about which services to use are the reader's own, and readers should always review a brand's current privacy policy and terms of service before signing up.

Not legal or compliance advice. Privacy scores are editorial assessments of publicly available information. They are not legal advice, regulatory determinations, certifications, or audit results. GDPR and CCPA fields are policy-text signals only: they describe whether the published policy appears to address specific topics, not the brand's actual regulatory standing.

Public information only. Scores reflect what a brand publishes. Private practices, internal contracts, undisclosed data-handling, and operational behaviour not documented in the privacy policy or other public materials are not assessable and are not included in the score. Opacity itself is captured in the transparency component of the score.

Scores age. Each assessment is timestamped on the scorecard. Brands change their policies, security posture, and infrastructure; an assessment reflects what was true at the time it was generated. Refreshes are scheduled on a rolling basis but are not instantaneous, and a score may be out of date by the time you read it.

Commercial relationships

SEXTECHGUIDE may earn affiliate commissions from some of the brands it assesses. Privacy scores are produced by the automated methodology described on this page and are not influenced by whether a brand is a commercial partner: a commercial relationship does not raise a brand's score, and the absence of one does not lower it. Where a brand is linked commercially, that relationship is disclosed at the point the link appears.

Disputes and corrections

If you are a brand and believe an assessment is inaccurate or out of date, contact us via the "Request a correction" link in the scorecard footer, or via our published contact page. We respond to correction requests within 21 business days and will either: republish the scorecard with the change applied, mark the assessment as under review pending re-scoring, or explain in writing why the score stands. We log every assessment with timestamps and source attribution and can review specific category scores or the archetype classification on request.