Skip to content

v0.1.7 — a delete path no longer requests permissions

Latest

Choose a tag to compare

@antrixy antrixy released this 07 Sep 22:25
· 175 commits to main since this release
52a2eaf

Closes FINDING-028 and FINDING-024. They were one line, not two.

diffDomainGrants() computed its two sides from different questions: toRevoke
read profile MEMBERSHIP, toRequest read GRANT STATE alone. So toRequest was
every ungranted domain in the resulting set, with no reference to what the
user had just done. A delete cannot add a domain, so it had nothing new to
want, and requested anyway — one approval on a delete confirmation granted
four domains the user never approved. The same filter re-requested the whole
legacy set on any edit, silently, because a previously-approved origin
re-grants without a dialog.

const toRequest = [...after].filter((d) => !before.has(d) && !granted.has(d));

Delete never requests. Save requests only newly-typed domains. Import
requests only domains the previous set did not reference. Recovery for a
denied or legacy domain is the chip, which is what the migration notice
already told users to use.

Also FINDING-032: the selftest's source-text scans could not tell a use from
a mention. Deleting FINDING-022's fix while a comment named it kept the suite
green — a false pass on the tripwire built to stop exactly that regression.

No new capability. No new permission. The extension still has no webRequest.

Selftest 273 -> 281, three mutation passes, browser sitting G with
predictions pre-registered before Chrome opened.