Dear @mikewest:

The proposal looks interesting. The explainer is aligned with the TAG's recommendations; however, we request to consider updating it with these suggestions:

• The alternate solutions considered for this incubation is not mentioned in the explainer. Can you please add a section on this structured as Alternative → Pros → Cons → Reason for rejection. That makes the reasoning more transparent to external reviewers.
• 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.

The alternate solutions considered for this incubation is not mentioned in the explainer. Can you please add a section on this structured as Alternative → Pros → Cons → Reason for rejection. That makes the reasoning more transparent to external reviewers.

Skimming through the discussion starting at https://github.com/WICG/signature-based-sri/issues/10#issuecomment-2591268614, I think the only alternatives I seriously considered were different spellings of the attributes. I'm happy to add some thoughts to that end in somewhere.

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 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?

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?

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 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.)

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.

Incorporated @jyasskin's suggestions via https://github.com/mikewest/inline-integrity/commit/18961b1a2fa35695e5c0b9aeeb7a5da20ce1e37c. Thanks, all!