Commit graph

10 commits

Author SHA1 Message Date
Local Dev
a6f7b335a5 Vault: PIN setup steps, 6-8 digit PINs, save and offer logins, keep sign-ins
The PIN could only be six digits and was set from three bare inputs; the
unlock prompt sat at the top of the page; and the password manager only
filled when you found the key chip, never offered to save, and "Clear
cookies on quit" signed you out of every site, including the ones whose
login the vault already holds.

- PINs are 6 to 8 digits. The PIN record stores its length so pads draw the
  right number of dots and submit on the last digit; a PIN of the wrong
  length is refused without a strike, so an older Aegis pad cannot burn the
  count against an 8-digit PIN.
- Settings sets a PIN in steps: master password, choose the PIN on a pad
  (6/7/8), repeat it, done. The locked vault opens Theseus's own prompt,
  which is now centred, with the PIN pad or the master password field.
- After a sign-in or sign-up form is sent and the page moves on, Theseus
  offers to save (or update) the login, with an optional "ask for my PIN or
  password before filling it". Focusing a login form offers the saved
  logins under it; on a locked vault it offers to unlock first. A failed
  login (the password field still showing) gets no offer.
- "Keep sign-ins for sites in your vault" (on): the quit clear spares the
  cookies and site storage of sites with a saved login. Their hostnames are
  kept sealed with the OS keystore so the list is readable at quit while
  the vault is locked. Verified end to end on a scratch profile: signed in,
  restarted, still signed in; another site's cookie was cleared.
2026-10-04 20:23:43 +02:00
Local Dev
4ad8f4e401 Theseus: a long approval scrolls inside the overlay instead of pushing the buttons off screen
The approval box had no height limit inside a fixed mask, so a long
message or many rows pushed the end of the text and the buttons out of
view. The box now scrolls, long values scroll in place, and the
buttons stay pinned at the bottom.
2026-10-04 04:23:01 +02:00
Local Dev
2dfa9e9c3e Theseus: an add-on's key namespace cannot be taken by another add-on
- `absorbs` lets one add-on derive under another's vault namespace. A
  community install has the field stripped, but an update of one is placed
  as shipped, so a second version could declare absorbs:["aegis"] and derive
  the wallet's keys. It is now honoured only for ids that ship inside
  Theseus, at the one place that matters: vault.derive.
- The legacy ids Aegis absorbs ("bchwallet", "siawallet") no longer have a
  bundled folder, so nothing stopped a catalog extension from installing
  under one and deriving `bchwallet/...`. They are reserved at install and
  refused at derive.
- A page-to-add-on message is accepted only from the tab's top-level frame.
  The origin shown to the user is the top-level URL, so a subframe that
  reached the channel would have been credited with its parent's origin.
- The approval overlay ignores everything but Cancel for the first 800 ms.
  A page can raise it without a gesture and knows where the primary button
  lands, which made "double-click here" a way to approve a spend.
2026-10-04 01:41:01 +02:00
Local Dev
7806e3f31c fix(theseus/light): sweep hardcoded acid → var(--acid), Theseus button uses BCH dark
Two follow-ups on the light-mode acid work:

1) Every hardcoded #d6ff3d and rgba(214,255,61,X) in the browser
   chrome and every addon panel now goes through var(--acid), so the
   light-mode BCH-teal (#0AC18E) takes effect everywhere — not just
   where var(--acid) was already used. Hex-with-alpha (#d6ff3d55 etc.)
   converts to color-mix(); rgba() converts to rgb(from var(--acid)…)
   for the same alpha with the current --acid hue. Chromium 128+
   supports both. Files touched: chrome / settings / error / home /
   approval / bchwallet / siawallet / screenshot (html + css).
   Screenshot editor.js's #d6ff3d stays — that's the drawing colour
   swatch, not UI chrome.

2) The Theseus button (.logo) and update chip (.upchip) become dark
   BCH-navy chips (#253A49 background, #F8FDFF text) in light mode.
   Previously the .logo hardcoded #d6ff3d text on a bright-acid tint —
   invisible on a light toolbar. The dark chip stands out and gives
   the light theme a distinct accent using the BCH secondary from
   whybitcoincash.com's palette.
2026-09-08 01:06:40 +02:00
Local Dev
f8c58538d0 fix: use BCH-primary #0AC18E in light mode + strip Electron token from UA
Two related visibility fixes:

1) Light-mode --acid → #0AC18E (Bitcoin Cash brand primary, from
   whybitcoincash.com's palette per user). Direct swap from #088A66
   (darkened variant) to the on-brand primary. Applied across chrome /
   settings / error / home / approval / messages / bchwallet /
   siawallet / screenshot editor. Dark mode's #d6ff3d is unchanged.

2) User-Agent no longer includes 'theseus-navigator/<ver>' or
   'Electron/<ver>' tokens. Cloudflare's WAF was returning HTTP 503
   'Service Unavailable' to any request carrying those (verified
   directly against whybitcoincash.com — same URL, same headers, only
   the UA differed; plain Chrome UA got 200, Theseus UA got 503).
   Strip both tokens via a stockChromeUA() helper called from
   applyAcceptLanguage(), which whenReady already invokes at boot.
   Standard practice: Brave, Vivaldi, Slack all do the same.

Verified via CDP: navigator.userAgent now reports
  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
  (KHTML, like Gecko) Chrome/130.0.6723.191 Safari/537.36
— indistinguishable from stock Chrome.
2026-09-08 01:04:27 +02:00
Local Dev
9d81c29656 fix(theseus/light): light-mode acid → BCH-teal #088A66 (brand-family, AA on white)
Prior light-mode --acid was #3a5c00 (dark olive-green) — legible but
off-brand. The Bitcoin Cash brand primary is #0AC18E (a teal-leaning
green already used in bchwallet's --bch variable). Darken it a step to
#088A66 for AA text contrast on white (~5:1) while staying in the BCH
family — the light-mode accent now reads as "Bitcoin Cash green,
darkened for legibility" instead of an arbitrary olive.

Applied across every chrome page + addon panel that carries the light
override (chrome / settings / error / home / approval / messages /
bchwallet / siawallet / screenshot editor). Dark mode's #d6ff3d
untouched.
2026-09-08 00:49:46 +02:00
Local Dev
c9106d4ede fix(theseus/light): darker acid (#3a5c00) + add missing overrides in addon panels
Previous #4d7300 (0.3.10) was still too light against actual white
backgrounds — several tint fills (rgba(214,255,61,X)) and unpatched
addon panels were making the effective color feel bright green. Two
fixes bundled:

1) Bump --acid in every top-level page's light-media block from
   #4d7300 to #3a5c00 — same hue, ~7:1 contrast on #ffffff (was ~5.5:1).
2) Add the missing light-media --acid override to the addon panels
   that were still resolving to #d6ff3d: bchwallet/panel.html,
   siawallet/panel.html, and screenshot/editor.css (was #b4e024, now
   #3a5c00 to match).

Dark mode unchanged. Tint fills (rgba backgrounds at low alpha) still
stay as-is — at 8–15% opacity the specific hue barely matters and the
darker foreground now dominates.
2026-09-07 00:56:33 +02:00
Local Dev
878b728ef8 fix(theseus/light): darker --acid in light mode so brand green stays legible
#d6ff3d on a #ffffff / #f6f8fb background sits at ~1.3:1 contrast — the
acid green went almost invisible any time the user flipped Settings >
Theme to light. Override --acid to #4d7300 in every chrome page's
prefers-color-scheme: light block. Same hue family, ~5.5:1 contrast
on white, still reads as the same brand color.

Also: chrome.html was missing --acid: #d6ff3d in :root entirely (every
site used var(--acid, #d6ff3d) fallbacks). Adding the real declaration
means the light override can actually take effect.

Files touched: chrome.html, home.html, settings.html, error.html,
approval.html, messages.html. downloads.html is a dark-only overlay
(hardcoded), collision.html already had a proper light-mode --bcdn.
Tint fills (rgba(214,255,61,X) at low alpha) stay as-is — the specific
hue barely matters through 8% opacity.

Verified live via CDP: getComputedStyle(--acid) returned #d6ff3d in
dark, #4d7300 after cfg.set('theme','light').
2026-09-06 21:12:45 +02:00
Local Dev
40391798e0 feat(theseus/bchwallet): per-site payment allowance for remembered sends
The dapp send approval gains an "Afterwards" dropdown: ask every time, or
allow up to 0.001 / 0.01 / 0.1 BCH more without asking. The allowance is
stored as permissions[origin].sendTx {capSats, usedSats}; sends within the
remainder go through silently and draw it down, a larger request re-prompts
(showing what is left) and the choice made there replaces the allowance.
No unlimited option. Settings > Connected sites shows the remaining budget
and Revoke clears it. Message signing still asks every time.

Host: approvalModal accepts `select` {id, label, options}; a chosen value
comes back as "+<id>=<value>" and is validated against the offered options.
2026-09-06 12:43:17 +02:00
Local Dev
ffeda26345 feat(theseus/addons): vault-derive, page-inject and approval-modal capabilities
Three opt-in capabilities for add-ons, plus the plumbing they need:

- vault-derive: api.vault.derive("<id>/<path>") resolves once the password
  vault is unlocked with a 32-byte HKDF child of the vault root under
  "silentmode/addons/<path>". Path must start with the add-on id.
- page-inject: manifest "page-inject" {preload, origins}; a session-wide
  preload asks main (sync, against the committed URL) which add-on bridges
  apply and runs them in the isolated world with a scoped `theseus` object.
- approval-modal: api.approvalModal({title, body, origin, rows, actions,
  checkbox}) shows a consent overlay over the tab area (approval.html);
  resolves to the picked action id, "cancel", or "<id>+<checkbox>".
- api.onMessage/emit + window.silentmode.invoke/on for panel <-> activate()
  messaging; page bridges use addon-page-msg, gated by tab + origin match.
- api.require so add-ons can share Theseus's dependency tree.
2026-09-06 02:33:26 +02:00