- From: Jeffrey Yasskin <notifications@github.com>
- Date: Tue, 07 Oct 2025 13:34:57 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1135/3378620136@github.com>
jyasskin left a comment (w3ctag/design-reviews#1135) > > The explainer mainly focuses on the developer's benefits and how this integrity mechanism will fulfil their needs. This is ok; however, the explainer should also elaborate on `end-use problem` and explicitly mention how the proposal benefits the end-users. This also should be addressed. > > I expect I'll follow the [explainer explainer's boilerplate](https://www.w3.org/TR/explainer-explainer/#security-user-benefit) here, and find somewhere reasonable to paste the helpful text it suggests: "This feature is meant to improve website security, which reduces the frequency of breaches that compromise user data.". > > Do you think additional justification of user benefit is necessary? I think you have a hint at the user benefit, and it just needs to be inverted to be clear, and that spelling it out would help people understand why this is an important addition. Specifically, you have > "Developers, however, often have reasons (performance, privacy, etc) to avoid asking users' agents to take responsibility for these additional requests." Those reasons are actually user benefits, so: > "Users experience performance and privacy benefits if the developer can inline some of those requests instead of asking the user's agent to make them directly to the source server." Focusing on the user benefit here probably doesn't affect the design of this feature, because it's relatively simple, and you're already thinking of the user benefits in doing the design, but we should stay in the habit in case there are details that depend on which user benefits the feature is chasing. (The "protections against injection attacks" are also a user benefit, but there's not as obvious a way to invert the sentence, so the boilerplate is appropriate for that one.) (The TAG should remember to be more eager to spell out the likely rephrasing instead of just saying "end-user problem" and expecting explainer authors to [DWIM](https://en.wikipedia.org/wiki/DWIM).) ---- > Otherwise, it sounds like y'all are directionally satisfied with this proposal? Or are there some details of the approach and/or spec on which you have feedback? I'll let the Breakout C folks confirm, but I don't personally have any concerns, and I don't see any in the [discussion](https://github.com/w3ctag/meetings/blob/gh-pages/2025/telcons/09-29-minutes.md#design-reviews1135-incubation-inline-integrity-history---toreini). -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1135#issuecomment-3378620136 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1135/3378620136@github.com>
Received on Tuesday, 7 October 2025 20:35:01 UTC