From 6f7313fcd764e3072bad8b0316c97edffccb9005 Mon Sep 17 00:00:00 2001 From: Dmitry Verkhoturov Date: Sun, 23 Aug 2026 21:21:41 +0100 Subject: [PATCH] Price the Storage Access route as it really stands: not reachable today The section sold it as a permission prompt on top of the existing flow. A browser denies requestStorageAccess outright when the embedded origin has no recent first-party interaction to grant against, and remark42 never gets one: the reader interacts on the provider's origin, and the callback returns to a document whose first statement is window.close() under ?selfClose. So the real cost is changing the first-party experience, either by having the callback collect a click before closing or by establishing interaction some other way, which is a different order of cost from the other two routes. Also states the grant correctly. It lets the frame's requests carry the cookie; it does not make it script-readable, and the JWT cookie is HttpOnly regardless, which is what the OAuth paragraph above already says. --- .../2026-08-19-frontend-simplification.md | 21 ++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/docs/plans/2026-08-19-frontend-simplification.md b/docs/plans/2026-08-19-frontend-simplification.md index e97a2235..58dfff0e 100644 --- a/docs/plans/2026-08-19-frontend-simplification.md +++ b/docs/plans/2026-08-19-frontend-simplification.md @@ -52,11 +52,22 @@ Two routes could bring OAuth inside the criterion, and both need costing before mandatory. The first is the Storage Access API, which exists for exactly this shape: an embedded frame asks -the browser, with a user gesture, for access to its own unpartitioned first-party cookies, and -Safari and Chrome both implement it. That would let the frame read the cookie the callback already -set, with no backend work at all. It is not free, since it spends a permission prompt and the -grant is revocable and scoped, but it is a real option and this section previously wrote it off by -claiming no frontend change could help. +the browser, on a user gesture, for permission to send its own unpartitioned first-party cookies, +and Safari and Chrome both implement it. Note what the grant is and is not. It lets the frame's +requests carry that cookie; it does not make the cookie script-readable, and the JWT cookie is +`HttpOnly` in any case, which is the same point the OAuth paragraph above makes. + +It is also not available to remark42 as the flow stands, which is the part worth pricing. A browser +denies the request outright when the embedded origin has no recent first-party interaction to +grant against, and remark42 never acquires one: the reader interacts on the provider's origin, and +the callback returns to the remark42 origin at a document whose first statement is `window.close()` +under `?selfClose` in `iframe.ejs`. Nothing happens there that a browser counts as interaction. + +So the cost is not a permission prompt bolted onto the existing flow. Either the callback stops +closing itself and collects a click first, or something else establishes first-party interaction on +the instance's own origin before the frame ever asks. That is a change to the first-party +experience, which is a different order of cost from the other two routes and has to be compared as +one. The second is a server-mediated handoff, where the popup posts a one-time code to its opener and the frame redeems it over XHR. Two shapes exist there and they cost differently. If the redemption