Shared Photos roots can be absent from the recipient timeline #173

New issue

Closed

opened 2026-09-26 13:07:50 +00:00 by kayg · 2 comments

kayg commented

2026-09-26 13:07:50 +00:00

Owner

A post-merge adversarial pass did not show an active shared Photos root in the recipient's timeline within the probe deadline.

Evidence from 2026-09-26:

tests/adversarial/attack.py uploaded a photo dated 2024-06-02 and verified that it appeared in the owner's timeline.
tests/adversarial/attack2.py shared the owner's Photos folder with a second User, opted into Shared/<owner>/Photos, then polled the recipient timeline for 12 seconds.
Every response was HTTP 200 with an empty days list, so the probe reported Photos shared timeline: active shared photo never appeared.
A count-only check after that phase found one recipient-scoped photos_media row, one photos_days row with item count 1, and one photos_groups row for that owner and capture day. The Share had been revoked by then. This suggests the recipient projection existed by the post-check, but does not establish when it became visible.
Several other builds, servers, and adversarial probes were active on the shared host. Delayed refresh is plausible; the run did not isolate the cause. No unauthorized visibility or data loss was observed.

Please reproduce with the shared Photos scenario in tests/adversarial/attack2.py on an otherwise idle server. Check whether root refresh can finish after the Share is removed, or whether timeline root selection hides an already indexed shared day. No behavior change is proposed from this single shared-host run.

A post-merge adversarial pass did not show an active shared Photos root in the recipient's timeline within the probe deadline. Evidence from 2026-09-26: - `tests/adversarial/attack.py` uploaded a photo dated 2024-06-02 and verified that it appeared in the owner's timeline. - `tests/adversarial/attack2.py` shared the owner's `Photos` folder with a second User, opted into `Shared/<owner>/Photos`, then polled the recipient timeline for 12 seconds. - Every response was HTTP 200 with an empty `days` list, so the probe reported `Photos shared timeline: active shared photo never appeared`. - A count-only check after that phase found one recipient-scoped `photos_media` row, one `photos_days` row with item count 1, and one `photos_groups` row for that owner and capture day. The Share had been revoked by then. This suggests the recipient projection existed by the post-check, but does not establish when it became visible. - Several other builds, servers, and adversarial probes were active on the shared host. Delayed refresh is plausible; the run did not isolate the cause. No unauthorized visibility or data loss was observed. Please reproduce with the shared Photos scenario in `tests/adversarial/attack2.py` on an otherwise idle server. Check whether root refresh can finish after the Share is removed, or whether timeline root selection hides an already indexed shared day. No behavior change is proposed from this single shared-host run.

kayg referenced this issue

2026-09-26 13:35:41 +00:00

Overlays: one shared glass surface for menus, dropdowns, popovers, sheets and the composer; more transparent #157

kayg commented

2026-09-26 13:50:35 +00:00

Author

Owner

Additional evidence from the ask-page branch's one post-merge adversarial run on 2026-09-26 (head 32f9d1a9):

tests/adversarial/run.sh ran attack2.py against a real local server.
The recipient timeline poll returned HTTP 200 with {"days":[],"next_before":null} while the shared photo was expected; the probe reported active shared photo never appeared.
The server process remained alive. Several independent builds and adversarial probes were active on the shared host, so this is not a controlled-load replay and does not establish product cause.

Additional evidence from the `ask-page` branch's one post-merge adversarial run on 2026-09-26 (head `32f9d1a9`): - `tests/adversarial/run.sh` ran `attack2.py` against a real local server. - The recipient timeline poll returned HTTP 200 with `{"days":[],"next_before":null}` while the shared photo was expected; the probe reported `active shared photo never appeared`. - The server process remained alive. Several independent builds and adversarial probes were active on the shared host, so this is not a controlled-load replay and does not establish product cause.

kayg referenced this issue

2026-09-26 14:17:40 +00:00

Ask mode: a real Ask page (5th tray mode) with conversation history #150

kayg referenced this issue

2026-09-28 18:46:44 +00:00

Shared Photos timeline stays empty after member opt-in #188

kayg referenced this issue

2026-09-28 18:46:58 +00:00

Shared Photos timeline stays empty after member opt-in #188

kayg commented

2026-09-28 23:46:31 +00:00

Author