Security

Four things are worth knowing about how Issue Mint is built: your sending credentials are encrypted and never displayed, the links your readers get are signed, every URL we fetch on your behalf is checked before we fetch it, and the pages your readers see run no JavaScript at all.

None of it needs configuring. There is no security section to set up and no hardening checklist to work through, which is why this page is a short one.

Passwords and signing in

Issue Mint stores a hash of your password rather than the password, so no screen, no log line and no support conversation can reveal it. The minimum length is eight characters and no other rule is imposed.

Five failed sign-ins from the same email address and network pause that combination for a minute. Password reset links last an hour and can be requested once a minute, and the link in a reset email is signed, so a truncated or edited one is refused rather than half-honoured. Changing a password is on the Password tab.

Your sending credentials

If you send through your own Amazon SES or SMTP account, those credentials are encrypted in the database and marked so they cannot be serialised into a page, a log or an error report. The interface shows dots and the last four characters, and nothing else, ever.

That masking is why the setup screens ask you to paste a key again rather than letting you check the one already there: we genuinely cannot show it back to you. Connecting your own Amazon account walks through what to paste. If you use hosted sending, which is the default and needs no setup, there are no credentials of yours in the system to protect.

The links your readers get

Every reader-facing link Issue Mint generates is signed, so a reader cannot reach anybody else’s record by editing a URL.

The three that matter behave differently, on purpose. An unsubscribe link is signed and never expires, because it has to work in an email somebody kept for a year, which is what makes one-click unsubscribing honest. A double opt-in confirmation link is signed and expires after seven days, since a week-old confirmation is not evidence of anything. And the recipient marker on a tracked link is its own short signature, checked on every click and open, so one reader cannot forge engagement against another subscriber or bend your figures.

Every URL Issue Mint fetches is checked first

When you paste a link into the composer, Issue Mint reads that page from our servers to prefill the title and your note. Before it reads anything, the address is checked, and addresses that resolve inside a private network are refused.

The rules are narrow deliberately. Only http and https are followed, only the ordinary web ports, and every answer a hostname resolves to has to be a public address rather than merely the first one. Each redirect is re-checked before it is taken, up to 3 of them, because a public URL that redirects somewhere internal is the classic way round a check like this. A fetch gives up after 5 seconds and reads at most 1 MB.

A refused address shows a short message in the composer, and that message deliberately does not say what the address resolved to. Adding a link by hand still works when a look-up is refused or a page will not load at all, so a stubborn URL costs you a title and a description rather than the link.

The pages that run no script at all

Your newsletter website, the confirm and unsubscribe pages your readers land on, and the previews in the composer are all served with scripting switched off at the browser level.

These are the pages that render text other people wrote, which is exactly where a script would do the most damage: a curator’s markdown, and the notes readers attach to a link they submit. Markdown is rendered with raw HTML escaped rather than passed through, and unusual link protocols stripped, so the worst a determined submission can produce is ugly text. It also leaves your archive with no tracking script to disclose and nothing loading in front of the words.

Who at Issue Mint can see your account

Support can open your account to look at a problem, and every one of those sessions is recorded: who did it, whose account, when it started and when it ended.

That record exists so the question “was anybody in my account on Tuesday” has an answer. It is used to reproduce something you have reported, and nothing about your data is looked at for any other reason.