- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 15 Apr 2015 07:16:33 +0200
- To: Domenic Denicola <d@domenic.me>
- Cc: Aaron Colwell <acolwell@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Matthew Wolenetz <wolenetz@google.com>, WHATWG <whatwg@whatwg.org>, Brad Hill <hillbrad@gmail.com>, Ryan Sleevi <sleevi@google.com>, "public-html-media@w3.org" <public-html-media@w3.org>
On Tue, Apr 14, 2015 at 9:38 PM, Domenic Denicola <d@domenic.me> wrote:
> I also imagine it won't be too hard to spec, as the point of an opaque stream type is that most of its methods consist of "magic happens here" (roughly speaking).
Well, we also need to ensure that nothing that takes a stream and then
exposes it either client or server-side (e.g. Request, Response,
fetch()) can handle them. (Which is a different primitive from what
Credential Management wants by the way, they just want to avoid
exposing the request body stream client-side, probably with the
exception of service workers.)
That is, the following should reject:
fetch(url, {mode:"no-cors"}).then(res => fetch(url2, {body:res.body}))
None of that should be particularly hard, though I do worry that the
further we get away from Response, the more we might lose sight of
what we are trying to protect and make mistakes.
(Perhaps the Credential Management case does not need to use streams
at all. We could extend FormData to have an opaque mode or some such.)
--
https://annevankesteren.nl/
Received on Wednesday, 15 April 2015 05:17:19 UTC