Privacy policy

This covers verify.robloxaudios.online/privacy and the verification step that gates access to it. It is a community-run tool, not a company, and the data below sits on hardware run by the developer rather than a cloud provider.

What is collected when you verify

Data	Why
Discord user ID and username	To grant the verified role to the right account and to recognise repeat attempts.
Discord account creation date	Very new accounts are the most common alt-account signal.
IP address	Checked automatically to work out whether the connection is a VPN, proxy or datacentre, and to notice several accounts arriving from one connection. It is not displayed anywhere - see who can see it.
Network details of that address	The provider or hosting company that owns it, the network it sits on and who operates that network, the country it is registered in, whether it is reported as a VPN, proxy, Tor exit, relay, datacentre or known-malicious address, what kind of connection it is (residential, corporate, datacentre), and the reputation score one of the checking services gives it. Stored alongside the result so a decision can be reviewed later without the address needing to be looked at. This is registration data about the network, not a location for you - the country is where the address block is registered, which for a VPN is usually not where its user is.
Browser fingerprint	Hashes of your browser's canvas, audio, WebGL, font list and basic properties (screen size, timezone, platform, language). Used only to spot the same browser verifying on multiple accounts.
Outcome of the check	Whether you passed, and if not, the reason.

The fingerprint is stored as one-way hashes, not as the raw values. It identifies that two verifications came from the same browser; it does not describe you, and it cannot be turned back into your settings.

Your Discord password is never seen by this site. Signing in happens on discord.com through Discord's own OAuth flow, which hands back only your ID, username and account age.

What is not collected

No passwords, payment details, email addresses or phone numbers.
No message content, DMs or anything you post in the server.
No advertising or analytics trackers, and no cookies beyond the short-lived session cookie that keeps you signed in during the check.
Nothing is sold, rented, or shared with advertisers. There is no third party buying any of this.

How it is stored

Verification records are encrypted at rest with AES-256-GCM before they touch the disk. They live on self-hosted hardware, not a rented VPS or a managed cloud database.

Why AES-256 and nothing "stronger"

This comes up, usually alongside a suggestion to switch to a post-quantum algorithm, so here is the reasoning in full.

There is no stronger tier

AES-256-GCM is the top of its category, not a midpoint. The credible alternatives for encrypting stored data - ChaCha20-Poly1305, XChaCha20-Poly1305 - are equally strong, not stronger. Choosing between them is a trade about speed on processors without hardware AES support and about how nonces are managed, not about how hard the encryption is to break. Every modern processor runs AES in dedicated hardware, so here it is both the fastest option and the strongest available.

The key length is the part that matters

A 256-bit key means 2²⁵⁶ possible keys. That number is not merely large - it is beyond exhaustion by any machine that can physically be built, because the energy required to even count that high exceeds what is available to work with. Nobody breaks AES-256 by guessing keys, which is why attacks in the real world target the software, the server, or the person holding the key, and never the cipher.

Quantum computers threaten a different family of algorithms

The concern is real but frequently misapplied. Quantum computing breaks asymmetric cryptography - RSA and elliptic curve, the maths behind key exchange and digital signatures - using Shor's algorithm, which is an enormous speedup. That is a genuine problem and the reason the industry is migrating.

Symmetric ciphers like AES are only exposed to Grover's algorithm, which is a square-root speedup: it reduces 2²⁵⁶ to roughly 2¹²⁸ operations. That leaves AES-256 at about the strength AES-128 has today, which no one can break either. Grover's algorithm also parallelises badly, so throwing more quantum machines at it barely helps.

This is not a minority reading. The NSA's post-quantum guidance (CNSA 2.0) keeps AES-256 and replaces only the asymmetric components, and NIST's own post-quantum work concludes that symmetric encryption needs larger keys rather than replacement. Using a 256-bit key instead of 128 is the recommended quantum precaution, and it is what this uses.

Post-quantum algorithms do not do this job

ML-KEM - the NIST post-quantum standard usually suggested here - is a key encapsulation mechanism. Its purpose is letting two parties agree on a shared key across a network without an eavesdropper learning it; it replaces the RSA/elliptic-curve step, not the encryption itself. It cannot encrypt a file. A system built on it would use it to agree a key and then encrypt the data with AES-256-GCM regardless.

It also has nothing to attach to here. There is no key exchange in this design: the data sits on one machine and the key never crosses a network, so there is no second party and no handshake for a post-quantum algorithm to protect. Where it genuinely matters is the encrypted connection between your browser and this site, and that layer already uses post-quantum key agreement, handled by the network provider.

GCM also detects tampering

The GCM part is not decoration. It authenticates every record, so altering stored data is detected rather than quietly decrypting into something wrong. Plain encryption hides data without proving it is unmodified; this does both.

The honest limitation

Encryption at rest protects the stored file - a stolen disk, a leaked backup, a copy taken from the server. It cannot protect data from someone who has already fully compromised the running machine, because a running service must be able to read its own data. No cipher fixes that, and switching algorithms would not change it. That is why the practical protections here are keeping the service patched, never surfacing IP addresses in the first place, and hosting the data rather than handing it to a third party - and it is why "we use strong encryption" is only part of an honest answer.

Other protections in place

Encryption at rest is one layer. These are the others, across the list site and the verification step.

Signing in

Logging in happens entirely on discord.com through Discord's official OAuth flow. No password for your Discord account is ever typed into, transmitted to, or stored by this site.
The list itself is not public - it requires a Discord account holding the verified role in the server.
A Cloudflare Turnstile challenge sits in front of verification to keep automated sign-ups out.

Encryption beyond the stored file

Verification records, browser fingerprints and IP records are each encrypted with AES-256-GCM before being written.
Connections use HTTPS, and that layer already negotiates keys with post-quantum protection at the network provider.
On the list site, the data sent to your browser is additionally encrypted with a key derived per browser session, so an intercepted response is not readable as a plain copy of the database.

Keeping automated traffic out

Before the list is served, a browser completes an attestation handshake including a small proof-of-work - trivial for a real browser, expensive for a bot making thousands of requests.
Requests are scored for signs of automation, and sessions that behave like scrapers are throttled or blocked.
Per-session quotas cap how much can be pulled in bulk, and audio and image files are protected against being embedded from other sites.
Login, verification and admin requests are individually rate-limited to make guessing impractical.

The browser-facing basics

Session cookies are HttpOnly, so page scripts cannot read them even if a script were somehow injected; SameSite=Strict, which blocks cross-site request forgery; and Secure in production, so they are never sent unencrypted.
Framing is refused outright through both X-Frame-Options and a Content-Security-Policy, which prevents clickjacking - nobody can invisibly embed these pages inside their own.
Content types are not allowed to be second-guessed by the browser, and referrer information is not leaked to other sites.
Verification links are cryptographically signed and time-limited, so one cannot be forged, edited, or reused after it expires.

The machine itself

Everything runs on hardware the developer controls, not a rented cloud instance.
Each service runs in an isolated container as an unprivileged user rather than as root, so a fault in one cannot freely reach the rest of the system.
Dependency vulnerability alerts are monitored and patched.

Some specifics are deliberately left out of this page - the exact detection thresholds and the decoy endpoints used to catch crawlers - because publishing them would be handing over the instructions to evade them. None of the omissions concern what is collected about you or who can read it, which is what this policy is for.

Who can see it

Administrators of the Discord server, and only through a restricted view that requires them to be signed in. It shows verification outcomes, account ages and fingerprint match data.

Your IP address is not shown to anyone

The address itself is never displayed in that view, and there is no longer any way to reveal it. What administrators see instead is a description of the network it belongs to:

The internet provider or hosting company that owns it.
The network it sits on and who operates that network.
The country it is registered in.
Whether the checking services report it as a VPN, proxy, Tor exit, relay, datacentre or known-malicious address.
The kind of connection it is, and its reputation score - so a denial can be judged on what it was actually based on, and a score that looks wrong can be seen to be wrong.

That is genuinely all that a VPN decision rests on. "Belongs to a hosting company" is what makes an address suspicious; the exact digits add nothing to that judgement, so there is no reason for a person to see them. It also means that if the automated check gets it wrong - a home connection sitting in a range reported as a VPN, or a household, school or university network legitimately producing several accounts - an administrator can still look at why and overturn it, without ever seeing where you connect from.

What the developer can see

Plainly, because the source code for all of this is public and anyone can check: the developer holds the encryption key, and can therefore read the verification records. A policy claiming otherwise would not survive somebody reading the repository, so this one does not claim it. Encryption at rest protects the stored file from a stolen disk, a leaked backup or a copied database - it is not a promise that the person running the service cannot read their own data, and no service that can decrypt its own records can honestly promise that.

What that access does not extend to matters just as much:

Browser fingerprints cannot be reversed by anyone. They are one-way hashes, so neither an administrator nor the developer - nor anyone holding every key involved - can turn them back into your screen size, fonts or hardware. They can only be compared against each other to see whether two verifications came from the same browser.
IP addresses are not surfaced anywhere. No page, export or admin view renders one - only the network description above, which is what the checks actually rely on.
There is very little to read. A record is a handful of technical fields - an account age, a pass or fail, a reason, a hash. No messages, no DMs, nothing you have posted, no email address or phone number, nothing about you beyond the Discord account you verified with and the connection you used at the time.

Reading through those records wholesale is not part of running this, and there would be nothing to gain from it. The protection worth trusting is the narrow amount collected in the first place, not a claim that the data is somehow unreadable to the people who operate it.

Services this relies on

Discord (discord.com) - login, and granting the role.
Cloudflare Turnstile (challenges.cloudflare.com) - the "confirm you're human" check.
IPQualityScore (ipqualityscore.com) - the main VPN, proxy and Tor check. Your IP address is sent to it, and with it two headers your browser sends on every request anyway: which browser you are using and which languages you prefer. They are included because IPQS documents them as materially improving accuracy, and leaving them out makes false positives more likely, not fewer. It returns a classification of the address and a reputation score for it.
findip.net and rdap.org - the other two. These run first, and answer who owns the address and what network it sits on. Only the address is sent.

Each of these has its own privacy policy covering what it does with a request.

The answer for an address is remembered for up to seven days, so a household reconnecting or somebody retrying a failed attempt does not become a fresh lookup each time. The service is also capped locally at 35 lookups a day and 1,000 a month, which is the free allowance it runs on - past that the check is skipped for the rest of the window and the decision falls back to the other two. Nobody is denied for the budget having run out.

What a reputation score is, and is not

It describes the address, not you. An address's score largely reflects what has previously been done from it - often by whoever held it before, since home connections are handed out and reassigned constantly. A perfectly ordinary broadband line can carry a high score for that reason alone; one on a major cable provider came back with a score of 89 while being neither a VPN nor a proxy.

So the score is recorded, and shown to an administrator reviewing a decision, but it is not allowed to deny a verification on its own. Neither is "proxy". The only automatic denial comes from an address actively identified as a VPN or a Tor connection - and an administrator can overturn even that.

Some ISPs are misreported wholesale, for reasons of how they are built rather than anything their customers did - satellite providers most of all, where households share addresses that leave through a ground station hundreds of miles away and so look like a VPN to any database judging by location. Those are allowed through automatically rather than left to be appealed one at a time.

How long it is kept

Verification records are kept while the server is running, so administrators can review a decision or spot a pattern of alt accounts later. There is no fixed automatic expiry; ask if you want yours removed.

The VPN check's answer about an address is kept separately, encrypted like everything else, and discarded after seven days. It exists only to avoid asking the same question about the same connection repeatedly, and holds a classification of the address rather than anything about a person.

Removing your data

You can ask for your verification record to be deleted. Ask an administrator in xxx. Deleting it removes the alt-account history tied to your account, so you may be asked to verify again.

Children

Discord requires users to be at least 13, or older where local law says so. This tool is not directed at anyone below that age.

Changes

If what is collected changes, this page changes with it. There is no mailing list to notify, so it is worth re-reading if you are asked to verify again after a long gap.