Intent to Implement and Ship: Feature Policy control over Synchronous XHR

[Ian Clelland]

Contact emails

icle...@chromium.org

Spec

XHR Spec is https://xhr.spec.whatwg.org/

This intent is to implement and ship the spec change described in https://github.com/whatwg/xhr/pull/177

Summary

As a step towards eventual deprecation of Synchronous XMLHttpRequest outside of workers, we are making it a policy-controlled feature. This allows synchronous XHR to be disabled for any document by the developer, or for a document embedded in a frame by the embedding page. Disabling it will cause calls to send() to immediately fail with a network error. When disabled in any frame, that policy automatically applies to any content embedded within that frame as well.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

http://xhr.featurepolicy.rocks/

Debuggability

When an XHR is disabled by feature policy, it will appear to the application that a network error has occurred. To help developers distinguish this from a legitimate network error, a message will be printed to the developer console.

Risks

Interoperability and Compatibility

This proposal adds an optional way to disable an existing feature. Existing websites will not be affected by the introduction of this feature, and synchronous XHR will continue to work as before. There are, however, at least two possible sources of interop and compat risk:

The first would be that developers believe that they have disabled synchronous XHR by policy, but it continues to work in browsers which have not implemented this feature.

The second risk is that sites which are completely unaware of this change are embedded via <iframe> elements inside of a page which disables synchronous XHR. In that case, any synchronous request initiated in those sites would stop working. This is at least partly mitigated by the fact that a network error condition is simulated, and any sites which rely on network requests should (in theory) be written to handle the case where those requests fail.

There is widespread support among browser vendors for doing *something* to restrict / discourage the use of synchronous XHR on the web, and discussions at TPAC concluded that this was a reasonable something to start with.

Web developers come down on both sides, and are often against removing synchronous XHR completely, which is why this mechanism is opt-in.

Edge, Firefox: See https://github.com/WICG/interventions/issues/62#issuecomment-343332995

Safari: No signals

Web developers: No signals

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

This may be used with other feature policy features, and can easily be integrated into existing policies.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

The default state of the feature is that synchronous XHR is enabled, which is not great for performance, but it's the current state of the web.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Using the feature is as simple as adding an HTTP header to the top-level page of a site, or adding a new attribute, allow="sync-xhr none", to an iframe.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Unknown; documentation and outreach would probably be great, but likely as part of a larger 'modern web' initiative.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes, the feature is tested at

https://wpt.fyi/XMLHttpRequest/xmlhttprequest-sync-default-feature-policy.sub.html

(moving soon to https://wpt.fyi/xhr/xmlhttprequest-sync-default-feature-policy.sub.html)

Entry on the feature dashboard

We haven't been making chromestatus entries for each feature being moved under feature policy, but happy to make a new one if appropriate.

[Joe Medley]

"

We haven't been making chromestatus entries for each feature being moved under feature policy, but happy to make a new one if appropriate."

We do tend to do that for other features. For example: https://www.chromestatus.com/features/4973817285836800

I at least need a tracking bug so that DevRel can know when it ships.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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/CAK_TSXL7-bwANF0hBi_oM25nv_-GKiYpYsffYC5OhhJGuASZmQ%40mail.gmail.com.

[Ian Clelland]

Thanks, Joe --

Filed https://www.chromestatus.com/feature/5154875084111872

The bug for this is https://crbug.com/661283

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

LGTM. It sounds like there's still a little bit of discussion on the spec PR, but it seems close enough to me now to ship (which we can of course reconsider if necessary before it reaches stable). 

Other platforms have long ago moved to completely failing requests for synchronous network I/O on the UI thread, it's long overdue for the web to catch up to that principle (especially as Chrome's usage is growing so much in lower-bandwidth countries).  Adding a feature-policy opt-out is a really important step towards giving content embedders more control over the user experience implications of what they embed (potentially holding their embedees to a higher bar than we're able to hold for the web at large by default).   At TPAC there was verbal support from representatives from Microsoft, Mozilla and Apple for this approach.

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/CAK_TSXL7-bwANF0hBi_oM25nv_-GKiYpYsffYC5OhhJGuASZmQ%40mail.gmail.com.

--
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/CAK_TSXJWDz4YnzXNzfOW%2Bw%2ByUAsBFMSBDsC8pdu52_iGHYgnow%40mail.gmail.com.

[Mike West]

In itself, this seems like a low-risk feature to ship. As part of the broader deprecation strategy, this lets folks get the ball rolling. LGTM2.

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/CAK_TSXL7-bwANF0hBi_oM25nv_-GKiYpYsffYC5OhhJGuASZmQ%40mail.gmail.com.

--
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/CAK_TSXJWDz4YnzXNzfOW%2Bw%2ByUAsBFMSBDsC8pdu52_iGHYgnow%40mail.gmail.com.

--
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/CAFUtAY9uBtvA0Rpid_HFDJOakwAG_uf_zYV%2Bn6BQk5L%3DJWKVzQ%40mail.gmail.com.

--

-mike

[Philip Jägenstedt]

LGTM3 assuming the spec, tests and implementation will all agree when shipping.

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

[jxck jxck]

Hi

Question.

in case of

https://example.com/index.html includes iframe https://example.net/frame.html

I wanna allow sync-xhr only in frame.html.

I add header below to index.html

```

content-security-policy: sandbox allow-scripts

feature-policy: sync-xhr https://example.net

```

and in chrome canaly 67.0.3362.0

I expected that sync-xhr in iframe works,

but actually blocked by feature policy

```

// error in console

Synchronous requests are disabled by Feature Policy.

```

if adding only csp line, works

if adding only feature policy, works

but adding cps + feature doesn't works.

live demo

https://labs.jxck.io/feature-policy/sync-xhr/sandbox.html

is this a bug ? or my misunderstood ?

thanks

Jxck

2018年1月17日水曜日 0時57分24秒 UTC+9 Ian Clelland:

[Ian Clelland]

Hi Jxck --

WIthout looking too deeply into your demo (which I hope to get to), this might be an interaction between iframe sandboxing and feature policy. Sandboxed pages, unless they have the option "allow-same-origin", have an opaque origin, which can't be referenced by name anywhere. So if you have allowed "example.net" access to SyncXHR, but the frame has an opaque origin (even though the contents are loaded from example.net) then feature policy won't see the frame as being from example.net, and so won't allow it.

If you need to target a sandboxed frame to allow a feature like that, you might need to use the allow attribute, like:

<iframe src="https://example.net/frame.html" sandbox="allow-scripts" allow="sync-xhr">

That allow attribute will specifically target the opaque origin of the sandboxed iframe, and *should* work. (Again, I haven't actually tried this yet with your demo page)

Ian

--
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/c3258ddb-9354-43f8-9f35-5faf111c8df6%40chromium.org.