Integrate feature policy #177

clelland · 2017-12-15T19:52:11Z

This adds a policy-controlled feature, named 'sync-xhr', which can be disabled in a document to turn off synchronous requests for that document (and documents in all descendant frames). Calling send() on a synchronous request in a document where sync-xhr is disabled will result in a NetworkError being thrown.

clelland · 2017-12-15T19:53:36Z

As written, this depends on whatwg/html#3287 so that 'allowed to use' can reference a policy-controlled feature, and not just an attribute name.

tyoshino

looks good

tyoshino · 2017-12-19T08:59:30Z

xhr.bs

+
+<p>The feature name for <a>Synchronous XMLHttpRequest</a> is "sync-xhr".
+
+<p>The default allowlist for Synchronous XMLHttpRequest is <code>*</code>.


<a> is omitted for "Synchronous XMLHttpRequest" intentionally? just checking.

Nope, missed the markup there. Thanks.

annevk · 2017-12-19T15:49:40Z

xhr.bs

+    <a>responsible document</a> and it is <em>not</em>
+    <a>allowed to use</a> the <a>Synchronous XMLHttpRequest</a>
+    feature, then run <a>handle response end-of-body</a> for a <a>network
+    error</a> and return.


It seems nicer to throw during open(), no?

That would be surprising to developers, I think -- there aren't currently any cases of a NetworkError being thrown during open(), since the fetch algorithm isn't called until send(). Since this policy can be imposed on pages which were written before this proposal, it seems that using an existing failure pattern is less likely to result in unforseen behaviour on the page.

I had originally proposed throwing an InvalidAccessError during open(), to align with the note at https://xhr.spec.whatwg.org/#sync-warning, but the rough consensus at TPAC (I wasn't actually present, this is second-hand) was around emulating a network-layer-error instead.

Well yeah, I wouldn't want to throw a NetworkError there. I wonder what rationale was given in that discussion. Who would we ask?

Note that InvalidAccessError would also be consistent with step 10 of open() today.

I'll ask on #178, and see if we can find out who was there, and if this accurately reflects the consensus.

https://chromium.googlesource.com/chromium/src/+/40126a62123c1e8704b2f92a6ef54eb3e6ce52db/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp#695 now throws InvalidAccessError in open(), which I think makes sense, has this been resolved but the comment thread just left open?

https://chromium-review.googlesource.com/c/chromium/src/+/804057 changes it from InvalidAccessError to NetworkError, and causes it to occur on send(), like other network conditions would.

I see, thanks!

annevk · 2017-12-19T15:49:55Z

xhr.bs

+<h3 id=feature-policy>Feature Policy Integration</h3>
+
+<p>This specification defines a policy-controlled feature named <dfn>Synchronous
+XMLHttpRequest</dfn>.


Are all features supposed to follow this naming convention?

I wanted to decouple the name of the feature from the character string used to denote it in policies

The spec just says that there are policy-controlled features, and they have a feature name, which is defined in the ABNF as 1*( ALPHA / DIGIT / "-")

annevk · 2017-12-19T15:50:46Z

xhr.bs

+<p>This specification defines a policy-controlled feature named <dfn>Synchronous
+XMLHttpRequest</dfn>.
+
+<p>The feature name for <a>Synchronous XMLHttpRequest</a> is "sync-xhr".


xref "feature name"

And make it "<code>sync-xhr</code>".

Done. (I've added explicit anchors for the unexported dfns until I fix up the FP spec to export those terms properly)

annevk · 2017-12-19T15:51:32Z

xhr.bs

+
+<p>The feature name for <a>Synchronous XMLHttpRequest</a> is "sync-xhr".
+
+<p>The default allowlist for Synchronous XMLHttpRequest is <code>*</code>.


xref "default allowlist" (elsewhere we use safelist for things like this, is this different enough to use a new name?)

I hadn't noticed 'safelist' being used in this context, and I'm not sure if 'safety' is the concept we're trying to convey in any case.

Originally the feature policy spec used 'whitelist', and early reviews suggested we switch to 'allowlist' to match some other specs (I don't recall which; perhaps Web Authentication?)

I'm sure this is open to change, but that should probably happen on the FP issues list :)

WebAuthn doesn't seem to use it.

w3c/webauthn#327 -- apparently not anymore (I still don't remember if this was the spec that was brought up, could be a complete coincidence)

annevk · 2017-12-19T15:52:10Z

xhr.bs

+
+<p>When disabled in a document, calling send() on an XMLHttpRequest object with
+the synchronous flag set MUST cause a DOMException named
+ <code>NetworkError</code> to be thrown.


Please remove this. We don't want duplicate requirements.

* Fix references and markup * Remove duplicated requirement text

annevk · 2017-12-19T18:06:52Z

In particular I was wondering if a feature is always named "Uppercase Feature" or "Uppercase feature" rather than just "uppercase feature" which would be "synchronous XMLHttpRequest" here. Introducing that as a "feature named X" and then saying X has a feature name is somewhat confusing by the way. Maybe it makes more sense to call one the feature name and the other the identifier.

clelland · 2018-01-11T16:01:09Z

There isn't a standard for naming features -- I've generally used whatever seems to sound right in prose -- and this is really the first time that the name of a feature and it's "feature name" string have diverged, since neither seems appropriate in the other's place.

(And I agree that it is confusing to call the character string that goes into policies the "feature name". I've opened w3c/webappsec-permissions-policy#125 to address that. I'll submit PRs to all of the specs that have included that text once we have settled on a better term to use)

domenic · 2018-01-11T16:08:37Z

FWIW I would probably just remove the feature name concept entirely and only use the web-developer-facing string ("feature identifier") throughout all specs. Having two 1:1 things, one of which is never exposed to either browser developers or web developers, seems confusing.

clelland · 2018-01-24T18:33:28Z

Agreed, and fixed with the latest commit.

annevk

Couple nits left, mostly looking good now. Thanks.

annevk · 2018-01-25T13:19:26Z

xhr.bs

@@ -29,6 +29,9 @@ spec:dom; type:interface; text:Document
 <pre class=anchors>
 urlPrefix: https://w3c.github.io/DOM-Parsing/; spec: dom-parsing
    type: dfn; text: fragment serializing algorithm; url: dfn-fragment-serializing-algorithm
+urlPrefix: https://wicg.github.io/feature-policy/; spec: FEATURE-POLICY
+    type: dfn; text: policy-controlled feature; url: policy-controlled-feature
+    type: dfn; text: default allowlist; url: default-allowlist


These should be properly exported by Feature Policy directly. This anchors block is only there for legacy.

They've been exported for a while -- or at least I thought they were :( Filed speced/bikeshed#1173 to get that indexed for use in bikeshed.

annevk · 2018-01-25T13:24:11Z

xhr.bs

+   <li>
+    <p>If <a>context object</a>'s <a>relevant settings object</a> has a
+    <a>responsible document</a> and it is <em>not</em> <a>allowed to use</a> the
+    <code><a>sync-xhr</a></code> feature, then run <a>handle response


If this is meant to be a string I think it should be "<code><a>sync-xhr</a></code>" here and below. That's how you write down strings per Infra.

Also, no wrapping inside phrasing elements.

Oh, also, since the <p> is the only child you need to do <li><p>....

annevk · 2018-01-25T13:24:51Z

xhr.bs

+
+<p>This specification defines a <a>policy-controlled feature</a> identified by
+the string <code><dfn>sync-xhr</dfn></code>. Its <a>default allowlist</a> is
+<code>*</code>.


More can be on one line here. Please use 100 columns for new/modified text.

annevk · 2018-01-25T13:25:06Z

xhr.bs

+<p>This specification defines a <a>policy-controlled feature</a> identified by
+the string <code><dfn>sync-xhr</dfn></code>. Its <a>default allowlist</a> is
+<code>*</code>.
+


You want an extra newline here for consistency.

annevk · 2018-01-25T13:26:41Z

xhr.bs

@@ -1021,6 +1025,12 @@ method must run these steps:
  <p>Otherwise, if the <a>synchronous flag</a> is set, run these substeps:

  <ol>
+   <li>
+    <p>If <a>context object</a>'s <a>relevant settings object</a> has a
+    <a>responsible document</a> and it is <em>not</em> <a>allowed to use</a> the


Should this be "and that"/"which is"? To me it seems that "it" refers to a settings object here.

Fixed -- that was ambiguous, thanks.

* Clarify which object is tested for "allowed to use" * Denote strings correctly * Formatting

annevk

Great work!

What remains is:

web-platform-tests
Implementation bugs

if I'm not missing anything.

annevk · 2018-01-30T16:03:01Z

You also might want to associate [email protected] with your GitHub account and add your name to the Acknowledgments section of the standard.

clelland · 2018-02-01T15:54:45Z

@annevk, there are web-platform-tests for this already committed; you can see the results at https://wpt.fyi/xhr/xmlhttprequest-sync-default-feature-policy.sub.html (It fails in Chrome 63, but should pass in 65) Are there additional tests you'd like to see?

I'll see about filing bugs in other places where I can do that.

annevk · 2018-02-01T17:18:41Z

That's good enough I think. Other interesting tests might be header-based / same-origin restrictions.

annevk · 2018-02-01T17:21:34Z

I noticed one more nit. We use sentence casing for headers. I'm not entirely sure if that means "Feature Policy integration" or "Feature policy integration" though. I'm guessing the former makes the most sense.

annevk · 2018-02-01T17:22:24Z

FWIW, here are the various bug databases:

clelland · 2018-03-02T17:57:50Z

Bugs filed:

domenic · 2018-03-02T18:24:59Z

Doesn't this depend on whatwg/html#3287 which is still not merged? :-/

annevk · 2018-03-02T18:27:23Z

@domenic see the commit message.

clelland added 2 commits December 15, 2017 14:09

Fix some linking errors

0792a5f

clelland mentioned this pull request Dec 15, 2017

Allow developers to opt-out of sync XHR with feature policy #178

Closed

tyoshino reviewed Dec 19, 2017

View reviewed changes

annevk reviewed Dec 19, 2017

View reviewed changes

clelland added 2 commits December 19, 2017 12:00

Clean up FP integration

28a6ab1

* Fix references and markup * Remove duplicated requirement text

Properly link to FP spec

e10403b

annevk mentioned this pull request Dec 19, 2017

"allowlist" w3c/webappsec-permissions-policy#103

Closed

clelland mentioned this pull request Jan 11, 2018

Replace "feature name" with "identifier" or similar w3c/webappsec-permissions-policy#125

Closed

Remove unneeded feature name

deac6f6

annevk reviewed Jan 25, 2018

View reviewed changes

clelland added 3 commits January 25, 2018 11:55

Merge branch 'master' into integrate-feature-policy

3d32ed6

Addressing review comments

3c98423

* Clarify which object is tested for "allowed to use" * Denote strings correctly * Formatting

Remove custom anchors for exported definitions

9210149

annevk approved these changes Jan 30, 2018

View reviewed changes

Add Ian Clelland to acknowledgements section

bfcb523

annevk mentioned this pull request Mar 2, 2018

Feature proposal: sync-xhr w3c/webappsec-permissions-policy#126

Closed

annevk merged commit 67a423f into whatwg:master Mar 2, 2018

clelland mentioned this pull request Nov 12, 2020

Permissions Policy JS API w3c/webappsec-permissions-policy#401

Open


		<p>The feature name for <a>Synchronous XMLHttpRequest</a> is "sync-xhr".

		<p>The default allowlist for Synchronous XMLHttpRequest is <code>*</code>.

Integrate feature policy #177

Integrate feature policy #177

Conversation

clelland commented Dec 15, 2017 • edited by pr-preview bot Loading

clelland commented Dec 15, 2017

tyoshino left a comment

Choose a reason for hiding this comment

tyoshino Dec 19, 2017 • edited by annevk Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Dec 19, 2017

clelland commented Jan 11, 2018

domenic commented Jan 11, 2018 • edited Loading

clelland commented Jan 24, 2018

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

annevk commented Jan 30, 2018

clelland commented Feb 1, 2018

annevk commented Feb 1, 2018

annevk commented Feb 1, 2018

annevk commented Feb 1, 2018

clelland commented Mar 2, 2018

domenic commented Mar 2, 2018

annevk commented Mar 2, 2018

clelland commented Dec 15, 2017 •

edited by pr-preview bot

Loading

tyoshino Dec 19, 2017 •

edited by annevk

Loading

domenic commented Jan 11, 2018 •

edited

Loading