Acceptable use and abuse reports

Decided in issue #91. This is the published page; the source text is kept in the repository alongside the code that enforces the parts of it that are enforced, so the two cannot drift apart without someone noticing.

The API renders a URL or an HTML fragment that you supply into an image or a PDF. That makes the rules about what you point it at, not about what we render.

What you may not do with a key

• Render, generate or distribute child sexual abuse material.
• Build or capture phishing and credential-harvesting pages — including screenshots of a real sign-in page used to make a fake one look convincing.
• Distribute malware, or render a page whose purpose is to deliver it.
• Impersonate a real person or organisation: their branding, byline, domain or record, presented as genuine. A mockup that says it is a mockup is fine; a fake receipt is not.
• Scrape in breach of a target site's terms — including using the renderer to get around a paywall, a rate limit or a block that the site applied to you.

Also, and this one the code enforces rather than the policy: do not point a render at a private network, a cloud metadata endpoint, or our own infrastructure. See enforced in code below, and the mechanism on the screenshot sheet.

Reporting abuse

[email protected]. Useful reports include the URL or image you saw, when (UTC), and where it was served from. If the rendered image is still reachable, its URL identifies the render. A key prefix (sk_ plus eight characters) identifies the customer, if you happen to have one — no response header carries it, so most reporters will not.

• Ordinary reports: a response within 72 hours. Most turn out to be a support question or a misdirected complaint about a site we merely photographed.
• Child sexual abuse material, phishing and malware: the key is suspended immediately, without notice and before any reply. A suspended key answers 401, indistinguishable from an unknown one. We would rather be wrong for a day than serve one more of those renders while a mailbox is being read.

We do not act on a report by removing content from someone else's website — we have no access to it. What we can do is stop the key that rendered it.

What we keep, and for how long

We record one row per served call: the key, the matched route pattern (/v1/screenshot), the plan, the HTTP status, how long it took, how many bytes came back, and a request id. It deliberately does not record the URL you asked us to render. Query strings carry other people's personal data, and a log of what every customer renders is a liability we do not want to hold.

So, plainly: nothing in the API stores target URLs today. A report is investigated from what the reporter provides plus the usage row it matches. The one URL-shaped thing that reaches a log is a refusal, and it carries the reason — private_address, bad_scheme — and not the address.

If investigating abuse ever requires recording target URLs, 30 days is the ceiling: long enough to act on a report that arrives weeks late, short enough that the log never becomes a history of what customers render. That is a rule for whoever builds it, not a description of something running now.

Enforced in code, not by policy

These are refusals you meet whether or not anyone reads this page. They are listed so this page is not read as the only thing standing between the renderer and abuse.

• The SSRF guard. Every render's browser is pointed at an in-process proxy that does its own DNS and opens its own sockets, so the address checked is the address dialled. Non-http(s) schemes, credentials in the URL and internal names (.internal, .local, .localhost, .home.arpa) are refused without a lookup; every resolved address is checked against the IANA special-purpose ranges for IPv4 and IPv6, including the v6 forms that embed a v4 address, and every address a name returns must pass, not just the first. Redirects and sub-resources are new connections, so they are checked again by construction. Our own public addresses are refused by name, because a range table cannot catch a box pointing at itself.
• Per-key concurrency. A key gets its plan's number of renders in flight, out of a small shared pool, and a plan is never enforced above the permits that exist — so no key can take the renderer away from everyone else. The plans sheet publishes both the sold and the enforced figure.
• Monthly quotas and a per-minute limit. Both are refused before the work is done, so a refused call is never billed. Getting started has the full list of refusals.
• Budgets per render: a byte cap across every connection one render makes, and a hard timeout.

Changing this

Anything here about response times or suspension is a commitment to customers. It changes on this page and in the repository together, never in one of the two.