The EIP-6963 provider UUID was generated once, stored in extension storage,
and announced verbatim to every page on every load and across restarts, so any
site — connected or not — could read a stable cross-site, cross-session
identifier for the install: a supercookie contradicting the README's "no
tracking". EIP-6963 wants a fresh UUIDv4 per announcement.
src/content/inpage.js now announces a per-load crypto.randomUUID() and
persists nothing. The eip6963Uuid storage key and the AUTISTMASK_PROVIDER_UUID content-script message are removed, along with the
now-unused storageGet/storageSet imports in src/content/index.js.
What the diff does not show: eip6963Uuid was a standalone top-level storage
entry, never a field of the versioned autistmask profile, so stateSchema.js and the persisted-field harness need no change and no existing
profile is affected. A stale value from an older install is read by no code
after this change and is not reachable by web pages; nothing depends on the
UUID being stable.
tests/inpageProviderUuid.test.js drives inpage.js against a stub window and
asserts two loads announce different UUIDv4s while one load reuses a single
UUID across re-announcements. The Firefox e2e comment describing the removed
storage read is updated; its length check on the announced UUID still holds.
No README sentence describes the provider UUID, so none was changed.
make check is green locally.
Model: opus-4-8
Closes https://git.eeqj.de/sneak/AutistMask/issues/398.
The EIP-6963 provider UUID was generated once, stored in extension storage,
and announced verbatim to every page on every load and across restarts, so any
site — connected or not — could read a stable cross-site, cross-session
identifier for the install: a supercookie contradicting the README's "no
tracking". EIP-6963 wants a fresh UUIDv4 per announcement.
`src/content/inpage.js` now announces a per-load `crypto.randomUUID()` and
persists nothing. The `eip6963Uuid` storage key and the
`AUTISTMASK_PROVIDER_UUID` content-script message are removed, along with the
now-unused `storageGet`/`storageSet` imports in `src/content/index.js`.
What the diff does not show: `eip6963Uuid` was a standalone top-level storage
entry, never a field of the versioned `autistmask` profile, so
`stateSchema.js` and the persisted-field harness need no change and no existing
profile is affected. A stale value from an older install is read by no code
after this change and is not reachable by web pages; nothing depends on the
UUID being stable.
`tests/inpageProviderUuid.test.js` drives inpage.js against a stub window and
asserts two loads announce different UUIDv4s while one load reuses a single
UUID across re-announcements. The Firefox e2e comment describing the removed
storage read is updated; its length check on the announced UUID still holds.
No README sentence describes the provider UUID, so none was changed.
`make check` is green locally.
Model: opus-4-8
The provider UUID was generated once, stored in extension storage, and
announced verbatim to every page on every load and across restarts, so any
site — connected or not — could read a stable cross-site, cross-session
identifier for the install: a supercookie contradicting the "no tracking"
promise. EIP-6963 wants a fresh UUIDv4 per announcement instead.
inpage.js now announces a per-load crypto.randomUUID() and persists nothing;
the eip6963Uuid storage key and the AUTISTMASK_PROVIDER_UUID content-script
message are removed. That key was a standalone top-level storage entry, never
part of the versioned autistmask profile, so stateSchema.js and the
persisted-field harness are untouched and no existing profile is affected.
A jest test asserts two loads announce different UUIDv4s and that one load
reuses a single UUID across re-announcements.
Model: opus-4-8
clawbot
self-assigned this 2026-09-22 01:36:24 +02:00
clawbot
added this to the 1.0.0 milestone 2026-09-22 01:36:24 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #398.
The EIP-6963 provider UUID was generated once, stored in extension storage,
and announced verbatim to every page on every load and across restarts, so any
site — connected or not — could read a stable cross-site, cross-session
identifier for the install: a supercookie contradicting the README's "no
tracking". EIP-6963 wants a fresh UUIDv4 per announcement.
src/content/inpage.jsnow announces a per-loadcrypto.randomUUID()andpersists nothing. The
eip6963Uuidstorage key and theAUTISTMASK_PROVIDER_UUIDcontent-script message are removed, along with thenow-unused
storageGet/storageSetimports insrc/content/index.js.What the diff does not show:
eip6963Uuidwas a standalone top-level storageentry, never a field of the versioned
autistmaskprofile, sostateSchema.jsand the persisted-field harness need no change and no existingprofile is affected. A stale value from an older install is read by no code
after this change and is not reachable by web pages; nothing depends on the
UUID being stable.
tests/inpageProviderUuid.test.jsdrives inpage.js against a stub window andasserts two loads announce different UUIDv4s while one load reuses a single
UUID across re-announcements. The Firefox e2e comment describing the removed
storage read is updated; its length check on the announced UUID still holds.
No README sentence describes the provider UUID, so none was changed.
make checkis green locally.Model: opus-4-8
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.