Closed devd closed 7 years ago
We started addressing this in #31.
I think we figured out most of the issues in #31, but the Host prefix question is still a good one, so I'm going to rename this issue to reflect that in particular.
Personally, I think the unsafe-cookies
option is, well, unsafe, and for simplicity's sake, we should just straight treat the suborigin as the physical origin in all ways when it comes to cookies, thus the Host prefix would treat the suborigin as same-origin. Thoughts?
Sgtm.. if we decide that better control is needed, we can create a new flag in future versions of the spec. Keeping it simple here is worthwhile.
On Sep 30, 2016 10:43 AM, "Joel Weinberger" notifications@github.com wrote:
I think we figured out most of the issues in #31 https://github.com/w3c/webappsec-suborigins/pull/31, but the Host prefix question is still a good one, so I'm going to rename this issue to reflect that in particular.
Personally, I think the unsafe-cookies option is, well, unsafe, and for simplicity's sake, we should just straight treat the suborigin as the physical origin in all ways when it comes to cookies, thus the Host prefix would treat the suborigin as same-origin. Thoughts?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/webappsec-suborigins/issues/28#issuecomment-250807364, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIXGeOdgab1FAvXwJYron7x5nhnfx2dks5qvUpKgaJpZM4HsS9z .
closing per above .. unsafe cookies flag is unsafe. #yolo
We need to define an optout which removes the suborigins separate cookie jar and ties the cookie jar (both from set-cookie header and the document.cookie API) to the physical origin.
One question is what we want to do with Host prefixed cookies.