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 is stamped with the algorithm version that produced it so changes to this framework do not retroactively alter past assessments.

Current algorithm version: 2026.11

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.
2. We scrape the brand's privacy policy and terms of service, plus supplementary policies (cookie policy, GDPR page, security page) when available.
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. Disagreements or verifier failures downgrade the field to "unverified".
5. Categories with reported confidence below 0.6 are excluded from scoring rather than letting a low-confidence guess contribute.
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 remaining category scores are weighted by the archetype's weight table, modified by transparency / terms-of-service quality, and adjusted for breach history. The result is a 0 to 100 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 Mozilla Observatory security-header scan plus direct TLS / cookie checks. Not derived from the privacy policy.

Content Privacy

How user-generated content (photos, messages, video) is protected. Not applicable to brands without UGC.

Confidence floor and verification

Per-category confidence floor: When the AI reports its own confidence in a category score below 0.6, that category is excluded from the weighted average. We would rather refuse to score a category than guess. Excluded categories are recorded in the assessment audit log for review.

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 demotes the field and marks it "unverified" on the public scorecard. When the second pass simply could not run — a temporary service outage, a missing key, or a source too short to check — the field is marked "could not verify" rather than demoted, so a transient failure never silently downgrades a brand. The original claim and the verdict are preserved in the audit log for review.

Quote grounding: Every quotation and every piece of concern evidence we publish must appear as a contiguous passage in the source policy or terms — not merely as words scattered across the document. Quotations that cannot be matched to a real passage, or that turn out to be a geo-block / error interstitial rather than policy text, are discarded before anything is shown.

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. Held assessments are hidden from visitors until an editor confirms them.

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. Assessments below the confidence floor are held for review rather than published.

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.
• Breach Penalty (0 to -20): 3 points per known breach with severity weighting; capped at 20 points.
• 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.

Letter grades

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

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. Refreshed every full assessment.

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, TLS configuration, cookies, and similar. Free public service. Drives the Security category score.

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 read a brand's published policies we use, in order: any URLs an editor has supplied; links found on the brand's own homepage and the sitemap files listed in its robots.txt; and finally a small set of common policy paths. Every request is made from a self-identifying user agent and is rate-limited to no more than one request per second per host.

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. We identify ourselves in every request and fetch only a small number of published policy pages, within the rate limit above.

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, transparent set of steps to reach the public policy behind such a wall: we may present a standard age-confirmation cookie (asserting the reviewer is over 18), and, if a wall still blocks the page, we may follow a single "enter" or "I am 18+" link on the wall. This traversal is GET-only; submitting forms by POST is disabled by default, and we never sign in or submit account credentials. We only ever score a re-fetch of the brand's own policy page reached this way — never the wall or the landing page itself.

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 obtained by hand from the brand's own site. In both cases the source and its date are recorded, and where an assessment was produced from an archived or an editorially obtained copy the scorecard says so.

Algorithm version changelog

2026.11 — current

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.04

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

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.