Who could see it, how, and what each path costs to close

Most worry about uploading an intimate photo stays vague, because "what if it gets out" has no shape to check against. A threat model gives it a shape: a short list of who could plausibly see the file, the specific mechanism by which each one would, and what closes that mechanism. Five adversaries cover almost the entire realistic space, and each has a different answer.

Why a vague worry is worse than a specific one

A vague worry either gets ignored, because there is nothing to act on, or it gets generalised into avoiding the category of tool entirely, which throws away something useful over a risk that was never itemised. A specific threat model does the opposite: it names the adversary, states what they would have to do, and gives you one thing to check. Some of the five below are worth real attention. Others turn out to be smaller than they feel, once named. The point of listing them side by side is that the ranking becomes visible, which it never is while the worry stays a single undifferentiated feeling.

Adversary one: the service itself, operating normally

The first adversary is not malicious. It is the service doing exactly what its policy says, which may still mean more retention than you assumed. Whatever it keeps by design - the original file, a derived embedding, the score, the account history - is data it can act on for as long as its stated retention allows, and "acting on" includes things you did not picture: using uploads to improve future models, or keeping results as account history you can browse later, which is also a record that exists to be found later by someone else with access to the account.

The mitigation here is entirely about reading before uploading rather than about anything technical. Decoding what a retention clause is actually promising turns the policy's phrasing into a specific number and a specific set of systems, and the five different things "we do not store your photos" can mean matters because the difference between them is the difference between a file that is genuinely gone in seconds and one whose derivative persists indefinitely under a different name.

Adversary two: staff at the service

Encryption and access controls do not remove the fact that a person, somewhere, can plausibly open a stored file - a support agent handling a ticket, an engineer debugging a failure, a moderator reviewing a flag. This adversary is not the service as an abstraction; it is a specific human with credentials, and the question is not whether such access exists but whether it is logged, limited to what a role actually needs, and auditable after the fact.

Almost no privacy policy names this directly, which is itself informative: who at a company can actually open an upload is a question worth asking even when the policy is silent on it, because the silence is the default answer. A crash or error path is a specific version of this risk worth knowing on its own, since a failing request sometimes saves the input that broke it for an engineer to look at later, and that path is rarely covered by the retention promise that applies to the normal flow.

Adversary three: third parties the service brought in

Few rating tools run their own model end to end. Most call a hosted inference API, which means the file is seen by at least two organisations rather than one, and the second one's terms and retention apply on top of the first's, whether or not the product page mentions it. Analytics and advertising scripts embedded in the page are a second version of the same pattern - they can see the page you are on and, depending on how the site is built, information tied to your visit, even though they are not part of the rating pipeline at all.

When a tool sends your photo to another company's model is worth reading specifically for what it means for the number of parties involved, and a service that discloses its inference provider by name is telling you something a service that just says "our AI" is not. The same logic applies off the upload path entirely: analytics scripts on adult-adjacent sites can register a visit to a third party who never touched the image but now knows you were there.

Adversary four: a breach

This is the adversary most people picture first and reason about least precisely, because "breach" gets treated as one undifferentiated catastrophe rather than an event whose damage is bounded by exactly what was sitting in storage at the time. A service that retains almost nothing has almost nothing to lose in a breach. A service that retains the original file, a derived embedding, full account history and unredacted logs has all four to lose, and the breach itself does not create any of that exposure - the retention decisions made months earlier did. What a breach of a rating tool would actually expose works through this as its own subject, because the honest answer is always "depends what they kept," and that is answerable in advance rather than only after the fact.

Server and CDN logs deserve a specific mention here, because they are the copy nobody frames as a copy: what gets written down on every request includes URLs, timestamps and often enough context to link an upload to a device, and a breach of a log store is a breach even when the "photo storage" itself was never touched.

Adversary five: someone with your device or your account

The last adversary is not the company at all. It is a person who has your phone, your open laptop, or your logged-in session - a partner, a family member, someone who finds a device unlocked. This is the adversary the other four completely miss, because none of the service-side controls in the world stop a result sitting in your notification tray or your browser history from being seen by whoever is standing next to the screen.

Cache, history and autofill left behind after an upload persist locally regardless of what the service does server-side, a shared or borrowed device carries its own residue - autofilled emails, cached thumbnails, sessions that never logged out - and a notification preview on a locked screen can show a result to anyone glancing at the phone, without unlocking anything at all. This is the cheapest category to close, because every fix is something you control directly rather than something you have to trust a company to have done correctly.

Putting the five together

None of these five is hypothetical, and none of them requires you to distrust a specific tool to take seriously - they are the same five questions for any tool in this category, Rate Cock included, and a service worth using is one whose policy answers most of them without you having to guess. A photo of someone else adds a sixth consideration that sits outside this list entirely, since consent is a question about the subject rather than about the pipeline, and no amount of technical care on the service's side resolves it.

Ranking the five by how much you control

The five adversaries are not equally within reach, and the ranking is worth stating plainly rather than left implied. The service, staff and third parties are all trust decisions you make once, at the moment you pick a tool, by reading a policy rather than by any ongoing action. A breach is nobody's decision at the moment it happens - it is a probability that retention choices scale up or down, and picking a service with disciplined retention is the only lever you have over it, applied in advance. Someone with your device is the one adversary you manage continuously rather than once, through habits rather than through a policy you read a single time: locking a phone, signing out on anything shared, checking what a notification shows before it shows it. Treating all five with the same kind of attention is a mistake in the other direction - reading a policy exhaustively while leaving a phone unlocked on a shared table addresses the adversary that was already smallest and ignores the one that was largest.

A five-minute version of this checklist

Not every upload deserves the full read-the-policy treatment, and a shorter version covers most of the risk in less time. Check that the page uses HTTPS, which is now close to universal and a bad sign in its absence. Look for a stated retention period rather than only a blanket promise, since a number is the difference between a checkable claim and an assertion. Strip EXIF before uploading regardless of what the service claims to do with it, since it costs nothing and removes the question entirely rather than trusting an ingest pipeline to have done it correctly. Use a private browsing window for a one-off session, which handles the fifth adversary without requiring you to remember to clear anything afterwards. None of these four takes more than a minute, and together they close a meaningful fraction of the five adversaries above without requiring a full policy audit every time.

What sits outside this model

A commissioned human review is a structurally different threat model from an automated scorer, because a person has to see the file to do the job, and what a human-reviewed submission actually retains is worth reading as its own case rather than assumed to match an automated tool's five adversaries. A measurement taken by hand and never turned into a file sidesteps all five at once, which is the actual advantage Measure My Cock's method has over anything routed through a server - there is no upload for any of these five to reach. Comparing several tools specifically on how well they answer this list, rather than on features, is close to what Penis Rater's tools coverage is built to do, and it is one of the few comparisons that predicts something about risk rather than convenience.

Five adversaries, five separate mitigations, and only one of the five - the last - is entirely within your own control regardless of which tool you pick. That is the actual shape of the worry, once it has one.