Security policy

Reporting a vulnerability

Open a private security advisory on the extension repository. It is private until we publish it, it threads the whole discussion in one place, and it is the only channel that gets a report to the operator without it sitting in a public issue first. If GitHub is not an option for you, the contact address in security.txt reaches the same person.

A report is easiest to act on when it carries the affected component and version, the steps to reproduce it, what an attacker gains, and anything you already know about the fix. A working proof of concept is welcome; the smallest one that demonstrates the impact is better than a broad one.

What you get back. An acknowledgement within 7 working days, and an honest assessment rather than a silent triage queue — including the cases where we disagree that a finding is exploitable, with the reasoning. Emojery is one person's project: expect a direct answer rather than a service-level agreement. Fixes ship as fast as severity warrants, and a fix to the extension reaches users through the store review process, which we do not control.

Credit. Reporters are credited by name or handle in the published advisory unless they ask not to be. There is no bug bounty — the project is free and donation-funded, and pretending otherwise would waste your time.

Scope

In scope:

• The browser extension, whether the store build or the source — it runs inside other people's browsers, so anything that escalates its access, leaks a session, or turns a page into a way to reach it is the highest-priority category here.
• The public API at api.emojery.app: authentication, the reaction endpoints, and the public /log/* reads.
• This website, emojery.app.
• The public log and the open-source verifier — including any way to make the verifier accept a log that should not verify, which is a break of the whole trust model even without a server-side flaw.

Out of scope:

• The third-party sites Emojery renders on. Their bugs belong to them; report those to the platform.
• Findings that require a compromised device, a malicious browser extension already installed alongside ours, or a user pasting attacker-supplied code into a console.
• Missing hardening headers, cipher preferences, and scanner output with no demonstrated impact. Show what it lets an attacker do.
• Volumetric testing of any kind: denial of service, load generation, brute-forcing a rate limit or a sign-in code. These degrade a live service for its users and prove nothing we do not already know.
• Social engineering, phishing the operator, and anything physical.

Rules that keep testing authorised

The acceptable use policy forbids probing the service. This section is the exception to that rule, and it holds as long as your testing stays inside it:

• Use your own account and your own test targets — a page you control instead of someone else's post.
• Stop at proof. The moment you can reach data that is not yours, that is the finding; do not collect it, and do not go further to see how much more there is.
• Do not modify or delete anyone else's data, and do not degrade the service for anyone else.
• Keep the finding private until a fix ships or 90 days pass, whichever comes first. If the fix needs longer, we will say so and why.

Safe harbour

Research that follows the rules above is authorised. We will not pursue legal action over it, will not terminate the account used for it, and will treat an accidental overstep that you report promptly as part of the research rather than as abuse. If a finding required touching data that was not yours before you realised it, say so in the report — that is a better outcome for everyone than a quiet deletion.

Testing that ignores the rules is not covered, and falls back under the acceptable use policy like any other traffic. The distinction is the conduct, never the intent stated afterwards.

What we do on our side

Traffic is encrypted in transit, long-lived data is encrypted at rest, and the identifiers we keep are one-way hashes rather than raw values — the reasoning, and what that leaves us holding, is in the privacy policy. There is no password database to leak, because the one-time code is the authenticator. The extension is open source and its permissions are itemised on Browser permissions, so the client half of this system can be audited without asking us anything.

Server-side defences are deliberately not described here, and neither are the windows they run on — the reasoning is the same one that keeps them out of the privacy policy. Everything a researcher needs is reachable by testing within the rules above; everything else would only shorten someone else's homework.

If a security incident affects personal data, the notification obligations we hold ourselves to are stated in the privacy policy rather than invented after the fact.

security.txt

The machine-readable version of this page lives at https://emojery.app/.well-known/security.txt (RFC 9116). It carries the contact route, this page as the policy, and an expiry date — if that date has passed, the file is stale and this page is the authority.