Spec partition nonce functionality #149
Conversation
spec.bs
Outdated
| boolean |isCredentialless| and [=fenced frame config instance/partition nonce=] or null | ||
| |newFencedFrameNonce|: | ||
|
|
||
| 1. If |credentialless| is true, return |this|'s [=top-level browsing context=]'s |
There was a problem hiding this comment.
credentialless => isCredentialless
There was a problem hiding this comment.
I can't really change this, since it corresponds to an exposed IDL attribute.
https://wicg.github.io/anonymous-iframe/#spec-window-attribute
There was a problem hiding this comment.
Well where are you getting |credentialless| from then? It's not just a global variable is it?
There was a problem hiding this comment.
It's a local variable, but I meant it would be weird to call it something else when it corresponds exactly to this preexisting field, and the same name is used throughout the Iframe credentialless spec
There was a problem hiding this comment.
Where is this local variable defined? Sorry I don't think I'm getting it.
There was a problem hiding this comment.
Oh, I misread this. I didn't mean to name the variable isCredentialless above in the declaration. The iframe credentialless spec refers to this kind of variable as credentialless throughout, so it would be inconsistent naming to use isCredentialless here. Changed the declaration back to credentialless to match.
There was a problem hiding this comment.
So @VergeA what's the verdict here? Should we have a "credentialless" variable in the algorithm declaration? Does everything look good enough here to resolve?
There was a problem hiding this comment.
Yes, I believe the "credentialless" variable needs to be declared. Reasoning:
- The "process a navigate fetch" algorithm below already has a "credentialless" variable
- The "initialize a document object" algorithm below also already has a "credentialless" variable
Without it, we don't know whether the partition nonce should come from the credentialless iframe or the fenced frame.
Given that the algorithm here declares |credentialless| as a local variable, and the below algorithms invoke it correctly, this seems fine to me to resolve.
(going to resolve all the other comments before I re-request a review, just need to get this one out of my brain.)
spec.bs
Outdated
| boolean |isCredentialless| and [=fenced frame config instance/partition nonce=] or null | ||
| |newFencedFrameNonce|: | ||
|
|
||
| 1. If |credentialless| is true, return |this|'s [=top-level browsing context=]'s |
There was a problem hiding this comment.
Well where are you getting |credentialless| from then? It's not just a global variable is it?
|
@domfarolino I think all the comments are addressed now |
|
Hey y'all, this seems important to have for completeness of the network revocation spec, so I'm going to take it over from gtanzer. Looks like all outstanding comments have been addressed, but wanted to request a re-review for any additional feedback. If there's additional changes necessary, I'll address them before we merge (and also resolve all the merge conflicts :) ). |
spec.bs
Outdated
| boolean |isCredentialless| and [=fenced frame config instance/partition nonce=] or null | ||
| |newFencedFrameNonce|: | ||
|
|
||
| 1. If |credentialless| is true, return |this|'s [=top-level browsing context=]'s |
There was a problem hiding this comment.
So @VergeA what's the verdict here? Should we have a "credentialless" variable in the algorithm declaration? Does everything look good enough here to resolve?
|
I think most of this could use rewrapping. I think it rewraps too aggressively, avoiding all spaces in linked-to terms. |
|
Addressed all the outstanding comments, but still need to go back through and rewrap everything. |
|
Alright, this should be all rewrapped now. |
spec.bs
Outdated
| The [[!IFRAME-CREDENTIALLESS]] specification defines a new object, the [=page credentialless | ||
| nonce=]. At a high level, the [=fenced frame config instance/partition nonce=] serves the same | ||
| purpose as the [=page credentialless nonce=] (partitioning storage and network), but scoped to each | ||
| fenced frame rather than to each credentialless iframe. The [=fenced frame config instance/ |
There was a problem hiding this comment.
Is page credentialless nonce really scoped to each credentialless iframe? The definition you link to seems to be tied to a top-level browsing context, which spans many iframes.
There was a problem hiding this comment.
Yeah I agree this is just worded wrong; every credentialless iframe "has" a nonce, which I think was the original intention here, but the value of that nonce is scoped to the top-level document. I updated the wording here to indicate as such.
spec.bs
Outdated
| nonce=]. At a high level, the [=fenced frame config instance/partition nonce=] serves the same | ||
| purpose as the [=page credentialless nonce=] (partitioning storage and network), but scoped to each | ||
| fenced frame rather than to each credentialless iframe. The [=fenced frame config instance/ | ||
| partition nonce=] is also used to revoke network access in fenced frames. Perform the following |
There was a problem hiding this comment.
| partition nonce=] is also used to revoke network access in fenced frames. Perform the following | |
| partition nonce=] is also used to revoke network access in fenced frames. Apply the following |
| |newFencedFrameNonce|: | ||
|
|
||
| 1. If |credentialless| is true, return the associated [=browsing context=]'s [=top-level | ||
| browsing context=]'s [=page credentialless nonce=]. |
There was a problem hiding this comment.
Note that the usage of "top-level browsing context" here will be fenced — is that intentional? That's because this specification does not override HTML's definition of top-level browsing context, which just iteratively reaches upward via the "parent" property, never the "unfenced parent" property.
If you want the unfenced version, you'll need to grab a navigable's top-level traversable and get its browsing context and grab its page credentialless nonce.
I just wanted to raise this in case it was unexpected. WDYT?
It seems like this algorithm prefers:
- A "fenced" page redentialless nonce, when we're in a credentialless iframe
- A "new" fenced frame nonce, when it exists
- The "old" navigated-away-from browsing context's fenced frame partition nonce, when we're in a fenced frame whose browsing context is apparently being navigated away from. (Is that right?)
Actually (3) above is a little confusing or surprising to me. Below on L4031 we're always grabbing the current browsing context's fenced frame config instance's nonce, even when said browsing context is I guess being navigated away from? Am I missing something?
There was a problem hiding this comment.
Regarding usage of "top-level browsing context:" I think this is actually intentional, looking at the Chromium implementation here
- Each fenced frame tree has its own content::Page.
- The credentialless_iframe_nonce_ is only written once, when a content::Page is constructed
- This means that the credentialless iframe nonce is unique per main frame, rather than per primary main frame.
Translating that to spec world, I think getting the "top-level browsing context" is indeed what we want, rather than the "top-level traversable," because we want the "fenced" top-level frame.
Regarding (3): There are a couple of situations where it's appropriate to re-use the nonce from the current browsing context: first is a content-initiated FF root navigation, and second is a subframe navigation, since I believe subframes' browsing contexts inherit the fenced frame config instance from their parent FF.
I need to spend some more time looking at the navigation algorithms patched below to determine if they actually provide a null nonce in situations where the current browsing context's nonce should be re-used instead, but I wanted to get this comment written out to refer to later.
There was a problem hiding this comment.
Ok I think I have figured (3)
For the process a navigate fetch algorithm, we always want to use the "old" partition nonce, so we can determine if the navigation is originating from a fenced frame, and if that navigation should be revoked due to disabled network access. I passed null to computing the effective partition nonce here to make it clear that getting the "old" nonce is the desired behavior.
For the initializing the document object algorithm, if a new fenced frame config instance was set in the navigation params as the result of an embedder-initiated navigation, we want to use the nonce from that one. Otherwise, the navigation was content-initiated or a subframe navigation, so we should use the nonce available from the current browsing context instead.
| Modify the step added to <a href=https://wicg.github.io/anonymous-iframe/#spec-navigation-partition-nonce> | ||
| process a navigate fetch</a> to read: | ||
|
|
||
| 13. Let <var ignore>partitionNonce</var> be the result of [=browsing context/computing the |
There was a problem hiding this comment.
Just to triple check here — the partitionNonce returned from the "computing" algorithm can be null. Can all of the consumers of this (presumably in the iframe credentialless spec) consume null in this case? Just want to make sure we're not in a position where we're passing null around to things that only accept/expect a populated nonce.
There was a problem hiding this comment.
The credentialless iframe spec explicitly defines a partition nonce as "an identifier or null" in the environment.
In the algorithms we're changing here from the credentialless iframe spec, the partition nonce is already allowed to be null if the page credentailless nonce is missing.
Preview | Diff