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. |
| 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.
| 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?
| 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.
Preview | Diff