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

['Jun Kokatsu' via blink-dev]

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 iframes and same-origin iframes.


Blink component

Blink>SecurityFeature>ContentSecurityPolicy 


Motivation

The same-origin blanket enforcement logic specific to same-origin iframes 
exposes a new way to block certain resources from loading in the iframe. 
This allowed an attack which was not possible before (example 
).
 



Additionally, this caused a bug 
 where CSP nonce value 
enforced by CSPEE from a top frame had to exactly match nonce value served 
in grand-child frame, if the top frame and child frame are cross-origin, 
but child frame and grand-child frame are same-origin. 


Given this part of blanket enforcement is rarely used (~0.17% 
), let's 
remove this logic.


Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None


Gecko: Positive 

WebKit: No signal 

Web developers: No signals

Other signals:

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


Is this feature fully tested by web-platform-tests 

?

Yes 

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1263288

Estimated milestones

M120


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5098158594195456

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a008e0f7-d1f1-4451-8d2a-6e0757913470n%40chromium.org.

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

['Jun Kokatsu' via blink-dev]

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 dangling markup injection mitigation.


Blink component

Blink>SecurityFeature


Motivation

Blink has shipped a mitigation for dangling markup injection
 attack while back.
However, it was discovered that the mitigation can be bypassed

through target name. Navigations with such target names are low

(~0.07%). Therefore, this change removes the limitation discovered in
the previous mitigation.


Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None


Gecko: Positive 

WebKit: Shipped/Shipping 

Web developers: No signals

Other signals:

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


Is this feature fully tested by web-platform-tests

?

Yes 

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1421440

Estimated milestones

119


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5073969773805568

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF4CR50EbS%3DMrYxMa5PcyiYPFg%2B4X2e6F5S0kzcxJLygew%40mail.gmail.com.

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

['Jun Kokatsu' via blink-dev]

>>> The XSS risk here is mostly about script execution triggered by
>>>>>>>> this pattern. This includes (but not limited to) inline event handlers 
>>>>>>>> and
>>>>>>>> links with Javascript URLs.
>>>>>>>>
>>>>>>>
>>>>>>> So if we find it's too breaking to disallow this pattern completely,
>>>>>>> could we instead just disable script execution from within the context 
>>>>>>> of
>>>>>>> documents resulting from data: URLs in SVGUseAttributes?
>>>>>>>
>>>>>>
>>>>>> Is that solution for Trusted Types or XSS through SVGUseElement in
>>>>>> general?
>>>>>>
>>>>>
>>>> I was thinking for SVGUseElement in general.
>>>>
>>>>
>>>>> If it is for Trusted Types, it does solve the issue in Chromium for
>>>>>> short term, but we want other rendering engines to implement Trusted 
>>>>>> Types
>>>>>> as well. Does that mean we spec this in Trusted Types that inline event
>>>>>> handlers from SVGUseElement will be disallowed when enforcing Trusted
>>>>>> Types?
>>>>>> One thing I'm not sure about this approach is that each rendering
>>>>>> engine has differences in supported features inside SVGUseElement.
>>>>>>
>>>>>
>>>> Oh yeah I certainly wouldn't suggest we do anything chromium-specific
>>>> here. Just that if we decide the web compat challenge of deprecating all
>>>> data urls is too high, then we could probably get other vendors on board
>>>> with something more modest and get that fully spec'd and tested.
>>>>
>>>> For example, if the 
>>>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject>
>>>>>> is supported, then iframes inside foreignObject can have srcdoc, and it 
>>>>>> can
>>>>>> contain script tags which are considered "stored" XSS (because the 
>>>>>> payload
>>>>>> never goes through DOM APIs), and therefore Trusted Types could be 
>>>>>> bypassed
>>>>>> (i.e. script tags are not inline event handlers). But maybe the current
>>>>>> script element restriction
>>>>>> <https://www.w3.org/TR/SVG2/struct.html#UseShadowTree:~:text=Within%20a%20use%2Delement%20shadow%20tree%2C%20%E2%80%98script%E2%80%99%20elements%20are%20inert%20(do%20not%20execute)%3B>
>>>>>> on the use element is enough to apply in child frames too?
>>>>>>
>>>>>> If it is for XSS, then as I mentioned, SVG link
>>>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/a> with
>>>>>> Javascript: URL can still trigger XSS (because the script execution is a
>>>>>> result of navigation, which can happen in the top frame or iframes by
>>>>>> target attribute).
>>>>>>
>>>>>> Long story short, we did consider disabling scripts, but people's
>>>>>> consensus (1
>>>>>> <https://github.com/mozilla/standards-positions/issues/718>, 2
>>>>>> <https://github.com/WebKit/standards-positions/issues/108>, 3
>>>>>> <https://github.com/w3c/trusted-types/issues/357#issuecomment-1049761361>
>>>>>> , 4
>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c10>,
>>>>>> 5 <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c11>)
>>>>>> has been that it's just better to deprecate data: URLs in SVGUseElement.
>>>>>>
>>>>>
>>>> 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 discussion that the consensus was based on the assumption that we
>>>> had already decided the web compat risk was sufficiently low. I'd certainly
>>>> prefer not to re-open the standards discussion as this solution seems the
>>>> safest, simplest and most coherent for the platform, but it's good to know
>>>> what our fallback options are so that we can keep the cost/benefit
>>>> tradeoffs in mind

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

['Jun Kokatsu' via blink-dev]

s for Trusted Types, it does solve the issue in Chromium for short
> term, but we want other rendering engines to implement Trusted Types as
> well. Does that mean we spec this in Trusted Types that inline event
> handlers from SVGUseElement will be disallowed when enforcing Trusted
> Types?
> One thing I'm not sure about this approach is that each rendering engine
> has differences in supported features inside SVGUseElement.
> For example, if the 
> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject>
> is supported, then iframes inside foreignObject can have srcdoc, and it can
> contain script tags which are considered "stored" XSS (because the payload
> never goes through DOM APIs), and therefore Trusted Types could be bypassed
> (i.e. script tags are not inline event handlers). But maybe the current
> script element restriction
> <https://www.w3.org/TR/SVG2/struct.html#UseShadowTree:~:text=Within%20a%20use%2Delement%20shadow%20tree%2C%20%E2%80%98script%E2%80%99%20elements%20are%20inert%20(do%20not%20execute)%3B>
> on the use element is enough to apply in child frames too?
>
> If it is for XSS, then as I mentioned, SVG link
> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/a> with
> Javascript: URL can still trigger XSS (because the script execution is a
> result of navigation, which can happen in the top frame or iframes by
> target attribute).
>
> Long story short, we did consider disabling scripts, but people's
> consensus (1 <https://github.com/mozilla/standards-positions/issues/718>,
> 2 <https://github.com/WebKit/standards-positions/issues/108>, 3
> <https://github.com/w3c/trusted-types/issues/357#issuecomment-1049761361>
> , 4 <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c10>, 5
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1300195#c11>) has
> been that it's just better to deprecate data: URLs in SVGUseElement.
>
>> Thanks
>>>>>
>>>>> On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:
>>>>>
>>>>>> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for adding me. Yes, this definitely seems like the pattern
>>>>>>> where we'd want a temporary enterprise policy to re-enable support for 
>>>>>>> ~3
>>>>>>> milestones after we remove support by default.
>>>>>>> go/chrome-enterprise-friendly
>>>>>>> <https://goto.google.com/chrome-enterprise-friendly> gets into the
>>>>>>> details of the why,
>>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>>>>>> is the step-by-step, and the enterprise team is always happy to advise 
>>>>>>> as
>>>>>>> well.
>>>>>>>
>>>>>>
>>>>>> Thank you for the details on enterprise policy! I'll make sure to
>>>>>> follow those steps when I plan to remove the feature by default!
>>>>>>
>>>>>>> On Tue, Jan 17, 2023 at 10:51 AM Rick Byers 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Would it be possible to turn
>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=30?q=ukm%20usecounter=chromium>
>>>>>>>>> the usecounter into a UKM to get a better view of the number of 
>>>>>>>>> impacted
>>>>>>>>> origins, beyond just the homepage?
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>> have. Can we find a developer for one of those sites who will talk to 
>>>>>>>> us
>>>>>>>> about where that pattern is coming from in their toolchain and how 
>>>>>>>> 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 (an

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

['Jun Kokatsu' via blink-dev]

recate data: URLs in SVGUseElement.

> Thanks
>>>>
>>>> On Tuesday, January 17, 2023 at 10:52:29 PM UTC-8 Jun Kokatsu wrote:
>>>>
>>>>> On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan 
>>>>> wrote:
>>>>>
>>>>>> Thanks for adding me. Yes, this definitely seems like the pattern
>>>>>> where we'd want a temporary enterprise policy to re-enable support for ~3
>>>>>> milestones after we remove support by default.
>>>>>> go/chrome-enterprise-friendly
>>>>>> <https://goto.google.com/chrome-enterprise-friendly> gets into the
>>>>>> details of the why,
>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>>>>>> is the step-by-step, and the enterprise team is always happy to advise as
>>>>>> well.
>>>>>>
>>>>>
>>>>> Thank you for the details on enterprise policy! I'll make sure to
>>>>> follow those steps when I plan to remove the feature by default!
>>>>>
>>>>>> On Tue, Jan 17, 2023 at 10:51 AM Rick Byers 
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Would it be possible to turn
>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=30?q=ukm%20usecounter=chromium>
>>>>>>>> the usecounter into a UKM to get a better view of the number of 
>>>>>>>> impacted
>>>>>>>> origins, beyond just the homepage?
>>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> have. Can we find a developer for one of those sites who will talk to us
>>>>>>> about where that pattern is coming from in their toolchain and how 
>>>>>>> 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
>>>>>>> stats). Maybe we'll get lucky and find that, despite the long tail, 90% 
>>>>>>> of
>>>>>>> the usage is from just a few sites we can work with.
>>>>>>>
>>>>>>
>>>>> 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 for the 
>>>>>>>> broader
>>>>>>>> web, while giving impacted folks some more time to move away from this
>>>>>>>> pattern.
>>>>>>>>
>>>>>>>
>>>>>>> Good idea. Impacting a large number of small sites is still
>>>>>>> problematic for a deprecation trial. Just reaching enough 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 advise on that. I'd also
>>>>>>> advise leaving this enabled for WebView (at least to start), it feels 
>>>>>>> like
>>>>>>> the sort of chromium rendering quirk we've found Android apps to rely on
>>>>>>> disproportionately in the past.
>>>>>>>
>>>>>>> On Fri, Jan 13, 2023 at 9:11 PM 'Jun Kokatsu' via blink-dev <
>>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> Thank you Rick for the detailed explanation!
>>>>>>>>>
>>>>>>>>> On Fri, Jan 13, 2023 at 10:30 AM Rick Byers 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Eliminating this makes 

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

['Jun Kokatsu' via blink-dev]

rating
>>>>>>>>this and will need to change?
>>>>>>>>
>>>>>>>> I think it is easy to migrate by hosting the same image to the
>>>>>>> same-origin endpoint. However, I do understand that it's just less work 
>>>>>>> to
>>>>>>> use data: URL than using same-origin image or blob: URL.
>>>>>>>
>>>>>>>>
>>>>>>>>- Interop
>>>>>>>>
>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4hjbxw7513sw>:
>>>>>>>>The fact that this doesn't work in Safari is a vote in favor of 
>>>>>>>> breaking it
>>>>>>>>in chromium to achieve interop. It does work in Firefox though.
>>>>>>>>
>>>>>>>>  For the interop, it's best to use a same-origin URL or blob: URL.
>>>>>>> And since both Mozilla and Webkit are supportive, I believe it's 
>>>>>>> positive.
>>>>>>>
>>>>>>>>
>>>>>>>>- Standards conformance
>>>>>>>>
>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.xcsa26ortrmi>:
>>>>>>>>This is allowed by spec today, so breaking it requires some more 
>>>>>>>> diligence
>>>>>>>>
>>>>>>>> Note that the PR <https://github.com/w3c/svgwg/pull/901> to SVG
>>>>>>> spec got merged.
>>>>>>>
>>>>>>
>>>>> Right, yes, sorry. What I meant was we took the initiative to make a
>>>>> breaking change to long established behavior - IMHO that makes the bar
>>>>> higher than if Chrome had just had a bug in allowing something that was
>>>>> never spec'd or allowed by other browsers. Still I think we can use this
>>>>> positively in our outreach - say something like "the spec has changed to
>>>>> not allow this, all the major browser engines agree that for security
>>>>> reasons it should be disallowed. It already doesn't work in Safari and
>>>>> other WebKit browsers, we want to help you fix your site to work in all
>>>>> browsers".
>>>>>
>>>>>>
>>>>>>>>- Enterprise
>>>>>>>>
>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.axcg738lzcs9>:
>>>>>>>>Being broken in Safari is an indication the risk will be higher in
>>>>>>>>enterprise software which is often chromium-only. We may need to go 
>>>>>>>> through
>>>>>>>>the enterprise breaking change process
>>>>>>>><https://www.chromium.org/developers/enterprise-changes/>.
>>>>>>>>- Outreach
>>>>>>>>
>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.t9ade4ywppcg>:
>>>>>>>>Given the relatively high usage, if we want to proceed with this 
>>>>>>>> plan I
>>>>>>>>think this is the main opportunity for mitigations. Can we try 
>>>>>>>> contacting
>>>>>>>>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 talking with a few customers who have done this 
>>>>>>>> and how
>>>>>>>>they fixed it for their UI design flow.
>>>>>>>>
>>>>>>>> Sorry it's not looking to be an easy decision, but I hope this
>>>>>>>> gives you some ideas for how we might be able to reduce the risk to a 
>>>>>>>> point
>>>>>>>> that we could proceed. WDYT?
>>>>>>>>
>>>>>>>
>>>>>>&g

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

['Jun Kokatsu' via blink-dev]

On Tue, Jan 17, 2023 at 11:36 AM Brandon Heenan  wrote:

> Thanks for adding me. Yes, this definitely seems like the pattern where
> we'd want a temporary enterprise policy to re-enable support for ~3
> milestones after we remove support by default.
> go/chrome-enterprise-friendly
> <https://goto.google.com/chrome-enterprise-friendly> gets into the
> details of the why,
> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
> is the step-by-step, and the enterprise team is always happy to advise as
> well.
>

Thank you for the details on enterprise policy! I'll make sure to follow
those steps when I plan to remove the feature by default!

> On Tue, Jan 17, 2023 at 10:51 AM Rick Byers  wrote:
>
>> On Tue, Jan 17, 2023 at 4:48 AM Yoav Weiss 
>> wrote:
>>
>>> Would it be possible to turn
>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=30?q=ukm%20usecounter=chromium>
>>> the usecounter into a UKM to get a better view of the number of impacted
>>> origins, beyond just the homepage?
>>>
>>
>> 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
>> have. Can we find a developer for one of those sites who will talk to us
>> about where that pattern is coming from in their toolchain and how 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
>> stats). Maybe we'll get lucky and find that, despite the long tail, 90% of
>> the usage is from just a few sites we can work with.
>>
>
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 for the broader
>>> web, while giving impacted folks some more time to move away from this
>>> pattern.
>>>
>>
>> Good idea. Impacting a large number of small sites is still problematic
>> for a deprecation trial. Just reaching enough 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 advise on that. I'd also advise leaving
>> this enabled for WebView (at least to start), it feels like the sort of
>> chromium rendering quirk we've found Android apps to rely on
>> disproportionately in the past.
>>
>> On Fri, Jan 13, 2023 at 9:11 PM 'Jun Kokatsu' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Thank you Rick for the detailed explanation!
>>>>
>>>> On Fri, Jan 13, 2023 at 10:30 AM Rick Byers 
>>>> wrote:
>>>>
>>>>> Eliminating this makes sense to me given the security benefit. Thank
>>>>> you for pushing it! But it does seem somewhat risky from a web compat
>>>>> perspective. 0.005% is above our "small but non-trivial risk
>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.mqfkui78vo5z>"
>>>>> rule of thumb. Here's a bit of an analysis according to our other compat
>>>>> principles <http://bit.ly/blink-compat>:
>>>>>
>>>>>- Severity of breakage
>>>>>
>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.u5ya6jvru7dl>:
>>>>>lower given this is likely only about some visualis, but this site
>>>>><https://jobs.nzz.ch/> is a good example of non-trivial UI
>>>>>breakage. This pattern of putting a base64-encoded SVG into an SVG 
>>>>> 
>>>>>element with nothing else in the  is weird, isn't it? Why would
>>>>>someone do that rather than just put the SVG in directly, or put the 
>>>>> data
>>>>>URL into an img tag?
>>>>>
>>>>> I've looked into that site. And it seems like they are reusing a
>>>> single SVG image (i.e. data: URL SVG image) which contains several images,
>>>> and changing which image should be rendered by combination of symbol
>>>> <https://developer.mozilla.org/en-US/docs/Web/SVG/Element/symbol> + id
>>>> (which is only possible in use el

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

['Jun Kokatsu' via blink-dev]

, it's best to use a same-origin URL or blob: URL. And
since both Mozilla and Webkit are supportive, I believe it's positive.

>
>- Standards conformance
>
> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.xcsa26ortrmi>:
>This is allowed by spec today, so breaking it requires some more diligence
>
> Note that the PR <https://github.com/w3c/svgwg/pull/901> to SVG spec got
merged.

>
>- Enterprise
>
> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.axcg738lzcs9>:
>Being broken in Safari is an indication the risk will be higher in
>enterprise software which is often chromium-only. We may need to go through
>the enterprise breaking change process
><https://www.chromium.org/developers/enterprise-changes/>.
>- Outreach
>
> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.t9ade4ywppcg>:
>Given the relatively high usage, if we want to proceed with this plan I
>think this is the main opportunity for mitigations. Can we try contacting
>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 talking with a few customers who have done this and how
>they fixed it for their UI design flow.
>
> Sorry it's not looking to be an easy decision, but I hope this gives you
> some ideas for how we might be able to reduce the risk to a point that we
> could proceed. WDYT?
>

Yes, it sounds good to me! I will check what has to be done and do those
step by step 

>
> Rick
>
> On Thu, Jan 12, 2023 at 3:11 PM 'Jun Kokatsu' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> 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
>>>
>>> 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 deprecate and remove support for it.
>>>
>>>
>>> Blink component
>>>
>>> Blink>SVG
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG>
>>>
>>> Motivation
>>>
>>> Assigning an attacker controlled string to SVGUseElement.href causes XSS
>>> and a Trusted Types bypass
>>> <https://github.com/w3c/trusted-types/issues/357> because of data:
>>> URLs. If we fix this bug by requiring TrustedScriptURL assignment to
>>> SVGUseElement.href under Trusted Types enforcement, many sites would need
>>> to refactor code (even for same-origin URL or Blob URL assignment).
>>>
>>> Since Webkit does not support data: URLs in SVGUseElement and both
>>> Mozilla and Webkit are supportive for the removal, we think that removing
>>> support for data: URLs in SVGUseElement is the right way to solve this
>>> problem.
>>>
>>> Additionally, data: URLs can only trigger script execution in script
>>> loaders such as HTMLScriptElement.src or dynamic import
>>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import>.
>>> However, SVGUseElement is an exception to this, which also caused a
>>> bypass
>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1306450#c10> in
>>> the Sanitizer API. We believe that this also led to several other bugs in
>>> sanitizers and linters missing a check for this special case.
>>>
>>> The usage
>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4356> of
>>> data: URLs in SVGUseElement is about 0.005%.
>>>
>>> Digging into the HTTP Archive shows usages in ~50 sites. There are 2
>>> major sites (slickdeals.net and hunter.104.com.tw) which use data: URLs
>>> in SVGUseElement.
>>>
>>> The use in slickdeals.net is invisible (i.e. used in the footer but
>>> doesn't appear), and hunter.104.com.tw is using it for a single icon in
>>> the footer (which is already broken when rendered in Webkit). Rest of the
>>> usages seems t

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

['Jun Kokatsu' via blink-dev]

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
>
> 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 deprecate and remove support for it.
>
>
> Blink component
>
> Blink>SVG
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG>
>
> Motivation
>
> Assigning an attacker controlled string to SVGUseElement.href causes XSS
> and a Trusted Types bypass
> <https://github.com/w3c/trusted-types/issues/357> because of data: URLs.
> If we fix this bug by requiring TrustedScriptURL assignment to
> SVGUseElement.href under Trusted Types enforcement, many sites would need
> to refactor code (even for same-origin URL or Blob URL assignment).
>
> Since Webkit does not support data: URLs in SVGUseElement and both Mozilla
> and Webkit are supportive for the removal, we think that removing support
> for data: URLs in SVGUseElement is the right way to solve this problem.
>
> Additionally, data: URLs can only trigger script execution in script
> loaders such as HTMLScriptElement.src or dynamic import
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import>.
> However, SVGUseElement is an exception to this, which also caused a bypass
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1306450#c10> in
> the Sanitizer API. We believe that this also led to several other bugs in
> sanitizers and linters missing a check for this special case.
>
> The usage
> <https://chromestatus.com/metrics/feature/timeline/popularity/4356> of
> data: URLs in SVGUseElement is about 0.005%.
>
> Digging into the HTTP Archive shows usages in ~50 sites. There are 2 major
> sites (slickdeals.net and hunter.104.com.tw) which use data: URLs in
> SVGUseElement.
>
> The use in slickdeals.net is invisible (i.e. used in the footer but
> doesn't appear), and hunter.104.com.tw is using it for a single icon in
> the footer (which is already broken when rendered in Webkit). Rest of the
> usages seems to be in individual small sites.
>
> I poked around the 10 sample sites at the bottom of the use counter:
>
> https://www.aspareanord.it/, https://www.umbria.camcom.it,
> https://www.bisenzio.it/, https://www.comune.vernio.po.it/,
> https://appaltinnovativi.gov.it/, https://www.gdf.gov.it/,
> https://www.us.schott.com/, https://shop.wavin.com/, https://jobs.nzz.ch/,
> https://www.learnapp.com/
>
> For the 6 Italian sites (I guess the same agency made them?), the right
> arrow icon next to "Vedi" would disappear. For a site like
> https://jobs.nzz.ch - there's a number of visually significant design
> icons that would be gone towards the bottom (and yes, it looks sort of
> broken today in Safari).
>
> It's not the end of the world, looking at these 10 sites, but I wonder how
> a developer would know how to fix this. Have you considered a DevTools
> issue?
>

Thank you for the suggestion! Yes, I do plan to follow Deprecation steps
<https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/frame/deprecation/README.md>
and
add a Devtools issue 

> Initial public proposal
>
> TAG review
>
> TAG review status
>
> Not applicable.
>
> Because this intent removes part of a feature, and it is already shipped
> in Webkit (i.e. never supported).
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Positive
> <https://github.com/mozilla/standards-positions/issues/718>
>
> WebKit: Positive
> <https://github.com/WebKit/standards-positions/issues/108>
>
> Web developers: No signals
>
>
> Debuggability
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?
>
> Yes <https://github.com/web-platform-tests/wpt/pull/37511>
>
> Flag name
>
> RemoveDataUrlInSvgUse
>
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1300195
>
> Estimated milestones
>
> Deprecate for 2 milestones, then remove depending on breakages.
>
> Can you say more about what the deprecation looks like (i.e., blog post,
> deprecation reports, devtools issue, etc)?
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5128825141198848
&g

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

['Jun Kokatsu' via blink-dev]

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 deprecate and remove support for it.


Blink component

Blink>SVG


Motivation

Assigning an attacker controlled string to SVGUseElement.href causes XSS
and a Trusted Types bypass 
because of data: URLs. If we fix this bug by requiring TrustedScriptURL
assignment to SVGUseElement.href under Trusted Types enforcement, many
sites would need to refactor code (even for same-origin URL or Blob URL
assignment).

Since Webkit does not support data: URLs in SVGUseElement and both Mozilla
and Webkit are supportive for the removal, we think that removing support
for data: URLs in SVGUseElement is the right way to solve this problem.

Additionally, data: URLs can only trigger script execution in script
loaders such as HTMLScriptElement.src or dynamic import
.
However, SVGUseElement is an exception to this, which also caused a bypass
 in the
Sanitizer API. We believe that this also led to several other bugs in
sanitizers and linters missing a check for this special case.

The usage
 of
data: URLs in SVGUseElement is about 0.005%.

Digging into the HTTP Archive shows usages in ~50 sites. There are 2 major
sites (slickdeals.net and hunter.104.com.tw) which use data: URLs in
SVGUseElement.

The use in slickdeals.net is invisible (i.e. used in the footer but doesn't
appear), and hunter.104.com.tw is using it for a single icon in the footer
(which is already broken when rendered in Webkit). Rest of the usages seems
to be in individual small sites.


Initial public proposal

TAG review

TAG review status

Not applicable.

Because this intent removes part of a feature, and it is already shipped in
Webkit (i.e. never supported).

Risks

Interoperability and Compatibility

Gecko: Positive 

WebKit: Positive 

Web developers: No signals


Debuggability

Is this feature fully tested by web-platform-tests

?

Yes 

Flag name

RemoveDataUrlInSvgUse


Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1300195

Estimated milestones

Deprecate for 2 milestones, then remove depending on breakages.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5128825141198848

This intent message was generated by Chrome Platform Status
.

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOWKMF6VXw7jmQoZM47i3ybzn%3D5Pc4mw26Khv9U9aP_UzBt-dg%40mail.gmail.com.

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

['Jun Kokatsu' via blink-dev]

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-html
>>
>> Summary
>>
>> Add a function to each "Trusted Type" to create an instance from a 
>> JavaScript template literal (but not from a dynamically computed string). 
>> This makes it easy to mark literals in the JavaScript source text as 
>> "trusted". Example:
>>
>> const html = TrustedHTML.fromLiteral`Literal Text`;
>>
>> Blink componentBlink>SecurityFeature>TrustedTypes 
>> 
>>
>> TAG reviewn/a
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>>
>> *Gecko*: No signal. (Gecko has not implemented Trusted Types.)
>>
>> *WebKit*: No signal. (WebKit has not implemented Trusted Types.)
>>
>> *Web developers*: Positive (
>> https://github.com/w3c/trusted-types/issues/347)
>>
>
> Can you point out specific signals in that thread that should be counted 
> as web developer ones?
>
It's little hard to tell, but that issue was a feature request from a 
developer (i.e. me).
At the time, I was working in Microsoft where I worked with Bing team to 
deploy Trusted Types in some of their products, and that was a request that 
I made.

 

>  
>
>>
>> *Other signals*:
>>
>> 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? No.
>>
>>
>>
>> Debuggability
>>
>> It's a new method. Its use can be readily debugged in DevTools.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?Yes
>>
>> Flag nameTrustedTypesFromLiteral
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1271149
>>
>> Estimated milestones
>>
>> 108
>>
>>
>> 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).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6551852775112704
>>
>> -- 
>>
> 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 on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMW%2BtvbM8eAxv5HJC0JW192EWSX_VmE7Yugta5Z5G-nXg%40mail.gmail.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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/018f9780-b98e-4b50-8ef5-7be1a0f69e47n%40chromium.org.

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

['Jun Kokatsu' via blink-dev]

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 Type" to create an instance from a 
> JavaScript template literal (but not from a dynamically computed string). 
> This makes it easy to mark literals in the JavaScript source text as 
> "trusted". Example:
>
> const html = TrustedHTML.fromLiteral`Literal Text`;
>
> Blink componentBlink>SecurityFeature>TrustedTypes 
> 
>
> TAG reviewn/a
>
> TAG review statusNot applicable
>
> Risks
>
> Interoperability and Compatibility
>
>
> *Gecko*: No signal. (Gecko has not implemented Trusted Types.)
>
> *WebKit*: No signal. (WebKit has not implemented Trusted Types.)
>
> *Web developers*: Positive (
> https://github.com/w3c/trusted-types/issues/347)
>
> *Other signals*:
>
> 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? No.
>
>
>
> Debuggability
>
> It's a new method. Its use can be readily debugged in DevTools.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> Flag nameTrustedTypesFromLiteral
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1271149
>
> Estimated milestones
>
> 108
>
>
> 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).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6551852775112704
>

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18969243-5331-4e32-9eda-8e02051906ffn%40chromium.org.

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

['Jun Kokatsu' via blink-dev]

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, and browsers (and other user 
agent) are free to implement any sort of permission model.

For example, a browser without Permission Delegation would require 
permission prompt from iframe (which contains origin of iframe in the 
prompt) in order to use any permission-based API. Permission Policy or 
allow attribute are just there to allow permission request from iframes, 
but that doesn't necessary mean that permission is delegated directly to 
iframe. 

If you try to ship Capability Delegation API in above model, this would be 
a bypass of permission prompt or delegating permission to cross-origin 
iframes without user's knowledge.

Thanks,

Jun

On Monday, July 12, 2021 at 9:31:24 AM UTC-7 Mustaq Ahmed wrote:

> A few quick updates:
> - The WICG/capability-delegation 
>  repository is the current 
> home for the explainer and a spec draft 
> .
> - Please use a new/existing issue 
>  for any comments 
> or suggestions.
> - We filed a TAG review request 
>  two weeks ago.
>
>
>
> On Wed, Nov 18, 2020 at 5:01 PM Mustaq Ahmed  wrote:
>
>> Hi Daniel:
>>
>> Sorry for the delay, thanks for listing those concerns.
>>
>> I have added a Privacy and security considerations 
>> 
>>  section 
>> in the design doc to address three of the concerns, please take a look and 
>> let us know if we missed anything.  I haven't yet replied to the Spectre 
>> point, I need to fully understand the attack vector you are thinking of.
>>
>> The relation to Feature/Permission Policy is still an open question, we 
>> will need some time to answer this.
>>
>> Mustaq
>>
>>
>> On Fri, Nov 6, 2020 at 12:04 PM Daniel Vogelheim  
>> wrote:
>>
>>> Hello Mustaq,
>>>
>>> We've discussed your intent within security + privacy teams. The 
>>> discussion raised a number of concerns, but we couldn't find enough detail 
>>> to either substantiate or allay them. This unfortunately makes it difficult 
>>> to give you actionable feedback.
>>>
>>> Our thoughts: This API effectively packages a permission / user 
>>> interaction in a token and allows it to be sent somewhere else, creating a 
>>> permission-capability-thing. This raises a number of questions:
>>>
>>> - The idea of gating functionality on user interaction is to make sure 
>>> that the user understands what they are interacting with. If a user 
>>> interaction is 'packaged' and sent for consumption elsewhere, does this 
>>> still hold? Could a malicious user put the 'packaged' interaction to a 
>>> surprising use?
>>> - Are there limits to where it can be passed to? Could it be passed - 
>>> via a server round-trip - to another site running in the same browser?
>>> - Is there any info on the API that would consume the token?
>>> - The token is unspecified, but seems to follow the pattern of 
>>> 'unguessable secret number'. The problem here is with the Spectre attack 
>>> family, where we've had to change our assumption to assume that any data 
>>> within a process is potentially readable, even by sandboxed code. Under 
>>> this assumption, could the token be read by an unintended recipient?
>>>
>>> We were also a bit unclear on the use cases, and the relationship to 
>>> feature policy.
>>>
>>> Mustaq, could you maybe update the docs to include this type of 
>>> information? We'd like to take a second look at it.
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>> On Fri, Oct 23, 2020 at 5:26 PM Mustaq Ahmed  
>>> wrote:
>>>
 Contact emailsmus...@chromium.org

 Explainergithub.com/mustaqahmed/capability-delegation

 SpecificationNone

 Summary

 Capability delegation means allowing a frame to relinquish its ability 
 to call a restricted API and transfer the ability to another (sub)frame it 
 can trust. If an app wants to delegate its ability to call a restricted JS 
 capability (e.g. popups, fullscreen, etc) to a known+trusted third-party 
 frame, the app would utilize a Capability Delegation API to "transfer" the 
 ability to the target frame in a time-constrained manner (unlike static 
 mechanisms like  attributes).

 Blink componentBlink 
 

 Motivation

 Here are some practical scenarios that would utilize a capability 
 delegation mechanism.


 - Many merchant websites host their online store on their own domain 
 but