Popup and privacy policy: \"nothing leaves this browser until you send it\" while /captures/known has already gone #18

New issue

Closed

opened 2026-10-01 10:47:16 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:47:16 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo-chromium at 7998de372, comparing what the popup says with the requests it makes.

Related to #5.

As soon as the page is read, before any Send, the popup asks the person's Postulo which of the page's postings it already holds, sending each one's address, title and company to POST /api/v1/captures/known (up to forty on a results page). The sentences around it say nothing leaves the browser until the person sends it, including the one shown above the very form that is waiting on that answer. PRIVACY.md lists the request in its table and denies it in the paragraphs either side.

Where:
- src/popup.js:108 (askKnown([page.read]), before show("edit")) and src/popup.js:266 (askKnown(listed.map((posting) => posting.data)) for a results page); the request is known() in src/lib/api.js, made only when an instance is set up, the testing switch is off and the host permission is granted (src/popup.js:189-202).
- src/_locales/en/messages.json:31 captureHint, also in src/popup.html:23: "The page is read here, in your browser. Nothing is sent until you say so."
- src/_locales/en/messages.json:227 reviewHint and :251 nothingRead: "…nothing leaves this browser until you send it."
- PRIVACY.md:6-8: "it goes there only when you press Send", and PRIVACY.md:49-51: "Nothing is ever sent that you did not press Send on", against the table row at PRIVACY.md:47 that describes POST /api/v1/captures/known.
- The same sentences in the other 39 catalogues.
What happens: a person reads "nothing leaves this browser until you send it" above the form, decides not to send the posting, and closes the popup; its address, title and company have already reached their Postulo. The request goes only to the person's own instance, which stores nothing from it, but the in-product promise and the policy's opening paragraph are untrue as written.
Why it matters: these sentences are the extension's privacy promise in the place it is read, and the policy is what both stores review; a statement that the extension's own behaviour contradicts undermines both, and the policy contradicts itself.
Fix: reword captureHint, reviewHint and nothingRead in all 40 catalogues to say that the posting's address, title and company are checked against your Postulo, and the page and your corrections go only when you send them; say the same in PRIVACY.md:6-8 and :49-51, keeping the table row. If the promise is to be kept instead, ask /captures/known only on an explicit gesture or behind a setting.

Done when

No catalogue and no paragraph of PRIVACY.md says that nothing is sent before Send; test/i18n.test.mjs still passes with the reworded keys in all 40 locales.

Found on 2026-09-29 in a read-only review of postulo-chromium at 7998de372, comparing what the popup says with the requests it makes. Related to #5. As soon as the page is read, before any *Send*, the popup asks the person's Postulo which of the page's postings it already holds, sending each one's address, title and company to `POST /api/v1/captures/known` (up to forty on a results page). The sentences around it say nothing leaves the browser until the person sends it, including the one shown above the very form that is waiting on that answer. `PRIVACY.md` lists the request in its table and denies it in the paragraphs either side. - **Where:** - `src/popup.js:108` (`askKnown([page.read])`, before `show("edit")`) and `src/popup.js:266` (`askKnown(listed.map((posting) => posting.data))` for a results page); the request is `known()` in `src/lib/api.js`, made only when an instance is set up, the testing switch is off and the host permission is granted (`src/popup.js:189-202`). - `src/_locales/en/messages.json:31` `captureHint`, also in `src/popup.html:23`: "The page is read here, in your browser. Nothing is sent until you say so." - `src/_locales/en/messages.json:227` `reviewHint` and `:251` `nothingRead`: "…nothing leaves this browser until you send it." - `PRIVACY.md:6-8`: "it goes there only when you press *Send*", and `PRIVACY.md:49-51`: "Nothing is ever sent that you did not press *Send* on", against the table row at `PRIVACY.md:47` that describes `POST /api/v1/captures/known`. - The same sentences in the other 39 catalogues. - **What happens:** a person reads "nothing leaves this browser until you send it" above the form, decides not to send the posting, and closes the popup; its address, title and company have already reached their Postulo. The request goes only to the person's own instance, which stores nothing from it, but the in-product promise and the policy's opening paragraph are untrue as written. - **Why it matters:** these sentences are the extension's privacy promise in the place it is read, and the policy is what both stores review; a statement that the extension's own behaviour contradicts undermines both, and the policy contradicts itself. - **Fix:** reword `captureHint`, `reviewHint` and `nothingRead` in all 40 catalogues to say that the posting's address, title and company are checked against your Postulo, and the page and your corrections go only when you send them; say the same in `PRIVACY.md:6-8` and `:49-51`, keeping the table row. If the promise is to be kept instead, ask `/captures/known` only on an explicit gesture or behind a setting. ## Done when - No catalogue and no paragraph of `PRIVACY.md` says that nothing is sent before *Send*; `test/i18n.test.mjs` still passes with the reworded keys in all 40 locales.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:16 +00:00

tiagoagueda added the

documentation

label

2026-10-01 10:47:16 +00:00

tiagoagueda referenced this issue from a commit

2026-11-11 22:46:27 +00:00

Say that /captures/known is asked before Send, in the popup and the policy

tiagoagueda referenced this issue from a pull request that will close it,

2026-11-11 22:46:28 +00:00

Fix the extension's four 0.6.0 issues #58