security: announce a fresh EIP-6963 provider UUID per page load (closes #398)
The provider UUID was generated once, kept in extension storage and announced to every page on every load, so any site could read it as a stable identifier for the install across sites and browser restarts. inpage.js now generates one UUID per page load, shared by every announcement in that load, and stores nothing. The eip6963Uuid storage key and the AUTISTMASK_PROVIDER_UUID content-script message are removed. The key was never part of the versioned autistmask profile, so the state schema is untouched. Two inpage.js message listeners lose the leftover name onUuid. The test posts each load the same stored UUID the way the old content script did, and asserts that no load announces it and that two loads announce different UUIDs. Model: opus-5-5
This commit was merged in pull request #412.
This commit is contained in:
@@ -143,6 +143,17 @@ but the review is broader than any of them.
|
||||
both routes take, so they behave the same and the button is live for the next
|
||||
delete.
|
||||
|
||||
- 2026-09-21: The EIP-6963 provider UUID is generated fresh on each page load
|
||||
and never persisted ([#398](https://git.eeqj.de/sneak/AutistMask/issues/398)).
|
||||
It was created once and stored, then announced verbatim to every page on every
|
||||
load and across restarts, so any site — connected or not — could read it as a
|
||||
stable cross-site, cross-session identifier for the install, contradicting the
|
||||
"no tracking" promise. inpage.js now announces a per-load
|
||||
`crypto.randomUUID()` and the `eip6963Uuid` storage key and the
|
||||
`AUTISTMASK_PROVIDER_UUID` content-script message are gone. That key was a
|
||||
standalone storage entry, never part of the versioned `autistmask` profile, so
|
||||
the state schema is untouched and no existing profile is affected.
|
||||
|
||||
- 2026-08-30: An address no longer wraps, or is shortened to fit, in any of the
|
||||
common views ([#380](https://git.eeqj.de/sneak/AutistMask/issues/380)). The
|
||||
wallet list was the reported case: the address shared one row with the
|
||||
|
||||
Reference in New Issue
Block a user