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

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

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