The EIP-6963 provider UUID was generated once, kept in extension storage, and announced to every page on every load and across restarts, so any site, connected or not, could read it as a stable identifier for the install. That contradicts the README's "no tracking".
src/content/inpage.js now generates one crypto.randomUUID() per page load, shared by every announcement in that load, as EIP-6963 asks, and stores 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. The inpage.js listeners for AUTISTMASK_RESPONSE and AUTISTMASK_EVENT drop the leftover name onUuid, which pointed at that removed message.
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. A value left by an older install is read by no code and is not reachable by web pages; nothing depends on the UUID being stable.
tests/inpageProviderUuid.test.js loads inpage.js twice against a stub window and posts each load the same stored UUID the way the old content script did. It asserts that each load announces a single UUIDv4 throughout, that neither load announces the stored one, and that the two loads differ. The Firefox end-to-end comment that described the removed storage read is updated.
No README sentence describes the provider UUID, so none was changed.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/398.
The EIP-6963 provider UUID was generated once, kept in extension storage, and announced to every page on every load and across restarts, so any site, connected or not, could read it as a stable identifier for the install. That contradicts the README's "no tracking".
`src/content/inpage.js` now generates one `crypto.randomUUID()` per page load, shared by every announcement in that load, as EIP-6963 asks, and stores 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`. The `inpage.js` listeners for `AUTISTMASK_RESPONSE` and `AUTISTMASK_EVENT` drop the leftover name `onUuid`, which pointed at that removed message.
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. A value left by an older install is read by no code and is not reachable by web pages; nothing depends on the UUID being stable.
`tests/inpageProviderUuid.test.js` loads `inpage.js` twice against a stub window and posts each load the same stored UUID the way the old content script did. It asserts that each load announces a single UUIDv4 throughout, that neither load announces the stored one, and that the two loads differ. The Firefox end-to-end comment that described the removed storage read is updated.
No README sentence describes the provider UUID, so none was changed.
Model: opus-5-5
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
tests/inpageProviderUuid.test.js would pass on the unfixed code. The stored UUID reached inpage.js only through the content script's AUTISTMASK_PROVIDER_UUID page message. The stub window never delivers that message, so before the fix every stub load also announced a fresh random UUID. As written, "two page loads announce different UUIDs" cannot catch the defect from #398. Acceptable: a test that fails on the old code. One way: give each load the same stored value the way the old content script did, as a page message event, then assert that the two loads still announce different UUIDs and that neither announces the value it was given. Another way: a test that loads src/content/index.js against stub storage and asserts it neither reads nor writes a UUID and posts none to the page. The case title "with nothing delivered" refers to that removed message without saying so; rename it or explain it.
The PR body states that make check is green locally. Statements about checks passing or failing do not belong in the PR body. Remove the sentence.
src/content/inpage.js:207-208 says the UUID "identifies one announcement". tests/inpageProviderUuid.test.js:7 says EIP-6963 "wants a fresh UUIDv4 per announcement", and the commit body and PR body say the same. The code, correctly, uses one UUID for every announcement in a page load, and the test's second case asserts exactly that. EIP-6963 asks for one UUID per provider for the lifetime of the page. Acceptable: those three places describe it as one UUID per page load, shared by every announcement in that load.
Model: opus-5-5
FAIL
1. `tests/inpageProviderUuid.test.js` would pass on the unfixed code. The stored UUID reached `inpage.js` only through the content script's `AUTISTMASK_PROVIDER_UUID` page message. The stub window never delivers that message, so before the fix every stub load also announced a fresh random UUID. As written, "two page loads announce different UUIDs" cannot catch the defect from https://git.eeqj.de/sneak/AutistMask/issues/398. Acceptable: a test that fails on the old code. One way: give each load the same stored value the way the old content script did, as a page `message` event, then assert that the two loads still announce different UUIDs and that neither announces the value it was given. Another way: a test that loads `src/content/index.js` against stub storage and asserts it neither reads nor writes a UUID and posts none to the page. The case title "with nothing delivered" refers to that removed message without saying so; rename it or explain it.
2. The PR body states that `make check` is green locally. Statements about checks passing or failing do not belong in the PR body. Remove the sentence.
3. `src/content/inpage.js:207-208` says the UUID "identifies one announcement". `tests/inpageProviderUuid.test.js:7` says EIP-6963 "wants a fresh UUIDv4 per announcement", and the commit body and PR body say the same. The code, correctly, uses one UUID for every announcement in a page load, and the test's second case asserts exactly that. EIP-6963 asks for one UUID per provider for the lifetime of the page. Acceptable: those three places describe it as one UUID per page load, shared by every announcement in that load.
Model: opus-5-5
Each test load is now posted the same stored UUID as an AUTISTMASK_PROVIDER_UUID page message, the way the old content script delivered it; the tests assert that each load keeps a single UUID, that no load announces the stored one, and that two loads differ. The first case is renamed "a load announces a UUIDv4 without being asked". Mutation run: with the old message listener put back into src/content/inpage.js, the "same UUID within one load" and "two loads differ, neither the stored one" cases failed; the fix was then restored.
The sentence about checks is gone from the PR body.
The inpage.js comment, the test header, the commit body and the PR body now say one UUID per page load, shared by every announcement in that load.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/AutistMask/pulls/412#issuecomment-116385:
1. Each test load is now posted the same stored UUID as an `AUTISTMASK_PROVIDER_UUID` page message, the way the old content script delivered it; the tests assert that each load keeps a single UUID, that no load announces the stored one, and that two loads differ. The first case is renamed "a load announces a UUIDv4 without being asked". Mutation run: with the old message listener put back into `src/content/inpage.js`, the "same UUID within one load" and "two loads differ, neither the stored one" cases failed; the fix was then restored.
2. The sentence about checks is gone from the PR body.
3. The `inpage.js` comment, the test header, the commit body and the PR body now say one UUID per page load, shared by every announcement in that load.
Model: opus-5-5
tests/inpageProviderUuid.test.js:99: the case "a load announces a UUIDv4 without being asked" does not check that. The helper always dispatches eip6963:requestProvider before the case reads anything, and the case only checks that the first announced UUID is a UUIDv4, so it still passes when inpage.js no longer announces at load. Acceptable: keep what was announced before the request is dispatched and assert on that, or name the case for what it checks (for example "a load announces a UUIDv4").
src/content/inpage.js:48 and :63: the listeners for AUTISTMASK_RESPONSE and AUTISTMASK_EVENT are both still named onUuid, left over from the commit that added the stored-UUID listener this change removes. With that message gone, the name sends a reader looking for a UUID message that no longer exists. Acceptable: name each for the message it handles, or leave them unnamed as they were before.
Model: opus-5-5
FAIL
1. `tests/inpageProviderUuid.test.js:99`: the case "a load announces a UUIDv4 without being asked" does not check that. The helper always dispatches `eip6963:requestProvider` before the case reads anything, and the case only checks that the first announced UUID is a UUIDv4, so it still passes when `inpage.js` no longer announces at load. Acceptable: keep what was announced before the request is dispatched and assert on that, or name the case for what it checks (for example "a load announces a UUIDv4").
2. `src/content/inpage.js:48` and `:63`: the listeners for `AUTISTMASK_RESPONSE` and `AUTISTMASK_EVENT` are both still named `onUuid`, left over from the commit that added the stored-UUID listener this change removes. With that message gone, the name sends a reader looking for a UUID message that no longer exists. Acceptable: name each for the message it handles, or leave them unnamed as they were before.
Model: opus-5-5
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
The case is renamed "a load announces a UUIDv4", which is what it checks.
The AUTISTMASK_RESPONSE and AUTISTMASK_EVENT listeners in src/content/inpage.js are unnamed arrow functions again, as they were before the name onUuid was added.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/AutistMask/pulls/412#issuecomment-116704:
1. The case is renamed "a load announces a UUIDv4", which is what it checks.
2. The `AUTISTMASK_RESPONSE` and `AUTISTMASK_EVENT` listeners in `src/content/inpage.js` are unnamed arrow functions again, as they were before the name `onUuid` was added.
Model: opus-5-5
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, kept in extension storage, and announced to every page on every load and across restarts, so any site, connected or not, could read it as a stable identifier for the install. That contradicts the README's "no tracking".
src/content/inpage.jsnow generates onecrypto.randomUUID()per page load, shared by every announcement in that load, as EIP-6963 asks, and stores nothing. Theeip6963Uuidstorage key and theAUTISTMASK_PROVIDER_UUIDcontent-script message are removed, along with the now-unusedstorageGet/storageSetimports insrc/content/index.js. Theinpage.jslisteners forAUTISTMASK_RESPONSEandAUTISTMASK_EVENTdrop the leftover nameonUuid, which pointed at that removed message.What the diff does not show:
eip6963Uuidwas a standalone top-level storage entry, never a field of the versionedautistmaskprofile, sostateSchema.jsand the persisted-field harness need no change. A value left by an older install is read by no code and is not reachable by web pages; nothing depends on the UUID being stable.tests/inpageProviderUuid.test.jsloadsinpage.jstwice against a stub window and posts each load the same stored UUID the way the old content script did. It asserts that each load announces a single UUIDv4 throughout, that neither load announces the stored one, and that the two loads differ. The Firefox end-to-end comment that described the removed storage read is updated.No README sentence describes the provider UUID, so none was changed.
Model: opus-5-5
FAIL
tests/inpageProviderUuid.test.jswould pass on the unfixed code. The stored UUID reachedinpage.jsonly through the content script'sAUTISTMASK_PROVIDER_UUIDpage message. The stub window never delivers that message, so before the fix every stub load also announced a fresh random UUID. As written, "two page loads announce different UUIDs" cannot catch the defect from #398. Acceptable: a test that fails on the old code. One way: give each load the same stored value the way the old content script did, as a pagemessageevent, then assert that the two loads still announce different UUIDs and that neither announces the value it was given. Another way: a test that loadssrc/content/index.jsagainst stub storage and asserts it neither reads nor writes a UUID and posts none to the page. The case title "with nothing delivered" refers to that removed message without saying so; rename it or explain it.The PR body states that
make checkis green locally. Statements about checks passing or failing do not belong in the PR body. Remove the sentence.src/content/inpage.js:207-208says the UUID "identifies one announcement".tests/inpageProviderUuid.test.js:7says EIP-6963 "wants a fresh UUIDv4 per announcement", and the commit body and PR body say the same. The code, correctly, uses one UUID for every announcement in a page load, and the test's second case asserts exactly that. EIP-6963 asks for one UUID per provider for the lifetime of the page. Acceptable: those three places describe it as one UUID per page load, shared by every announcement in that load.Model: opus-5-5
60d2b24cd1to810a3c17fdRework for #412 (comment):
AUTISTMASK_PROVIDER_UUIDpage message, the way the old content script delivered it; the tests assert that each load keeps a single UUID, that no load announces the stored one, and that two loads differ. The first case is renamed "a load announces a UUIDv4 without being asked". Mutation run: with the old message listener put back intosrc/content/inpage.js, the "same UUID within one load" and "two loads differ, neither the stored one" cases failed; the fix was then restored.inpage.jscomment, the test header, the commit body and the PR body now say one UUID per page load, shared by every announcement in that load.Model: opus-5-5
FAIL
tests/inpageProviderUuid.test.js:99: the case "a load announces a UUIDv4 without being asked" does not check that. The helper always dispatcheseip6963:requestProviderbefore the case reads anything, and the case only checks that the first announced UUID is a UUIDv4, so it still passes wheninpage.jsno longer announces at load. Acceptable: keep what was announced before the request is dispatched and assert on that, or name the case for what it checks (for example "a load announces a UUIDv4").src/content/inpage.js:48and:63: the listeners forAUTISTMASK_RESPONSEandAUTISTMASK_EVENTare both still namedonUuid, left over from the commit that added the stored-UUID listener this change removes. With that message gone, the name sends a reader looking for a UUID message that no longer exists. Acceptable: name each for the message it handles, or leave them unnamed as they were before.Model: opus-5-5
810a3c17fdto87698beacbRework for #412 (comment):
AUTISTMASK_RESPONSEandAUTISTMASK_EVENTlisteners insrc/content/inpage.jsare unnamed arrow functions again, as they were before the nameonUuidwas added.Model: opus-5-5
PASS
Model: opus-5-5