ShareShield 4.0: organisations, policies, audit and API v2

ShareShield 4.0 is out today. It’s the largest release since the 2023 rewrite, and most of it is for teams that need to set rules and see what happened afterwards.

For teams

• Organisations with four roles. Owners, admins, members and viewers. Viewers can read but not create. Owners and admins see everyone’s secrets and requests (metadata only) and can burn any of them.
• Enforced policies. Owners set maximum and default expiry and views, require passcodes, switch anonymous viewers, files and requests on or off, and limit recipient email domains. The send form and the API both enforce them.
• An audit log of secrets, requests, members, API keys, policy, billing, sign-ins, 2FA and SSO. Professional and Enterprise organisations can export it as CSV.
• Two-factor authentication with an authenticator app and backup codes, which organisations can require.
• Single sign-on per organisation over OpenID Connect, starting with Microsoft Entra ID. Verify domains by DNS TXT record, enforce SSO on them (owners keep a password sign-in for emergencies), and let new sign-ups on an auto-join domain join automatically.

For sending secrets

• View limits, expiry in hours and early burning. Recipients get a burn link that destroys a misdirected secret unread.
• Email recipients. Send a secret to up to ten people, get an email when it’s opened, and optionally make it open only for them, with a six-digit code emailed to anyone who isn’t signed in as one of them.
• File secrets on paid plans, encrypted like text and downloaded as an attachment, never displayed in the browser.
• New link format. Links now use ten characters grouped for reading aloud (k7mq-2vx-r9t). They’re harder to guess, and case, dashes and look-alike letters are ignored when typed. A dead link now says whether it was opened, burned or expired.
• Encryption. Each secret has its own AES-256-GCM key, wrapped by a key we can rotate. Here is how it works and what it doesn’t protect against.

For developers

API v2 has an OpenAPI 3.1 description and reference documentation, and keys are now scoped and bound to one organisation. Reveal is POST-only, so link previews can’t burn a secret. The developer docs cover keys, scopes and errors.

What you may need to do

• If you call API v1, move to v2. v1 is deprecated and due to be removed 60 days after this release. API-key calls to v1 carry Deprecation and Sunset headers.
• Review your API keys. Existing keys were given every scope and bound to their owner’s oldest organisation. Narrow them to what each integration needs. Keys of users in no organisation were deleted.
• Check for 410. Opened, burned and expired secrets now return 410 Gone; 404 means only “no such secret”.
• Browser extension users. The old key handoff is gone and issued keys keep working. The extension notes explain what comes next.

Links created before the upgrade keep working until they expire, which is at most seven days.