Allow payment requests for same origin-domain subdocuments #2217

zcorpan · 2016-12-27T08:24:21Z

This is on top of #2195.

Same origin-domain is used instead of same-origin to disallow by default if document.domain had been used in the parent document.

The origin check is part of the snapshot instead of live.

Browsing context containers other than iframe (e.g. object, embed, frame) that are same origin-domain are allowed to use payment request.

(I think ideally this should apply to allowfullscreen and allowusermedia as well, but I don't want to hold up allowpaymentrequest on compat concerns for allowfullscreen so focusing on just allowpaymentrequest right now.)

Please use #2184 for comments about the general approach/concerns, and comment here for editorial review.

Implementer sign-off:

Chromium: @rsolomakhin ? @clelland ?
Gecko: @bzbarsky ?
WebKit: @hober ?
Edge: @adrianba ?

annevk · 2016-12-28T11:53:09Z

source

+
+      <li><var>document</var>'s <span data-x="concept-document-bc">browsing context</span> has a
+      <span>browsing context container</span> whose <span>node document</span>'s <span>origin</span>
+      has the <span>same origin-domain</span> as <var>document</var>'s <span>origin</span></li>


Why not use same origin here? I think we should keep same origin-domain for legacy cases only.

See the issue for discussion with @bzbarsky. In particular using same-origin would allow cases where script DOM access is otherwise not allowed.

Right, similar to how access to the network or storage would remain "shared", but script access would not. I guess we could go either way... Or we could require both meaning that when you use document.domain you're out of luck with this feature, but that might not be compatible either.

Since it is snapshotted at document creation time it will not work if document.domain is used with the proposed spec. But it would work if "same origin" is used. So same origin-domain + snapshot allows fewer cases without the attribute.

I see, quite subtle!

I tried to clarify this a bit now.

annevk · 2016-12-28T13:29:00Z

LGTM, but it would be good to have tests (as noted by the label), but also some implementer sign-off. I have the feeling we'll keep tweaking these allow* attributes forever otherwise.

bzbarsky · 2016-12-29T20:11:36Z

This seems generally ok to me, but have you talked to the feature policy people about the origin-domain aspect of things?

zcorpan · 2016-12-29T22:29:12Z

@igrigorik @mikewest @raymeskhoury @ojanvafai @clelland

It would be good if the spec here for allowpaymentrequest could be described in terms of Feature Policy. Can you review this and make sure Feature Policy has the exact same behavior (or propose changes for this PR so they are the same)? Also see comments in #2184.

I would be happy to add any hooks to HTML that FP can use if necessary.

clelland · 2017-01-03T16:08:04Z

source

+
+      <li><var>document</var>'s <span data-x="concept-document-bc">browsing context</span> has a
+      <span>browsing context container</span> whose <span>node document</span>'s <span>origin</span>
+      has the <span>same origin-domain</span> as <var>document</var>'s <span>origin</span></li>


I think that "has the same origin-domain as" should probably read "is same origin-domain with" here.

I used the same wording as elsewhere in the spec.

Probably wrong elsewhere too then, since it's not really a property of origins, but a check you perform on them.

https://html.spec.whatwg.org/#svg-0:same-origin-domain is the only instance I could find with that wording; all the other cross-referenced uses seem to use some variant of "is same origin-domain with"

OK fixed. Thanks!

clelland · 2017-01-04T16:32:53Z

The wording seems good to me; Same origin-domain seems like the right boundary to be using.

I think this behavior matches the way that Feature Policy should work for allowpaymentrequest -- at least as far as the iframe attribute goes. There may be additional complications when we introduce policies via respone headers, but as long as we can amend this at that point, then this should be good right now.

(It would be great to eventually be able to define 'allowed to use' in terms of feature policy, but that spec isn't quite there yet.)

annevk · 2017-01-05T09:10:50Z

Thanks, @clelland do you think we should double check with @igrigorik or should we move ahead and merge?

foolip · 2017-01-05T14:38:07Z

source

+    <li>
+     <p>If <var>allowattribute</var> is <code
+     data-x="attr-iframe-allowfullscreen">allowfullscreen</code> or <code
+     data-x="attr-iframe-allowusermedia">allowusermedia</code>, then follow these substeps:</p>


Since nobody has shipped allowusermedia we can probably exclude it here.

igrigorik · 2017-01-05T18:19:06Z

The wording seems good to me; Same origin-domain seems like the right boundary to be using.

Ditto.

raymeskhoury · 2017-01-09T03:31:00Z

Sorry for being slow to the thread and if this is a silly question, but I'm unsure why we want to check for same origin-domain as opposed to same-origin?

annevk · 2017-01-09T08:24:09Z

@raymeskhoury it was discussed in #2184 (comment). Since the check is made during document creation using same origin-domain will allow slightly less than using same-origin would. In particular if the parent had already set document.domain it would not be treated as same-origin.

The argument was made that this would be slightly better since the documents can't access each other through script in that case either.

raymeskhoury · 2017-01-10T05:18:19Z

Ah so using same origin-domain would be less permissive in this case?

I was just looking at the definition of same origin-domain here: https://w3c.github.io/html/browsers.html#same-origin-domain and it seemed to indicate that origins with different ports would compare equal, which would be more permissive. Will that apply in this case? Is that what we want?

annevk · 2017-01-10T08:25:22Z

It would be less permissive because in this case the child global cannot have document.domain set yet. Therefore if the parent global did have document.domain set, its origin's domain would be non-null and it could never be same-origin domain with its child. And if neither has document.domain set, their origins' domain would be null and therefore you'd have to do a normal same origin check which does take the port into account.

(Also, you want https://html.spec.whatwg.org/multipage/browsers.html#same-origin-domain but it happens they're the same in this case I think.)

domenic · 2017-01-10T14:05:00Z

IMO we should include a note outlining all the less-permissive-vs.-more-permissive things we've discovered here. Maybe with an example or three.

annevk · 2017-01-10T14:06:56Z

There is a note explaining it.

domenic · 2017-01-10T14:09:15Z

Yes, I meant explicitly stating that using same origin-domain is less permissive than using same-origin, and perhaps giving an example of where that's the case.

clelland · 2017-01-10T14:38:13Z

It's only less permissive in the snapshotting case, right? In the general case, we can't say anything so definite, since it could either restrict communication between documents, or allow it when it wasn't otherwise possible.

(And, like @raymeskhoury, I originally thought that same origin-domain completely ignored ports, I had to re-read the wording carefully a couple of times to convince myself that it wasn't the case. An example to that end would be useful as well)

annevk · 2017-01-10T14:45:21Z

We're only discussing snapshotting here. In general same origin-domain should be avoided.

raymeskhoury · 2017-01-10T22:02:44Z

@annevk thanks for clarifying! Sorry for my lack of understanding. SGTM then. Any ways we can make it more obvious would be great though :)

See #2217 (comment)

zcorpan · 2017-01-10T23:06:28Z

OK added a new commit here with examples, and also a new PR with an example for ports at #2257

See #2217 (comment).

zcorpan · 2017-01-11T18:59:37Z

Sweet, still need to add tests. Plan in web-platform-tests/wpt#4526 (might not need all of these to merge this, but some of them at least)

domenic · 2017-01-13T22:26:46Z

I agree with @foolip's comment that we should also switch allowusermedia in this PR if possible.

…ents Fixes #2184.

zcorpan · 2017-01-25T10:22:42Z

I've squashed and rebased on master. Since we added allowusermedia to the snapshot model in #2195, it is now consistent with allowpaymentrequest for the same origin-domain thing as well. I would appreciate a new editorial review to make sure I didn't make a mistake here.

A first set of tests for allowpaymentrequest for this is in web-platform-tests/wpt#4615

annevk

Text LGTM. Haven't looked at anything else though.

annevk · 2017-01-25T11:15:11Z

source

@@ -28717,6 +28717,65 @@ interface <dfn>HTMLIFrameElement</dfn> : <span>HTMLElement</span> {
    <span>browsing context container</span> that is an <code>iframe</code> element, let
    <var>iframe</var> be that element. Otherwise, abort these steps.</p></li>

+    <li>
+


This newline can be removed.

zcorpan · 2017-01-25T13:19:15Z

I had missed to git add a fix I meant to have included (12a49c3).

zcorpan · 2017-01-25T14:12:08Z

Bugs:

https://bugs.chromium.org/p/chromium/issues/detail?id=682280
https://bugzilla.mozilla.org/show_bug.cgi?id=1318988
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10656915/
https://bugs.webkit.org/show_bug.cgi?id=167417
https://bugs.webkit.org/show_bug.cgi?id=167430

zcorpan · 2017-01-25T14:23:15Z

I think it is OK to merge this now.

annevk · 2017-01-25T14:38:32Z

I think so too. We got tests, bugs, and solid text. The only nitpick I have is that we should maybe also have allowusermedia tests, but implementers should still be writing tests too.

zcorpan · 2017-01-25T17:32:31Z

Filed web-platform-tests/wpt#4625 for testing allowusermedia.

See whatwg#2217 (comment).

zcorpan added the needs tests Moving the issue forward requires someone to write tests label Dec 27, 2016

annevk reviewed Dec 28, 2016

View reviewed changes

zcorpan mentioned this pull request Dec 28, 2016

Invoke "allowed to use" always w3c/payment-request#383

Merged

clelland reviewed Jan 3, 2017

View reviewed changes

zcorpan mentioned this pull request Jan 5, 2017

"Allowed to use" should allow same-origin without the attribute #2184

Closed

foolip reviewed Jan 5, 2017

View reviewed changes

zcorpan added a commit that referenced this pull request Jan 10, 2017

Add example for same origin-domain where ports are different

fe18512

See #2217 (comment)

zcorpan mentioned this pull request Jan 10, 2017

Add example for same origin-domain where ports are different #2257

Merged

annevk approved these changes Jan 11, 2017

View reviewed changes

annevk mentioned this pull request Jan 11, 2017

Iframe sandboxing options for gUM w3c/mediacapture-main#268

Closed

domenic pushed a commit that referenced this pull request Jan 11, 2017

Add example for same origin-domain where ports are different

17be896

See #2217 (comment).

zcorpan mentioned this pull request Jan 11, 2017

Add tests for allowing same-origin PaymentRequest in nested browsing contexts web-platform-tests/wpt#4526

Open

15 tasks

Allow PaymentRequest and getUserMedia for same origin-domain subdocum…

3aa2531

…ents Fixes #2184.

zcorpan force-pushed the zcorpan/allow-same-origin-allowpaymentrequest branch from f4dacfc to 3aa2531 Compare January 25, 2017 10:14

annevk approved these changes Jan 25, 2017

View reviewed changes

Reorder steps to allow same origin non-iframe BC; remove a newline

12a49c3

zcorpan removed the needs tests Moving the issue forward requires someone to write tests label Jan 25, 2017

annevk approved these changes Jan 25, 2017

View reviewed changes

zcorpan mentioned this pull request Jan 25, 2017

Test <iframe allowusermedia> web-platform-tests/wpt#4625

Closed

zcorpan merged commit ffae698 into master Jan 25, 2017

zcorpan deleted the zcorpan/allow-same-origin-allowpaymentrequest branch January 25, 2017 17:36

clelland mentioned this pull request Dec 20, 2017

allowlist same-origin domain w3c/webappsec-permissions-policy#107

Closed

alice pushed a commit to alice/html that referenced this pull request Jan 8, 2019

Add example for same origin-domain where ports are different

b2e8113

See whatwg#2217 (comment).

Allow payment requests for same origin-domain subdocuments #2217

Allow payment requests for same origin-domain subdocuments #2217

Conversation

zcorpan commented Dec 27, 2016 • edited by domenic 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

annevk commented Dec 28, 2016

bzbarsky commented Dec 29, 2016

zcorpan commented Dec 29, 2016

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

clelland commented Jan 4, 2017

annevk commented Jan 5, 2017

Choose a reason for hiding this comment

igrigorik commented Jan 5, 2017

raymeskhoury commented Jan 9, 2017

annevk commented Jan 9, 2017 • edited Loading

raymeskhoury commented Jan 10, 2017

annevk commented Jan 10, 2017

domenic commented Jan 10, 2017

annevk commented Jan 10, 2017

domenic commented Jan 10, 2017

clelland commented Jan 10, 2017

annevk commented Jan 10, 2017

raymeskhoury commented Jan 10, 2017

zcorpan commented Jan 10, 2017

zcorpan commented Jan 11, 2017

domenic commented Jan 13, 2017

zcorpan commented Jan 25, 2017

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan commented Jan 25, 2017

zcorpan commented Jan 25, 2017 • edited Loading

zcorpan commented Jan 25, 2017

annevk commented Jan 25, 2017

zcorpan commented Jan 25, 2017

zcorpan commented Dec 27, 2016 •

edited by domenic

Loading

annevk commented Jan 9, 2017 •

edited

Loading

zcorpan commented Jan 25, 2017 •

edited

Loading