Subscore

SecurityTesting methodology

Security measures how well an AI girlfriend app protects account access, explains payment information, and handles past security problems.

We check the company’s documented encryption, try to enable two-factor authentication, confirm whether the billing name is shown before payment, and search for confirmed security incidents from the previous five years.

The live database does not contain separate active tests for Account Security or Billing Privacy. Those names appear in older methodology files but are not part of the current scoring system.

4 evidence groups
4 scored tests

Security is organized into 4 evidence groups. Each group contains one scored test: Encryption, Two-Factor Authentication, Billing Descriptor, and Security Incidents.

How the Security score is calculated

Every test receives a score from 0 to 10.

We multiply each score by how much the test counts. We then add the points together to calculate the final Security score.

Security makes up 28% of the Privacy score.

Billing Descriptor and Security Incidents have the largest effect on the score. Together, they make up 86% of Security. Security makes up 28% of the Privacy score.

7%Encryption
7%Two-Factor Authentication
43%Billing Descriptor
43%Security Incidents

Weighted evidence groups (combined 100%)Security score28% of Privacy score

View exact calculation

Each test gets a score from 0 to 10. We multiply that score by how much the test counts. We then add all the points together.

Security makes up 28% of the Privacy score. Privacy makes up 10% of the overall performance score.

Scored tests and weights

Scored test	How much it counts	See scoring
Encryption	7.00%	View
Two-Factor Authentication	7.00%	View
Billing Descriptor	43.00%	View
Security Incidents	43.00%	View
Total	100%

How the score is calculated

Each test gets a score from 0–10
Test score × how much it counts
Example: 5 × 7.00% = 0.35 points
We do this for every test
We add all the points together
Final Security score
Counts for 28% of Privacy

Example calculation

We multiply each test score by how much it counts. We then add all the points together.

Scored test	Test score	How much it counts	Calculation	Points added
Encryption	5.00	7.00%	5.00 × 7.00%	0.35
Two-Factor Authentication	0.00	7.00%	0.00 × 7.00%	0.00
Billing Descriptor	10.00	43.00%	10.00 × 43.00%	4.30
Security Incidents	10.00	43.00%	10.00 × 43.00%	4.30
Final Security score	—	100%	Add all points	8.95/10

Standard result scoring

Yes, Limited, and No

Encryption, Two-Factor Authentication, and Billing Descriptor use Yes = 10/10, Limited = 5/10, and No = 0/10. Security Incidents uses a separate count-based scoring table.

Unknown

Privacy Unknown results are excluded from the score. Unknown does not mean that the app is secure. It means we could not find enough reliable information to give a confirmed result.

Not Applicable

If a test genuinely does not apply, we remove it and spread its weight across the remaining scored tests. A test that has not been completed should not be entered as zero confirmed incidents or as a positive security result.

Manual adjustment

In rare cases, we may adjust a score when the calculated result is clearly misleading. We always record the reason.

Why Security matters

AI girlfriend accounts can contain highly private information.

This may include intimate conversations, uploaded photos, generated adult images and videos, saved memories, personal preferences, and payment information.

Someone who gains access to the account may be able to see much more than they could through a normal entertainment app.

Encryption helps protect information while it is being sent or stored. Two-factor authentication adds another check when someone tries to sign in.

Billing information also matters. Users should know what name may appear on their bank or card statement before they pay.

Past security incidents provide additional context. A confirmed breach does not automatically mean the service is unsafe today, but users should know whether incidents happened and how often.

A strong Security result means the app documents useful protections, gives users an additional login-security option, explains the billing descriptor, and has few or no confirmed recent security incidents.

What good Security looks like

A high Security score means important protections are clearly documented, two-factor authentication works, the billing name is shown before purchase, and no confirmed security incidents were found during the five-year review period. A lower score means protections are missing or unclear, users cannot secure their accounts with a second login step, the statement name is hidden until after payment, or the company has several confirmed incidents.

Main benchmarks

GoodLimitedWeak

Encryption

YesLimitedNo

Two-factor authentication

YesLimitedNo

Security incidents

012+

Minimum useful standard

Encryption: Yes
Two-Factor Authentication: Yes
Billing Descriptor: Yes
Security Incidents: 0

Common red flags

The company makes general security claims without explaining the protections used
The privacy policy does not mention encryption
Two-factor authentication is unavailable
The billing descriptor is hidden until after purchase
Several confirmed breaches or leaks occurred recently
The company does not explain what happened after a known incident
Marketing uses “secure” or “private” without supporting information

How we test Security

We use a paid test account and complete one Security and Billing session.

First, we review official security, privacy, and help pages for statements about encryption in transit, encryption at rest, and end-to-end encryption. We do not assume that any type of encryption exists when the company does not clearly state it.

We then open the test account’s security settings and try to enable two-factor authentication.

Before making a payment, we check the checkout page and payment help pages to see whether the expected billing name is shown.

Finally, we search for confirmed breaches, leaks, and other security incidents from the previous five years.

We only count an incident when it is supported by at least one of these sources: an official company statement, a regulator, a court filing, or a reliable security report.

The active guided-testing session contains four evidence tests: Encryption, Two-Factor Authentication, Billing Descriptor, and Security Incidents.

Limitations and edge cases

We cannot directly inspect the company’s servers, source code, or internal security systems.

Our Encryption result is based on what the company clearly documents. A company may use protections it does not publicly explain, but we cannot award points based on assumptions.

The opposite is also possible. A company can publish strong security claims without giving independent proof that every system follows them.

Two-factor authentication may work differently depending on the sign-in method. For example, it may be available for email accounts but not accounts created through Google or Apple.

Billing Descriptor only checks whether the expected billing name is shown before payment. It does not automatically mean the descriptor is discreet.

A company could clearly show a revealing brand name and still pass the Billing Descriptor test because the user was warned before paying. Payment discretion is recorded separately in the Pricing system.

Security Incidents only includes confirmed incidents found during the previous five years. Finding zero confirmed incidents does not prove that no incident has ever happened.

Our result reflects the documentation, account settings, billing information, and confirmed reports available on the recorded test date.

Evidence groups

Security has 4 evidence groups made up of 4 scored tests.

Encryption measures which types of data protection the company clearly says it uses.

We check encryption in transit, encryption at rest, and end-to-end encryption.

Encryption

7%of Encryption (7% total)

Which types of data protection the company clearly says it uses.

How we test

We search official sources, including the privacy policy, security pages, help center, terms of service, and official company statements. We record how many of the three encryption types the company clearly confirms. We do not use technical guesses based only on the website using HTTPS.

What counts

A direct statement that data is encrypted in transit
A direct statement that stored data is encrypted
A clear claim that chats or messages use end-to-end encryption
Official documentation that explains where the protection applies
Current information from the company

What does not count

General claims such as your data is secure
A padlock icon in the browser
HTTPS alone as proof of encryption at rest
Encryption claims from an unofficial review
Assuming end-to-end encryption because messages are private
A statement that does not explain which data it covers

Result shown

Limited — encryption in transit and at rest were clearly stated, but no end-to-end encryption claim was found

Protections confirmed: 2 of 3

Scoring

We use the result categories below.

Result	Score
Yes — strong encryption coverage is clearly documented	10/10
Limited — only some protections are clearly documented	5/10
No — the company does not document the tested protections	0/10
Unknown — available information is not clear enough	Excluded

In this example, Encryption scores 5/10.

Evidence group 2 of 4

Two-Factor Authentication measures whether users can protect their account with a second login step.

A password can be stolen or reused. Two-factor authentication makes it harder for someone to enter the account with only the password.

Two-Factor Authentication

7%of Two-Factor Authentication (7% total)

Whether users can protect their account with a second login step.

How we test

We open the paid test account’s security settings and try to enable two-factor authentication. We record whether the feature exists, whether setup works, which method is supported, and whether important restrictions apply. Supported methods may include authentication app, email code, SMS code, security key, or passkey.

What counts

A working authentication-app setup
A working SMS or email verification method
A security key or passkey used as an additional check
Recovery codes provided during setup
A second login step available to regular users

What does not count

Email verification used only when creating the account
A password-reset email
Signing in with Google or Apple by itself
A CAPTCHA
A feature shown in help pages but missing from the account
A code that cannot be enabled or used

Result shown

Yes — two-factor authentication worked through an authentication app

Recovery codes were provided

Scoring

We use the result categories below.

Result	Score
Yes — a useful second login step works	10/10
Limited — the feature works with important restrictions	5/10
No — two-factor authentication is unavailable	0/10
Unknown — availability could not be confirmed	Excluded

In this example, Two-Factor Authentication scores 10/10.

Evidence group 3 of 4

Billing Descriptor measures whether the company shows the expected billing name before the user pays.

The billing descriptor is the name that may appear on a bank or card statement.

Billing Descriptor

43%of Billing Descriptor (43% total)

Whether the company shows the expected billing name before the user pays.

How we test

Before completing payment, we check the checkout page, payment information, billing help pages, and subscription FAQs. We look for the exact billing name or a clear example of the name users should expect.

What counts

The exact statement name shown before payment
A representative descriptor clearly explained before payment
Billing information displayed during checkout
An official help page linked from the payment process

What does not count

Discovering the name only after the payment
A vague statement such as discreet billing with no name
An unofficial user claiming what appeared on their statement
Support providing the answer only after purchase
The company name appearing elsewhere without saying it is the descriptor

Result shown

Yes — “CCBILL.COM” was shown as the expected billing descriptor before payment

Scoring

We use the result categories below.

Result	Score
Yes — the expected billing name is shown before payment	10/10
Limited — partial or unclear billing information is shown	5/10
No — the billing name is not shown before payment	0/10
Unknown — it cannot be confirmed	Excluded

In this example, Billing Descriptor scores 10/10.

Evidence group 4 of 4

Security Incidents measures the number of confirmed breaches, leaks, or similar security problems connected to the company during the previous five years.

This test uses confirmed incidents rather than rumors or unverified user claims.

Security Incidents

43%of Security Incidents (43% total)

The number of confirmed breaches, leaks, or similar security problems connected to the company during the previous five years.

How we test

We search for incidents from the five years before the review date. We look for data breaches, exposed databases, leaked chats or media, unauthorized account access, security failures confirmed by an authority, and other incidents that exposed user information. For each incident, we save the source and relevant date.

What counts

An incident confirmed by the company
An incident confirmed by a regulator
An incident confirmed by a court filing
An incident confirmed by a reliable security report

What does not count

Unverified social-media posts
A user claiming their individual account was hacked
Service outages with no data exposure
Rumors with no supporting evidence
Incidents involving an unrelated company
Reports older than the five-year review period

Result shown

0 confirmed security incidents during the previous five years

Scoring

We use the ranges below.

Confirmed incidents in the past five years	Score
0 incidents	10/10
1 incident	6/10
2 incidents	3/10
3 or more incidents	0/10
Search not completed or result unclear	Excluded

A result of zero confirmed incidents scores 10/10.

Back to Privacy