[blink-dev] Intent to Deprecate and Remove: Dangling markup in target name

Contact emails jkoka...@google.com Specification https://github.com/whatwg/html/pull/9309/files Summary This change replaces the navigable target name (which is usually set by target attribute) to `_blank`, if it contains a dangling markup (i.e. `\n` and `<`). Which fixes a bypass in the dangl

[blink-dev] Intent to Deprecate and Remove: Same-origin blanket enforcement in CSPEE

Contact emails jkoka...@google.com Explainer None Specification https://github.com/w3c/webappsec-cspee/pull/28/files Summary Removes a special treatment for same-origin iframes from CSP Embedded Enforcement. This aligns the behavior of enforcing CSP Embedded Enforcement for cross-origin if

[blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

Contact emails jkoka...@google.com Specification https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute https://github.com/w3c/svgwg/pull/901/files Summary Assigning a data: URL in SVGUseElement can cause XSS. And this also led to a Trusted Types bypass. Therefore, we plan to depre

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

On Thu, Jan 12, 2023 at 10:44 AM Mike Taylor wrote: > On 1/11/23 6:49 PM, 'Jun Kokatsu' via blink-dev wrote: > > Contact emails > > jkoka...@google.com > > Specification > > https://svgwg.org/svg2-draft/struct.html#UseElementHrefAttribute > >

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

ng >some of these sites we've identified to understand why they're using this >pattern? Is there a tool generating this pattern which we can get updated >before we make the change? I think we'd need a blog post capturing what >we've learned from talki

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

h to make any change at all is >> the hard part. Perhaps we can make replacing the usage easier than the >> overhead of getting an applying an OT token? Still a deprecation trial >> would probably be useful. Enterprise policy, certainly. +Brandon Heenan >> can help advis

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

>>>>> >>>> >>> Added UKM at https://crrev.com/c/4171733. >>> >>>> >>>>> I wonder if this would be a good candidate for a deprecation trial + >>>>>> enterprise policy. That would solve this injection vector fo

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

w >>>>>>> they'd >>>>>>> migrate off it? Having the UKM data will also help in selecting the >>>>>>> sites >>>>>>> that will have the most impact on our users (and hence our UseCounter >>>>>&

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

>>>>>> >>>>>>>> >>>>>>>> Yeah that could be useful. But we've also got some leads already so >>>>>>>> getting more leads may not be critical until we follow up on the ones >>>>>>>> we >>

Re: [blink-dev] Intent to Deprecate and Remove: data: URL in SVGUseElement

t; Thanks for those links, I hadn't appreciated how much discussion >>>> had gone into the tradeoffs already. I agree that if we can convince >>>> ourselves it's not too breaking that this is the best solution. But I see >>>> from the discussi

[blink-dev] Re: Intent to Implement and Ship: Trusted Types fromLiteral

This is awesome! Thank you for working on this Daniel! Jun On Thursday, September 29, 2022 at 7:34:16 AM UTC-7 Daniel Vogelheim wrote: > Contact emailsvoge...@chromium.org > > Specificationhttps://w3c.github.io/trusted-types/dist/spec/#trusted-html > > Summary > > Add a function to each "Trusted

Re: [blink-dev] Intent to Implement and Ship: Trusted Types fromLiteral

On Wednesday, October 5, 2022 at 2:52:59 AM UTC-7 yoav...@chromium.org wrote: > On Thu, Sep 29, 2022 at 4:34 PM 'Daniel Vogelheim' via blink-dev < > blin...@chromium.org> wrote: > >> Contact emailsvoge...@chromium.org >> >> Specificationhttps://w3c.github.io/trusted-types/dist/spec/#trusted-htm

Re: [blink-dev] Intent to Prototype: Capability Delegation

This is spec is probably written with the assumption that Permission Delegation is implemented (or should be implemented) in all browsers. However, Permission Delegation is not a Web Standard, an

[blink-dev] Re: Intent to Ship: Permissions Policy reports for iframes

Sorry, forgot to include how a violation report looks like: ``` { "age": 0, "body": { "allowAttribute": "camera", "disposition": "enforce", "message": "Potential permissions policy violation: camera is not allowed in this document.", "policyId": "camera" }, "type": "potent

[blink-dev] Re: Intent to Ship: Permissions Policy reports for iframes

Explainer Potential Permissions Policy violation report triggers when Permissions Policy (or report-only) is enforced on a document, where iframe has an allow attribute which conflicts with the Permissions Policy specified by the header. Unlike Permissions Policy violations, Potential Permissions

[blink-dev] Re: Intent to Ship: Permissions Policy reports for iframes

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 call

[blink-dev] Intent to Ship: Permissions Policy reports for iframes

Contact emailsjkoka...@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 s

Re: [blink-dev] Re: Intent to Ship: Permissions Policy reports for iframes

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, 2

Re: [blink-dev] Intent to Deprecate and Remove: Remove auto-detection of ISO-2022-JP charset in HTML

Thank you all! I've sent emails to 2 sites which were affected. Regarding deprecation period, I will wait for 2 weeks to hear back from those 2 sites. If I don't get any response, then I plan to just deprecate this feature in M138 since usage is very low. Let me know if y'all think I should inste

Re: [blink-dev] Intent to Deprecate and Remove: Remove auto-detection of ISO-2022-JP charset in HTML

Sounds good! I will work on adding a depreciation period for 2 milestones! Thanks, Jun On Mon, Apr 14, 2025 at 3:20 PM TAMURA, Kent wrote: > "Deprecate" means that the feature still works but using it shows a > deprecation warning in the DevTools console and kicks Reporting API. > > IMO, we s

Re: [blink-dev] Re: Intent to Ship: Permissions Policy reports for iframes

nesday, 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 >> wrote: >> >>> LGTM2. I think this is a useful improvement over permission policy >>> violation reporting >