From 5224c5dfcfb38e95391826c0264f21ec09a1d208 Mon Sep 17 00:00:00 2001 From: Dmitry Verkhoturov Date: Sun, 23 Aug 2026 15:05:32 +0100 Subject: [PATCH] Drop three more banned constructions from the R1 text --- docs/plans/2026-08-19-frontend-simplification.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/plans/2026-08-19-frontend-simplification.md b/docs/plans/2026-08-19-frontend-simplification.md index bad79a59..e97a2235 100644 --- a/docs/plans/2026-08-19-frontend-simplification.md +++ b/docs/plans/2026-08-19-frontend-simplification.md @@ -81,7 +81,7 @@ it is partitioned. #2214's control cookie encodes exactly that: an unpartitioned cookie written by the same script in the same frame has to be dropped, or the case declares itself vacuous. -Documenting it is the remaining gap for the flows named above, and it is two edits rather than one. +Documenting it is the remaining gap for the flows named above, and it is two edits, not one. `site/content/docs/manuals/separate-domain/index.md` covers only `ALLOWED_HOSTS` and `AUTH_SAME_SITE`, so it needs the flag added. `site/content/docs/configuration/parameters/index.md` does document the flag, but its mitigation list still promises `SameSite=Strict` cookies and a @@ -129,7 +129,7 @@ prefix that neither the backend nor the widget's own reader ever asks for, and m frontend now marks its cookies `SameSite=None; Secure; Partitioned` when it detects a third-party context. The server-set cookies are untouched and still carry no `Partitioned`. That is what makes the -upstream work matter rather than what excuses it: `AUTH_SEND_JWT_HEADER` defaults to false, so in +upstream work matter, not what excuses it: `AUTH_SEND_JWT_HEADER` defaults to false, so in the configuration remark42 actually ships nothing writes a partitioned cookie anywhere, and partitioning the server's pair is what would carry email, anonymous and Telegram off-domain without asking operators for a flag that costs them XSS exposure. @@ -148,7 +148,7 @@ Constraints on any frontend design: wrong: it holds the token in memory for one page, and after a reload the browser sends the partitioned cookie the frontend wrote, so both routes stand on the same attribute and differ only in whether the server or the frontend sets it, plus the XSS cost the frontend writer carries. - Neither is a flag flip, and the first cost is upstream rather than here: + Neither is a flag flip, and the first cost falls upstream, not here: `go-pkgz/auth/v2@v2.2.0` cannot emit `Partitioned` at all. Both cookies are hand-built in `Service.Set` with only `HttpOnly`, `Path`, `Domain`, `MaxAge`, `Secure` and `SameSite`, and `AUTH_SAME_SITE` in `cmd/server.go` offers `default`/`none`/`lax`/`strict` with no partitioned