search

w3c / wpub

W3C Web Publications
https://w3c.github.io/wpub/
Other
79 stars 19 forks source link

Reference to opaque origin in the manifest lifecycle #343

Closed iherman closed 6 years ago

iherman commented 6 years ago

Adopted the change proposal of @JayPanoz. This replaces the (opaque:-) reference to an opaque origin...

Some issues on security must be addressed in the security section, too, which may, eventually, add some more text to the lifecycle section. But this PR seems to provide a proper intermediate stage.

Fix #321

Cc: @JayPanoz, @rdeltour @llemeurfr @dauwhe

Preview | Diff

mattgarrish commented 6 years ago

I'm not 100% sold on this, to be honest. Why select only one type of opaque origin to reject? data: URLs, srcdoc, createDocument() all seem like possible ways of generating an opaque-origin document that could attempt to initiate itself as a web publication, as we shouldn't only focus on what is common.

As I read the definition -- and I'm not claiming to be any kind of expert on this -- if a document has an opaque origin, its origin (document.origin) is set to NULL. Isn't that sufficient in terms of determining whether to terminate manifest processing? Only the browser developers really need to understand the finer details of calculating that origin.

JayPanoz commented 6 years ago

Yeah that was my preferred option as well.

That’s for implementers and It basically takes care of all the details for you, although the concept of “opaque origin” is complex to define/understand at first sight. My assumption is that it will be re-introduced at a later date anyway, because it does that.

Now, I can also understand the need for a temporary clarification, although I’m not comfortable with it – after all, it wasn’t at all in the W3C manifest at first and it could for instance buy some time to write some “companion doc”/wiki explaining how you may end up with an opaque origin and what it means in practice.

rdeltour commented 6 years ago

I agree with @mattgarrish.

Also, I'm wondering what we're trying to solve with this PR?

The Web App Manifest issues referenced by @jaypanoz in #321 are on point (especially w3c/manifest#668). I think we should carefully review what happens there, and possibly seek advice from experts (at TPAC?), before jumping into changing anything here.

My 2 cents ;-)

JayPanoz commented 6 years ago

@rdeltour Note opaque origin impacts media elements as well, audio in particular. But I can’t tell what’s happening there if the media element is CORS cross-origin.

Edit: so yeah restricted, cf. https://stackoverflow.com/a/27431853

iherman commented 6 years ago

O.k. I am fine closing this PR without merge, but I would also think that the comment of @mattgarrish (ie, https://github.com/w3c/wpub/pull/343#issuecomment-429814360) also holds, as an answer, to #321, which may have to be closed without further action, too (although it was very useful to have it, because it helped to clarify certain things and accept our own limitations:-)

Note that, as far as I understand, https://github.com/w3c/manifest/issues/668 is not fully relevant for us either. The manifest lifecycle in this draft is simplified, because there is no mention, in the case of the Web Manifest, of start_url, of the url where the application is to be installed, etc. In this respect, we are on a much simpler space.

JayPanoz commented 6 years ago

but I would also think that the comment of @mattgarrish (ie, #343 (comment)) also holds, as an answer, to #321, which may have to be closed without further action, too

LGTM.

(I did really think a lot about it recently but my view hasn’t change that much: I personally consider it a whole i.e. the Web Origin + its security policies so it’s probably more of an overarching concept.)

iherman commented 6 years ago

Closing the PR without further action.