Great! I'll work on shipping then! Thanks,
Jun On Wed, Mar 19, 2025 at 1:19 PM Mike Taylor <miketa...@chromium.org> wrote: > You have 3 LGTMs, so there is no need to delay shipping. Please proceed. > > thanks, > Mike > On 3/19/25 4:11 PM, Jun Kokatsu wrote: > > Hi All, > > I've file a TAG review > <https://github.com/w3ctag/design-reviews/issues/1050> more than a month > ago, but I'm yet to get a response. > Should I wait until the TAG review is complete? Or is filing enough for > shipping this feature? > > Thanks, > > Jun > > On Wednesday, January 29, 2025 at 8:08:15 AM UTC-8 Chris Harrelson wrote: > >> LGTM3 >> >> On Wed, Jan 29, 2025 at 7:53 AM Vladimir Levin <vmp...@chromium.org> >> wrote: >> >>> LGTM2. I think this is a useful improvement over permission policy >>> violation reporting >>> >>> On Tuesday, January 28, 2025 at 10:15:57 AM UTC-5 Mike Taylor wrote: >>> >> LGTM1 >>>> On 1/27/25 6:27 PM, 'Jun Kokatsu' via blink-dev wrote: >>>> >>>> On Sunday, January 26, 2025 at 6:45:39 PM UTC-8 Domenic Denicola wrote: >>>> >>>> >>>> >>>> On Friday, January 17, 2025 at 7:42:03 AM UTC+9 Jun Kokatsu wrote: >>>> >>>> Contact emailsjkok...@google.com >>>> >>>> Specificationhttps://github.com/w3c/webappsec-permissions-policy/ >>>> pull/546 >>>> >>>> >>>> >>>> Summary >>>> >>>> Introduces a new violation type called "Potential Permissions Policy >>>> violation", which will only look at Permissions Policy (including >>>> report-only policy) and the allow attribute set in iframes to detect the >>>> conflict between Permissions Policy enforced vs permissions propagated to >>>> iframes. >>>> >>>> Motivation >>>> Permissions Policy violation reports for cross-origin iframes are only >>>> sent to the iframe's reporting endpoint and not to the embedder's reporting >>>> endpoint, because of the concern that it might leak sensitive information >>>> about a cross-origin iframe. However, this makes it difficult for sites to >>>> enforce Permissions Policy because it can't learn about breakages in >>>> cross-origin iframes. This feature introduces a new violation type called >>>> "Potential Permissions Policy violation", which will only look at existing >>>> Permissions Policy (including report-only policy) and the allow attribute >>>> set in iframes to detect the conflict between Permissions Policy enforced >>>> vs permissions being propagated to iframes. Since both Permissions Policy >>>> and allow attributes are set by the embedder, this feature does not leak >>>> any new information to the embedder. However, potential Permissions Policy >>>> violations will be sent when an iframe is loaded, and not when the iframe >>>> uses the prohibited feature, which is different from the normal Permissions >>>> Policy violations which fires upon a feature usage (hence the name >>>> "potential"). >>>> >>>> Blink componentBlink>PermissionsPolicy >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPermissionsPolicy%22> >>>> >>>> TAG reviewNone >>>> >>>> TAG review statusNot applicable >>>> >>>> >>>> Can you say more why you believe TAG review is not applicable for this >>>> feature? I cannot figure out which exception, if any, it falls under from >>>> this >>>> list >>>> <https://www.chromium.org/blink/launching-features/wide-review/#exceptions> >>>> . >>>> >>>> >>>> Sorry, I think I missed this step. I will submit for a TAG review, and >>>> come back to this thread once the TAG review is approved. >>>> >>>> FWIW, I don't think we should block on TAG review resolution - but it's >>>> useful to file an issue, in case someone is keeping track of APIs that do >>>> reporting, or have report-only modes. >>>> >>>> >>>> >>>> >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> None >>>> >>>> >>>> *Gecko*: No signal >>>> <https://github.com/mozilla/standards-positions/issues/1164> >>>> >>>> *WebKit*: No signal >>>> <https://github.com/WebKit/standards-positions/issues/448> >>>> >>>> *Web developers*: No signals >>>> >>>> >>>> Why are we proposing to ship this, if it is not interesting to any web >>>> developers, and has support from no other browsers? >>>> >>>> >>>> We'd like to mitigate Permission Delegation of powerful permissions to >>>> unintentional sites (e.g. HTML injection in Bing resulted in camera >>>> access in Edge >>>> <https://speakerdeck.com/shhnjk/piloting-edge-copilot?slide=27>) in >>>> Google applications. >>>> So we do have internal developer support. But I'm not sure if there is >>>> external developer support. >>>> >>>> >>>> >>>> >>>> *Other signals*: >>>> >>>> Security >>>> >>>> Potential Permissions Policy violation reports should not include any >>>> new information about cross-origin iframes >>>> >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> None >>>> >>>> >>>> Debuggability >>>> >>>> None >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?No >>>> >>>> >>>> Which platform will it not be supported on? >>>> >>>> >>>> This had to be Yes. I've fixed it in Chrome status. >>>> >>>> >>>> >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?https://github.com/web-platform-tests/wpt/pull/49978 >>>> >>>> >>>> >>>> Flag name on about://flagsNone >>>> >>>> Finch feature namePotentialPermissionsPolicyReporting >>>> >>>> Requires code in //chrome?False >>>> >>>> Tracking bughttps://issues.chromium.org/issues/40941424 >>>> >>>> Estimated milestonesShipping on desktop134 >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> None >>>> >>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >>>> feature/5154241037205504?gate=5069369228656640 >>>> >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+...@chromium.org. >>>> >>>> >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/453d70c8-b1b4-4607-8a76-ff564f00b231n%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/453d70c8-b1b4-4607-8a76-ff564f00b231n%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>> >> You received this message because you are subscribed to the Google Groups >>> "blink-dev" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send an >>> email to blink-dev+...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f98e6ec-8ea6-4982-ad4c-44d88c48ec3dn%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f98e6ec-8ea6-4982-ad4c-44d88c48ec3dn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6EFv9rmLtR3nHhe5e3z6obmG7yUiaAH%2BHfV0KW%3DyhzSQ%40mail.gmail.com.
