When you sign in on a browser, Space Duck records a device label (derived from your browser's user-agent string) in the local audit cache. The trusted-device expiry is the number of days after which that label is treated as stale for reminder purposes on this browser.

Once a device label crosses the expiry window, the local interface shows an ⚠ Aging chip next to it in the trusted-devices panel and may prompt you to re-verify. This is a browser-local reminder only — the backend session remains valid until explicitly revoked.

No. Trusted-device expiry is a local label that drives on-screen reminder chips. It does not revoke your session, invalidate your token, or change your server-side trust score.

To actually end a session you must use the Revoke action in the Session Trust Map or the Sign out all other sessions button in the Security Audit.

Open Device Trust Preferences and adjust the Trusted-device expiry segmented control (7 / 14 / 30 / 90 days). Press Save preferences to persist the new value in localStorage.

Your change applies immediately to all reminder labels on this browser. Other browsers or devices are unaffected because the preference is local.

The trusted-devices panel groups entries by user-agent and IP bucket. If a session in the audit cache matches the same bucket as the current browser, it may not yet appear stale until the page re-loads and re-evaluates the age against your local expiry preference.

Try clearing the sd_audit_cache localStorage key (via browser dev tools) and reloading; the panel will re-fetch the latest events and apply the current expiry threshold. If you want to force-remove a session, use the Revoke button.

The local anomaly detector compares each recent auth event (from sd_auth_events) against your pattern and flags events that match any of these heuristics:

• New device — the user-agent string has not been seen in your local auth-event history before.
• New IP range — the first two octets of the signing IP differ from all previously stored IPs.
• Off-hours login — the event timestamp falls outside 07:00–23:00 local time.
• Rapid successive logins — two sign-in events occurred less than 60 seconds apart.

These checks run entirely in your browser against locally cached data. No alert is sent to the server.

Sensitivity controls how many heuristics must fire before an ⚠ Unusual activity amber card is surfaced on your profile page:

• Low — only surfaces a card when 3 or more heuristics fire simultaneously (rarer, fewer false positives).
• Medium — surfaces a card when 2 or more heuristics fire (balanced, the default).
• High — surfaces a card when any single heuristic fires (most sensitive, may show for routine travel).

Adjust the level in Device Trust Preferences. The setting is stored locally and does not affect server-side security rules.

Press That was me on the alert card. This records a local acknowledgement and suppresses that specific device+IP combination from triggering further alerts for 30 days. No server action is taken.

If you do not recognise the event, press Review to open the Security Audit and check for active sessions you did not create. If you see an unknown session, revoke it immediately.

When you open the Auth History page, recent sign-in events are grouped by country and IP bucket (first two octets) into a Sign-in Geography Digest. Each group shows how many events came from that region, and flags any region that was not seen in the prior 30-day window as New region.

A new-region flag means that none of your previous locally cached events originated from that IP bucket. It is a reminder prompt — not a block, not an alert sent to the server.

Almost certainly not — the new-region flag fires whenever your sign-in IP bucket changes, including for legitimate travel, VPN use, or a new mobile carrier IP range.

To dismiss the flag for that region, press Acknowledge in the auth-history geography digest. The region will be marked as recognised for 30 days and removed from the new-region highlight list.

If you have not travelled and do not recognise the IP range, review your active sessions in the Session Trust Map and revoke anything unfamiliar.

Space Duck records the IP address associated with each sign-in event in the server-side audit log. The geography digest reads these IPs from the /beak/audit/me endpoint (bearer-authenticated) and performs local grouping in the browser — it does not send IPs to any third-party geolocation service.

Country labels in the digest are derived from the first IP octet using a lightweight local mapping; they are approximate and may not reflect VPN exit nodes accurately.

When you arrive at a Space Duck page via a cross-domain single sign-on token (an ?sso= URL parameter), the page redeems the token via POST /beak/sso/redeem, stores your session locally, and briefly shows a blue 🔗 Signed in via SSO chip in the topbar.

The chip is informational only — it confirms your session was established through an SSO handoff rather than a direct email-password login on this domain. It auto-dismisses after the configured duration (default 30 seconds).

By default the chip auto-dismisses after 30 seconds. You can adjust this in Device Trust Preferences under SSO arrival chip duration. Available values are 15 s, 30 s, 60 s, and Always (chip stays until you navigate away).

The chip duration preference is browser-local and does not affect SSO token validity, which is always a server-enforced 30-second TTL regardless of how long the arrival chip remains visible.

The SSO bridge is active across the five official Space Duck surfaces:

• spaceduckling.com
• duckgalaxy.com
• duckcontrol.com
• spaceduck.bot
• mightyspaceduck.com

An SSO token arriving from any other domain will be rejected at redemption (invalid_token) and no chip will be shown. See the SSO Settings page for your current SSO session posture.

Set the SSO arrival chip duration to 0 seconds (i.e., select the "Off" option if available, or set it to the minimum) in Device Trust Preferences. The chip initialisation code checks the stored duration before rendering; a zero-second value means the chip is immediately dismissed without being visible.

Disabling the chip does not affect SSO redemption — your session is still established normally.

Device-trust and reminder preferences are persisted under the key sd_device_trust_preferences as a JSON object containing:

• trusted_device_expiry_days — integer (7, 14, 30, or 90)
• suspicious_login_sensitivity — string ("low", "medium", or "high")
• sso_chip_duration_minutes — integer (0, 1, 2, or 5)
• recovery_reminder_cadence_days — integer (7, 30, 90, or 180)
• saved_at — ISO timestamp of the last save

These values never leave your browser. They are not synced to the server, included in GDPR exports from the server, or visible to other browsers signed into the same account.

No. All security-authoritative decisions — session validity, trust score, cert status, peck approvals, SSO token issuance — are computed and enforced server-side. Browser-local preferences only control when and how this browser shows you reminders.

Clearing localStorage removes all browser-local preferences, the local audit cache, and your session tokens. Effects:

• You will be signed out of this browser (tokens are gone).
• Device trust preferences reset to defaults.
• The local audit cache is cleared; the trusted-devices panel will re-fetch from the server on next sign-in.
• Your server-side trust score, certificates, and active sessions on other devices are unaffected.

To re-apply your preferences after clearing, visit Device Trust Preferences and save again.

No. Each browser stores its own copy of sd_device_trust_preferences independently. If you set a 30-day trusted-device expiry on your laptop, your phone still uses the default (7 days) unless you update it separately on that device.

This is intentional — preferences are per-browser because trusted-device labels themselves are per-browser. A phone and a laptop have different hardware fingerprints and different trust contexts.

The Device Trust Preferences page is the single owner-side control surface for all four preference values. For server-side session management (revoke, audit, SSO posture), use the pages linked below.