Resolve two-User matrix expectation for live Share Item reads

kayg commented

2026-09-29 15:05:09 +00:00

Owner

The #435 live two-User campaign finished its Derived Search and Photos checks and MCP probe, but the inherited generic #331 matrix exits 1 on a known authorized Share. The fixture gives D a live Share of A's private-<suffix>.txt; verify_derived_isolation() asserts that D can search that Share. run_matrix() then replays the same A Files Item ID as D and applies its generic private-object expectation, flagging D's HTTP 200 as a leak and different response size from a missing ID. B, C, and anonymous did not appear in the findings.

The owner rule forbids changing an existing test expectation unless the issue explicitly changes the behavior, so #435 left this assertion unchanged. Review the intended permission for a recipient reading an Item through a live Share. If that permission is correct, make the matrix classify this one authorized Share edge separately from private A IDs, retaining the B/C/anonymous negative controls. Add a regression test for the recipient and revoked Share cases. If the permission is wrong, fix the Files authorization path instead. The decision belongs to the orchestrator/owner.

The #435 live two-User campaign finished its Derived Search and Photos checks and MCP probe, but the inherited generic #331 matrix exits 1 on a known authorized Share. The fixture gives D a live Share of A's `private-<suffix>.txt`; `verify_derived_isolation()` asserts that D can search that Share. `run_matrix()` then replays the same A Files Item ID as D and applies its generic private-object expectation, flagging D's HTTP 200 as a leak and different response size from a missing ID. B, C, and anonymous did not appear in the findings. The owner rule forbids changing an existing test expectation unless the issue explicitly changes the behavior, so #435 left this assertion unchanged. Review the intended permission for a recipient reading an Item through a live Share. If that permission is correct, make the matrix classify this one authorized Share edge separately from private A IDs, retaining the B/C/anonymous negative controls. Add a regression test for the recipient and revoked Share cases. If the permission is wrong, fix the Files authorization path instead. The decision belongs to the orchestrator/owner.

kayg referenced this issue

2026-09-29 15:05:25 +00:00

ISOLATION: physically separate per-User derived stores (vectors) + full cross-user inventory #435

kayg referenced this issue

2026-09-29 15:12:19 +00:00

ISOLATION: physically separate per-User derived stores (vectors) + full cross-user inventory #435

kayg commented

2026-09-29 15:14:07 +00:00

Author

Owner

Orchestrator decision: a Share recipient with a live Share of an item may read that item; that is the Share's purpose. The probe's expectation is wrong for the shared item. Fix the probe: D reading A's item with a live Share is allowed (200); after the Share is revoked, or for any unshared A item, D gets 404 with no timing or size oracle. Keep both cases in the matrix. Owner: job iso-435.

Orchestrator decision: a Share recipient with a **live** Share of an item may read that item; that is the Share's purpose. The probe's expectation is wrong for the shared item. Fix the probe: D reading A's item **with** a live Share is allowed (200); after the Share is revoked, or for any unshared A item, D gets 404 with no timing or size oracle. Keep both cases in the matrix. Owner: job iso-435.

kayg referenced this issue

2026-09-29 15:22:15 +00:00

ISOLATION: physically separate per-User derived stores (vectors) + full cross-user inventory #435

kayg referenced this issue from a commit

2026-09-29 15:37:19 +00:00

test(isolation): classify live Share Item reads by grant

kayg referenced this issue from a commit

2026-09-29 16:27:22 +00:00

test(isolation): require 404 for unshared and revoked Share paths

kayg referenced this issue

2026-09-29 17:09:06 +00:00

ISOLATION: physically separate per-User derived stores (vectors) + full cross-user inventory #435

kayg referenced this issue

2026-09-30 01:29:37 +00:00

SECURITY (merge-blocker class): cross-user matrix halts on dev, 20 {id} routes unclassified #472

kayg referenced this issue

2026-09-30 01:34:26 +00:00

SECURITY (merge-blocker class): cross-user matrix halts on dev, 20 {id} routes unclassified #472

kayg referenced this issue

2026-09-30 02:02:05 +00:00

SECURITY (merge-blocker class): cross-user matrix halts on dev, 20 {id} routes unclassified #472

kayg referenced this issue from a commit

2026-09-30 02:02:43 +00:00

docs: record the #472 real-server matrix result and where the #461 assertion lives

kayg referenced this issue

2026-09-30 03:49:23 +00:00

ISOLATION: physically separate per-User derived stores (vectors) + full cross-user inventory #435

kayg commented

2026-09-30 05:06:49 +00:00

Author

Owner

Owner decision (2026-09-30): items shared with a User appear in that User's search, for both kinds of share. The current matrix expectation (D can search A's Item shared with D) is correct, so keep it and classify it as authorised. Separately, the owner wants the share kinds renamed; see the new Shares naming issue.

**Owner decision (2026-09-30):** items shared with a User **appear in that User's search**, for both kinds of share. The current matrix expectation (D can search A's Item shared with D) is correct, so keep it and classify it as authorised. Separately, the owner wants the share kinds renamed; see the new Shares naming issue.

kayg referenced this issue

2026-09-30 05:06:50 +00:00

SHARES: rename to Share (view) and Collaborate (edit); drop 'live' (grill) #479

kayg referenced this issue

2026-10-01 05:11:28 +00:00

SHARES: rename to Share (view) and Collaborate (edit); drop 'live' (grill) #479

kayg commented

2026-10-01 05:11:29 +00:00

Author

Owner

Owner decisions, grill round 1 (2026-10-01): #461: a recipient of a Share can read the Item through every surface (web, API, MCP, CalDAV, search); fix the test to assert that non-recipients are denied. Public links are view only. A Share can switch between Share and Collaborate in place (recipients notified). Public links expire after 30 days by default (changeable); User shares do not expire unless set. Collaborate covers Notes (live co-editing), Calendar, Folders (deletes go to the owner's Trash), Money (shared household budget) and Tasks; every edit is attributed and undoable. Recipients see shared items in place in each Tab's sidebar ("important stuff first, then filters"). New: a share option that doubles as an invite link: a person without an account opens it, creates an account, and lands back on the shared item (details in grill round 2).

**Owner decisions, grill round 1 (2026-10-01):** #461: a recipient of a Share can read the Item through every surface (web, API, MCP, CalDAV, search); fix the test to assert that non-recipients are denied. Public links are **view only**. A Share can switch between Share and Collaborate in place (recipients notified). Public links expire after 30 days by default (changeable); User shares do not expire unless set. Collaborate covers Notes (live co-editing), Calendar, Folders (deletes go to the owner's Trash), Money (shared household budget) and Tasks; every edit is attributed and undoable. Recipients see shared items **in place** in each Tab's sidebar ("important stuff first, then filters"). **New:** a share option that doubles as an **invite link**: a person without an account opens it, creates an account, and lands back on the shared item (details in grill round 2).

kayg referenced this issue

2026-10-02 13:09:18 +00:00

BLOCKER: bind public download authorization to the opened item and current grant #755

kayg referenced this issue

2026-10-02 13:09:20 +00:00

BLOCKER: bound public link password work outside async request workers #756

kayg referenced this issue

2026-10-03 12:51:31 +00:00

Issue hygiene sweep 2026-10-03 #1008

Rows
Columns

Resolve two-User matrix expectation for live Share Item reads #461