- From: Chris Thompson <notifications@github.com>
- Date: Thu, 10 Jul 2025 15:22:32 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1116/3059319328@github.com>
christhompson left a comment (w3ctag/design-reviews#1116) We agree that a permission prompt is somewhat non-ideal, but we feel that *any* speed bump and user notice here is better than what the status quo has been for a long time now. Longer term I hope we are able to move towards something more like a Discovery API that can use chooser patterns (although this may need us to solve the local HTTPS problem first). There may also be some medium term opportunities for improving the permission, how we apply it, and how we might be able to iterate to improve user understanding. > However, we do think that a permission prompt is not a great solution. Or rather, it's almost exactly the wrong thing to be asking people to decide. These sorts of questions only work if consent is "freely given, specific, and informed", where this basically fails on all three tests. This is not something that people are naturally able to understand very well. The permission is also necessarily very broad. And the alternative is generally that the site breaks, so it cannot reasonably claim to be "freely given" either. In the case of things like the localmess tracking vector, our hope is that this is (1) substantially unexpected by end users, and (2) makes such behavior extremely visible and thus disincentivized. We already saw evidence that such tracking vectors moved _away_ from prior techniques (such as direct fetch() requests) towards less visible techniques (i.e., WebRTC which doesn't show up directly in Chrome's DevTools' Network tab). As with any permission-gated powerful capability, we hope that sites that have positive use cases adequately explain to their users what they are doing and _why_ they need access to this capability. In the absence of such explanations, we hope that the permission prompt is sufficient speed bump to prevent drive-by exploitation on the web. > Not ALL the TAG agree with this viewpoint; some of us believe that it might be possible to construct a prompt that makes it possible to obtain meaningful consent. Shipping the feature might help answer that. This is also our hope. We are already seeing Firefox take a slightly different approach to their permission prompts (separate prompts for "connect to loopback" and "connect to local network") -- this natural variation in implementations combined with seeing how this works in the real world (e.g., monitoring grant/deny rates for our permissions, among other metrics) will hopefully help guide future improvements. To the clerical points: * We are in the process of converting the spec draft to bikeshed in [WICG/local-network-access](https://github.com/WICG/local-network-access) * Yep the standards position requests were filed after we filed the TAG review but we didn't have a chance to come back and link them here yet * We discussed this at webappsec back in February https://github.com/w3c/webappsec/blob/main/meetings/2025/2025-02-19-minutes.md -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1116#issuecomment-3059319328 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1116/3059319328@github.com>
Received on Thursday, 10 July 2025 22:22:36 UTC