Introduce Feature policy : `document-write` #172

ehsan-karamad · 2018-06-04T15:27:43Z

This document servers as an explainer of an experimental feature which was most recently committed to chromium codebase. The state of the proposal is not complete as there is still a critical open questions regarding the correct implementation and behavior for cross and same-origin contents.

All suggestions and ideas are most welcomed!

This document servers as an explainer of an experimental feature which was most recently committed to chromium [codebase](https://chromium.googlesource.com/chromium/src/+/d8e49fe9a8374c236010d75874c082e9701543fb). The state of the proposal is not complete as there is still a critical open questions regarding the correct implementation and behavior for cross and same-origin contents. All suggestions and ideas are most welcomed!

annevk · 2018-06-05T04:06:33Z

I think it would be much clearer if we called this "document-write".

clelland · 2018-06-05T14:36:46Z

Agreed -- the initial spec had a feature called 'docwrite', for even more terseness. Do you think document-write captures the idea that this also restricts document.open and document.close as well?

clelland · 2018-06-05T14:37:19Z

policies/document_stream_insertion.md

+
+## Objective
+The API around document stream modification ([dynamic mark-up insertion](https://www.w3.org/TR/2011/WD-html5-author-20110705/apis-in-html-documents.html#dynamic-markup-insertion)), i.e., `document.write`, `document.writeln`, `document.open` and `document.close` 
+are anti-pattern, parser-blocking javascritp API. The objective of the proposed feature is to limit the usage of this API in websites.


sp: JavaScript

Done, thanks!

clelland · 2018-06-05T14:38:11Z

policies/document_stream_insertion.md

+
+## Solution
+
+When the feature is disabled for a specific origin in a frame, any occurance of such API will be ignored and might


sp: occurrence (or better yet, "usage")

Done, thanks!

clelland · 2018-06-05T14:40:15Z

policies/document_stream_insertion.md

+```
+<iframe src="https://example.com" allow="document-stream-insertion http://www.google.com"></iframe>
+```
+would limit the usage of stream insertion API to only "google.com" origins using HTTPS protocol.


Not quite accurate: This limits it to just www.google.com, not any *.google.com origin. (and you've used HTTP, rather than HTTPS)

Thanks, I believe I confused site instance with origin.

clelland · 2018-06-05T14:44:53Z

policies/document_stream_insertion.md

+1: The _most_ correct behavior is not known yet. For now, Chrome's implementation behind the flag simply throws exception
+on API usage (for both same and cross origin). But this is not the final implementation.
+
+2: An embedded website might rely on important `<script>` added to the document using `document.write`.


We should note that this is already not guaranteed to work in Chrome, because of WICG/interventions#17 -- so hopefully sites are already discouraged from implementing critical functionality via document.write of script content.

The difference with this proposal is that the embedder now has some control of whether or not the write will succeed, rather than just the user agent.

Thanks. Added a few lines here.

annevk · 2018-06-05T14:50:04Z

I think it's close enough (don't forget document.writeln()!). I suspect the variant of document.open() that's actually window.open() won't be blocked by this? This'll require careful integration with HTML.

Addressing comments, fixing typos, and more importantly renaming the feature from `document-stream-insertion` to `document-write`.

ehsan-karamad · 2018-06-05T15:56:35Z

Just to confirm and clarify, this feature does not block the variant of document.open with 3+ args which would actually do window.open (link).

ojanvafai · 2018-06-06T23:47:27Z

You can already do the opening behavior with window.open. Is there a specific reason to continue to allow it with document.open? I think it's pretty subtle and confusing to have the API partially function and would be better for us to keep it simple that all uses of document.open fail.

annevk · 2018-06-07T06:00:38Z

@ojanvafai blocking both requires two checks (one for each algorithm), as they're different methods do to IDL overloading. Therefore it might also be a tad confusing, but it seems fine to block both to me.

ehsan-karamad · 2018-06-07T15:33:04Z

Both variants of document.open() (returning window v/s document) are explained in the "dynamic markup insertion" section of the sepc, therefore, so far as the promise of the feature goes, we could block both. That said our current implementation in chrome (behind flag) does not block the variant returning window.

It was proposed here w3c/webappsec-permissions-policy#172 that "document-write" is a better name for this feature. This CL makes the naming change correspondingly. Bug: 841605 Change-Id: Id0a928fd3f6669eb3700736ff5770d4717d2b414

It was proposed here w3c/webappsec-permissions-policy#172 that "document-write" is a better name for this feature. This CL makes the naming change correspondingly. Bug: 841605 Change-Id: Id0a928fd3f6669eb3700736ff5770d4717d2b414 Reviewed-on: https://chromium-review.googlesource.com/1095328 Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Nasko Oskov <nasko@chromium.org> Cr-Commit-Position: refs/heads/master@{#566829}

clelland · 2018-06-27T13:12:28Z

Merged into master as ca24bf4

…nsertion, a=testonly Automatic update from web-platform-testsRename Feature Policy: document-stream-insertion It was proposed here w3c/webappsec-permissions-policy#172 that "document-write" is a better name for this feature. This CL makes the naming change correspondingly. Bug: 841605 Change-Id: Id0a928fd3f6669eb3700736ff5770d4717d2b414 Reviewed-on: https://chromium-review.googlesource.com/1095328 Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Nasko Oskov <nasko@chromium.org> Cr-Commit-Position: refs/heads/master@{#566829} -- wpt-commits: a0272053ab1712be6bf6b967ce75797b351001fc wpt-pr: 11463 --HG-- rename : testing/web-platform/tests/feature-policy/experimental-features/resources/document-stream-insertion.html => testing/web-platform/tests/feature-policy/experimental-features/resources/document-write.html

…nsertion, a=testonly Automatic update from web-platform-testsRename Feature Policy: document-stream-insertion It was proposed here w3c/webappsec-permissions-policy#172 that "document-write" is a better name for this feature. This CL makes the naming change correspondingly. Bug: 841605 Change-Id: Id0a928fd3f6669eb3700736ff5770d4717d2b414 Reviewed-on: https://chromium-review.googlesource.com/1095328 Commit-Queue: Ehsan Karamad <ekaramadchromium.org> Reviewed-by: Ian Clelland <iclellandchromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Reviewed-by: Nasko Oskov <naskochromium.org> Cr-Commit-Position: refs/heads/master{#566829} -- wpt-commits: a0272053ab1712be6bf6b967ce75797b351001fc wpt-pr: 11463 UltraBlame original commit: 40f42f669a0b67e18bbc3beb3ac706bfb6cbb53a

clelland reviewed Jun 5, 2018

View reviewed changes

Update document_stream_insertion.md

75812ee

Addressing comments, fixing typos, and more importantly renaming the feature from `document-stream-insertion` to `document-write`.

ehsan-karamad changed the title ~~Introduce Feature policy : document-stream-insertion~~ Introduce Feature policy : document-write Jun 5, 2018

chromium-wpt-export-bot mentioned this pull request Jun 11, 2018

Rename Feature Policy: document-stream-insertion web-platform-tests/wpt#11463

Merged

clelland closed this Jun 27, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce Feature policy : `document-write` #172

Introduce Feature policy : `document-write` #172

ehsan-karamad commented Jun 4, 2018

annevk commented Jun 5, 2018

clelland commented Jun 5, 2018

clelland Jun 5, 2018

ehsan-karamad Jun 5, 2018

clelland Jun 5, 2018

ehsan-karamad Jun 5, 2018

clelland Jun 5, 2018

ehsan-karamad Jun 5, 2018

clelland Jun 5, 2018

ehsan-karamad Jun 5, 2018

annevk commented Jun 5, 2018

ehsan-karamad commented Jun 5, 2018

ojanvafai commented Jun 6, 2018

annevk commented Jun 7, 2018

ehsan-karamad commented Jun 7, 2018

clelland commented Jun 27, 2018


		## Solution

		When the feature is disabled for a specific origin in a frame, any occurance of such API will be ignored and might

Introduce Feature policy : document-write #172

Introduce Feature policy : document-write #172

Conversation

ehsan-karamad commented Jun 4, 2018

annevk commented Jun 5, 2018

clelland commented Jun 5, 2018

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 Jun 5, 2018

ehsan-karamad commented Jun 5, 2018

ojanvafai commented Jun 6, 2018

annevk commented Jun 7, 2018

ehsan-karamad commented Jun 7, 2018

clelland commented Jun 27, 2018

Introduce Feature policy : `document-write` #172

Introduce Feature policy : `document-write` #172