- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Sat, 14 Nov 2015 13:26:11 -0800
- To: Joel Weinberger <jww@chromium.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Artur Janc <aaj@google.com>
> - document.cookie is necessary for applications to keep working without > requiring users to sign into every part of your website separately. > Security-wise it's on par with existing behavior (cookies being shared > between subdomains) so we believe it's a reasonable default. That having > been said, I wouldn't be surprised based on comments from Dev that we'll > eventually want to build an opt-out to give a Suborigins a unique cookie > jar. Would a cookie set by top level domain be readable though? That's what was I was really not ok with and that is also not par with current sub-domain behavior. Additionally, I like the current sub-domain behavior has been a forever source of pain and so extending it doesn't sound like a great idea. I can understand this being a requirement though. I am just not a fan of making it the default. Allowing it through some 'unsafe-cookie' sort of opt-in (an opt-in we make mandatory in v1) seems more reasonable to me. > In the case of XHR/Fetch, our solution is to send a CORS preflight for all > XHR/Fetch calls from a Suborigin, and we'll add a Suborigin header. Then > we'll require that the response has an Access-Control-Allow-Suborigin header > that lists the requesting Suborigin (or, alternatively, a '*' response to > Access-Control-Allow-Origin). This seems a big hammer. While secure, the perf impact of pre-flight is terrible and applications go out of their way with some horrible hacks to avoid it. At the least, why not inherit existing behavior: preflight only for complex requests? Also, how will * response work? Will the request be sent with a cookie? Does the app set request.withCredentials to false? How would the app know whether it is running in a browser with subOrigin support and needs to set that flag? > Importantly, the app > will need to have the cookie because otherwise you'd stop being logged in > and it would suck for usability. I am still confused why the app needs document.cookie though. The cookie is sent with the request. ~dev
Received on Saturday, 14 November 2015 21:26:59 UTC