CardConduct
Privacy

What we hold, and what we deliberately do not.

This site publishes accusations, so the thing most worth protecting is the person who made one. The short version: we never learn who files a report, because there is no field on the form and no column in the database for it. Everything below describes what this code actually does. It was written by reading the code, not from a template.

Effective . Operated by StephensCode LLC, a Texas limited liability company.

When you file a report

We do not ask who you are

The report form has no name field, no email field, and no account behind it. The reports table in our database has no column for a reporter's identity, so there is nothing to leak, sell, hand over, or lose. This is not a promise to delete your details later. We never receive them.

What the form actually sends

  • The game, and the marketplace or platform.
  • The seller handle you are reporting, as you typed it.
  • The listing or stream URL, if you give one.
  • The red flag you picked, and the asking price, if you give one.
  • Your written description of what happened.
  • Up to six screenshots, at most 6MB each.

All of it is stored. The written description and the screenshots can be published later if the report survives investigation, so write them as though they will be public, because they may be.

Screenshots are re-encoded before they touch disk

Several of the things people report here cannot be screenshotted, so phone photos are a normal case, and a phone photo carries GPS coordinates, a capture time, and a device serial. Published evidence is anonymously fetchable, so storing those bytes unchanged would hand a listed seller the reporter's home address. Every accepted image is decoded and re-encoded through a fresh encoder, which drops EXIF, XMP, IPTC and embedded text chunks. We then re-read our own output and refuse to store it if any of that survived. The bytes you upload are never written to disk. Only the re-encoded copy is kept.

Orientation is baked into the pixels before the tag is dropped, images over 4000 pixels on a side are downscaled, and anything we cannot decode and verify is rejected rather than stored.

A salted hash of your network address

We store one derived value: an HMAC-SHA-256 of the submitting network address, keyed with a secret held only on the server and truncated to 32 characters. It exists so a flood of submissions from one source can be counted and slowed. In production the code refuses to hash anything at all unless that secret is configured, which means it refuses the submission, because a guessable salt would turn the stored hashes back into a list of addresses.

Be exact about the limit of that promise. Two submissions from the same address produce the same hash, so the hash can tell us that two reports came from one place. It cannot tell us where that place is, and it is never published, never attached to a public entry, and never included in the notification email a submission generates.

When you dispute a listing

A dispute is the one place we do ask for a contact, because the entire point is that we answer you. We store the handle, the platform, your claim, what you say actually happened, and the contact you give us.

That contact is used to reply to you and for nothing else. It is not rendered on any public page, it is not added to any list, and this site sends a disputing seller no mail other than a reply about their dispute. A dispute also carries the same salted address hash, for the same throttling reason.

What is never collected

  • Reporter names, emails, accounts, or any other reporter identity.
  • Payment details. Nothing here is paid for.
  • Legal names, home addresses, phone numbers, or employers of the sellers we list. We identify a seller by their public handle, and reports carrying private details are rejected.
  • Location data. The one route it could arrive by is image metadata, which is stripped on intake.
  • Anything from any tracker, because there are none. See cookies below.

Cookies and tracking

This site sets exactly one cookie, and only for the moderator. It is the admin session, set after a successful login to the moderation console, marked HttpOnly, SameSite=Lax and Secure, and it expires after twelve hours. If you are reading the record, filing a report, or filing a dispute, this site sets no cookie at all.

There is no analytics package, no tag manager, no advertising pixel, no session recorder, no A/B testing tool, and no social embed. Fonts are served from this domain rather than a font CDN, so loading a page here does not make a request to anybody else. There is nothing to opt out of, which is why there is no cookie banner.

Who else touches any of this

Email

When a report or a dispute arrives, the site emails the operator, so the review clock starts against a human rather than an unwatched queue. That mail goes out through a third-party email provider. It carries the submitted text and the handle being reported. It never carries the screenshots and never carries the address hash, on purpose: the evidence stays behind the login.

Hosting

The site runs on a server rented by the operator. The database and the evidence files live on that server's own disk, outside the web root, not in any third-party storage or database service.

Server logs

The web server in front of this app logs client addresses truncated to a network block rather than in full, and the report and dispute endpoints are configured to write no access log line at all, so no log entry exists that pairs a timestamp with a submission. The moderator login is logged in full, because that traffic is the operator's own and matters for security.

How long it is kept

Plainly, without dressing it up: retention is currently indefinite. Reports, disputes, investigation findings, and evidence images are kept until a person removes them. There is no expiry job in this code, and we would rather say that than publish a deletion schedule the software does not run.

  • A dismissed report can be purged at the moment it is dismissed, which deletes its image files from disk. That is a decision the moderator makes on each one, not an automatic sweep.
  • A cleared handle disappears from the record and its page stops resolving. The underlying report, findings, and image files are retained.
  • Backups of the database and the evidence are taken daily. Full archives are held about a week, database-only archives about ninety days, and one full archive a month is held about thirteen months. So something deleted today can still exist inside a backup for up to roughly thirteen months before it ages out.

If that changes, this section changes and the effective date moves with it, rather than a job quietly running that the policy never mentioned.

Asking what we hold, and asking us to delete it

If your handle is listed

Email legal@cardconduct.com with the handle and the platform. Because there are no accounts here, we need something that ties you to the handle: a message from the address that storefront publishes, a reply sent from the platform account itself, or a post from that account confirming the request. We will then tell you everything held about that handle - every report against it, every finding and the source checked, how many screenshots are on file, the dates, and the current status.

One thing we will not give you is anything that identifies who reported you. That is not a policy you could talk us out of. We do not have it.

If you filed a report and want it withdrawn

Email the same address. Since we never learned who you are, we cannot look your report up by your name, so give us the handle you reported, the platform, and roughly when. We will find it and delete it along with its screenshots, as long as it has not already been published as part of an entry. If it has, say so and we will treat it as a correction request against that entry instead.

If you want an entry about you taken down

The route for that is the dispute form, not an email. It goes straight into the review queue and the evidence gets re-checked against what you say. If it does not hold up, the entry comes down and the log records the correction. If it was an honest mistake and you say so, the handle is cleared and removed. What we will not do is delete an entry the evidence still supports because it is unflattering. That is the whole point of keeping a record.

How these are handled

By a person, by hand. There is no ticketing system and no automated pipeline behind any of it. If a request needs us to confirm who you are first, we will say so rather than act on an unverified claim about somebody else's handle.

Security

Evidence files sit outside the web root and are served only through an endpoint that refuses anything not attached to a published entry. The moderation console is behind a password stored as a scrypt hash and a signed, expiring session. Uploads are identified by their actual bytes rather than by filename or declared type, so a script wearing a .png extension never reaches disk. No system is perfect, and if something here is ever exposed we will say what happened rather than hope nobody noticed.

Children

This site is not directed at children and has no accounts. Since we collect no identity from anyone, we have no way to know a submitter's age. If you believe a child submitted something here, email us and it will be removed.

Changes to this policy

When this policy changes, the effective date at the top of the page changes with it. We do not publish an archive of previous versions, so if a specific wording matters to you, keep a copy. Changes that materially affect what is collected or how long it is kept get called out on this page rather than slipped in.

Questions about any of this go to legal@cardconduct.com.