The original failure mode described in #0 may not be practical for the open web; there may be pages which depend on XHR.open succeeding and which never check for InvalidAccessError (and which may generally expect the call to succeed, especially if it is transferred from the same origin server as the requesting document)

In that case, we may want to consider unloading a document which violates policy, rather than possibly failing (effectively) silently. In a policy-aware document -- one which has set its own policy for syncxhr -- we may choose to fail with the IAError instead.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/224ff964f4e15546d6a11fe39596e60cee2120d2

commit 224ff964f4e15546d6a11fe39596e60cee2120d2
Author: Ian Clelland <iclelland@google.com>
Date: Thu Oct 12 18:09:20 2017

Add SyncXHR as an experimental policy-controlled feature

This CL disables synchronous XHR in documents by throwing an
InvalidAccessError on open() if it is disallowed by feature policy.

SyncXHR is allowed by default in all frames; to disable in a particular
iframe, use the allow attribute, like

<iframe src="..." allow="sync-xhr 'none'"></iframe>

Or include a Feature-Policy HTTP header with a document which either
only allows synchronous XHR in certain origins:

Feature-Policy: sync-xhr 'self' https://example.com

or disallows it completely:

Feature-Policy: sync-xhr 'none'

The feature currently requires the 'FeaturePolicyExperimentalFeatures'
runtime flag.


Bug:  661283 
Change-Id: If511e5990623670128f63f9c1d7233bca659b7e6
Reviewed-on: https://chromium-review.googlesource.com/656722
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508370}
[add] https://crrev.com/224ff964f4e15546d6a11fe39596e60cee2120d2/third_party/WebKit/LayoutTests/external/wpt/XMLHttpRequest/xmlhttprequest-sync-default-feature-policy.sub-expected.txt
[add] https://crrev.com/224ff964f4e15546d6a11fe39596e60cee2120d2/third_party/WebKit/LayoutTests/external/wpt/XMLHttpRequest/xmlhttprequest-sync-default-feature-policy.sub.html
[modify] https://crrev.com/224ff964f4e15546d6a11fe39596e60cee2120d2/third_party/WebKit/LayoutTests/external/wpt/feature-policy/resources/featurepolicy.js
[modify] https://crrev.com/224ff964f4e15546d6a11fe39596e60cee2120d2/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp
[modify] https://crrev.com/224ff964f4e15546d6a11fe39596e60cee2120d2/third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f5df3401108eac38bb63d99372195b342493428

commit 0f5df3401108eac38bb63d99372195b342493428
Author: Ian Clelland <iclelland@google.com>
Date: Wed Jan 17 16:59:02 2018

Treat policy-disallowed sync xhr as a network error

Bug:  661283 

Change-Id: I311cef40e03a264ca9db601842477d502e7cf12d
Reviewed-on: https://chromium-review.googlesource.com/804057
Reviewed-by: Takeshi Yoshino <tyoshino@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529775}
[delete] https://crrev.com/e84a57647a5dc8838a1e1053d00c31deadef051d/third_party/WebKit/LayoutTests/external/wpt/xhr/xmlhttprequest-sync-default-feature-policy.sub-expected.txt
[modify] https://crrev.com/0f5df3401108eac38bb63d99372195b342493428/third_party/WebKit/LayoutTests/external/wpt/xhr/xmlhttprequest-sync-default-feature-policy.sub.html
[modify] https://crrev.com/0f5df3401108eac38bb63d99372195b342493428/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequest.cpp
[modify] https://crrev.com/0f5df3401108eac38bb63d99372195b342493428/third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/245bf895c9c98f7b07cb840c0a553e9dc16f4d09

commit 245bf895c9c98f7b07cb840c0a553e9dc16f4d09
Author: Ian Clelland <iclelland@google.com>
Date: Fri Jan 19 16:12:09 2018

Catch unexpected exceptions in sync-xhr test.

With this change, only the expected NetworkError from send() will be
propagated to the feature policy test framework. Other errors (including
NetworkErrors from other calls) will be prefixed with
"UnexpectedException:" and will cause the tests to fail.

Bug:  661283 
Change-Id: I75e2fa6526211cc87c65f5f03e926903ae1ba22e
Reviewed-on: https://chromium-review.googlesource.com/874270
Commit-Queue: Philip Jägenstedt <foolip@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530527}
[modify] https://crrev.com/245bf895c9c98f7b07cb840c0a553e9dc16f4d09/third_party/WebKit/LayoutTests/external/wpt/xhr/xmlhttprequest-sync-default-feature-policy.sub.html

This feature breaks extensions that use sync XHR in the content script to get dynamic data from their background pages at document_start before the page starts loading. For example, Tampermonkey - when configured to use Instant inject mode.

With this change, and in the absence of any extension API to pass data synchronously at document_start, extension developers will no longer be able to provide dynamically configurable service in the web pages (like adding a custom API or the abovementioned userscripts in Tampermonkey) *before* the page starts running its scripts.

This should only break pages that actually choose to embed content with the feature disabled -- synchronous XHR is still enabled by default in all web content. (Including extensions)

Is there a site you can point to that is currently broken with this change?

>This should only break pages that actually choose to embed content with the feature disabled

Extensions may run content scripts in any web iframe, including the sandboxed ones because extensions act on behalf of the user and so they must have a way to be exempt from web restrictions. This is how extensions always worked in all browsers including Chrome. This change should not have broken extensions at all.

>Is there a site you can point to that is currently broken with this change?

I can make one right now but what for? In the future there might be millions of iframes that break extensions in the way I've described. The problem here is not the amount of sites, but the basic approach: extensions should not be affected by web limits.

The detrimental effect could be lessened if someone implements a proper extensions API to pass dynamic data at document_start so it's available immediately in the content script's first statement (that is same behavior as sync XHR implements right now).