| 06:14 | <Domenic> | Does anyone know if anything specifies what should happen when the user closes their browser? |
| 06:14 | <Domenic> | e.g. should unload handlers run |
| 06:14 | <Domenic> | beacons, <a ping>s etc |
| 06:41 | <annevk> | Domenic: we only vaguely define that for browsing contexts |
| 06:42 | <annevk> | Domenic: lifecycle of documents/windows is terrible though |
| 06:42 | <Ms2ger> | Ask hsivonen about it :) |
| 06:42 | <botie> | will do |
| 06:42 | <Ms2ger> | Oops |
| 06:49 | <annevk> | Domenic: about upload streams, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322 is relevant |
| 06:49 | <annevk> | Domenic: it seems browsers are widely inconsistent (and XMLHttpRequest is too) about progress event listeners for uploads |
| 06:50 | <annevk> | Domenic: that doesn't really diminish the chunked encoding aspect, but given H2 has different framing perhaps that isn't as much of an issue (although we should still make sure of course) |
| 06:50 | <Domenic> | hmm hmm |
| 06:50 | <Domenic> | Not really sure what to make of it... |
| 06:51 | <Domenic> | This HEIST attack makes me feel like I don't understand the constaints anymore :( |
| 06:52 | <annevk> | The constraints are basically anything that isn't possible using <form>, <a>, <img>, <object>, with some exceptions that we've added over the years |
| 06:53 | <annevk> | Anyway, happy to help with more specific questions, not sure I can do the whole thing here from first principles |
| 06:55 | <Domenic> | Yeah, just unsure how we missed those constraints with fetch (and/or resource timing?) |
| 06:56 | <annevk> | Well, there's not a whole lot of people that understand the same-origin policy, and it's also rather complicated |
| 06:57 | <annevk> | With fetch() the problem was that we added a feature, "no-cors", and only thought about protecting the response |
| 06:57 | <annevk> | But we didn't protect against when we'd reveal there is a response |
| 06:57 | <annevk> | So that's rather subtle, but it's arguably a problem |
| 06:57 | <constant> | howdy - could I please be invited to the whatwg github org? |
| 06:58 | <annevk> | However, if we fix that problem service workers will stream those kind of responses a little slower to the page, potentially delaying the rendering of images and such |
| 06:58 | <annevk> | constant: have you contributed in the past or is there a particular reason? |
| 06:58 | <constant> | I've contributed in the past |
| 06:59 | <variable> | and will likely contribute more in the future |
| 06:59 | <variable> | sporadically though :) |
| 06:59 | <annevk> | variable: are you https://github.com/constant? |
| 06:59 | <variable> | no, I'm 'grimreaper' |
| 06:59 | <annevk> | ah okay |
| 07:01 | <annevk> | variable: done btw |
| 07:01 | <variable> | tyvm |
| 07:01 | <variable> | fancy :) |
| 07:17 | <annevk> | I wonder if that person knew membership was not a requirement to post |
| 07:18 | <Domenic> | They were posting on some threads I think |
| 07:18 | <Domenic> | Probably they just wanted the cool GitHub profile badge? |
| 07:19 | <annevk> | We do have the coolest badge |
| 08:04 | <annevk> | Domenic: https://github.com/whatwg/fetch/issues/355 describes this new attack briefly in the third comment |
| 08:31 | <mkwst> | annevk: Building Fetch, I'm getting an xref error for "handle foreign fetch". |
| 08:32 | <mkwst> | Is there anything I need to do to update xrefs other than just pulling down the repository? |
| 08:40 | <annevk> | mkwst: sorry, committed the latest |
| 08:41 | <annevk> | mkwst: git pull on whatwg/xref should do it |
| 08:41 | <mkwst> | Easy, thanks! |
| 08:54 | <annevk> | mkwst: the @ goes before the name, fwiw |
| 08:59 | <mkwst> | Hrm? |
| 09:00 | <annevk> | mkwst: you wrote annevk@ on GitHub |
| 09:00 | <annevk> | mkwst: and tabatkins@ |
| 09:00 | <mkwst> | Ah! I just fixed that. ;) |
| 09:01 | <annevk> | mkwst: thoughts on https://www.w3.org/Bugs/Public/show_bug.cgi?id=20322 by any chance? |
| 09:01 | <mkwst> | I didn't pay much attention to the column width, no. I'll clean that up. I just wanted to see if you would be sad about the patch in general before spending too much time on it. |
| 09:01 | <annevk> | mkwst: we should probably sort out what we do there and what we want to do there and then apply it to streams |
| 09:01 | <annevk> | mkwst: nah that patch looks fine, will make it easier to transition to bikeshed at some point |
| 09:02 | <mkwst> | annevk: Ok. Then I'll clean it up and send you more when I have downtime. It's a nice brainless thing to do while waiting for things to compile and tests to run. |
| 09:02 | <mkwst> | Looking at the bug now. |
| 09:19 | <mkwst> | annevk: I wouldn't be terribly surprised if Chrome's behavior had shifted in the last few years. :) |
| 09:19 | <mkwst> | Let me see what we're doing today. |
| 09:28 | <mkwst> | http://w3c-test.org/cors/late-upload-events.htm <-- Firefox and Chrome both agree that the first test passes, and the second fails. |
| 09:33 | <mkwst> | same in Edge. |
| 09:41 | <annevk> | Yeah, I'm not sure that test is really testing anything though |
| 09:42 | <annevk> | See https://bugzilla.mozilla.org/show_bug.cgi?id=1254382#c18 |
| 10:56 | <smaug____> | Domenic: FWIW, I don't know the context in https://github.com/w3c/webcomponents/issues/537 Like, why is document.write disabled at all there? |
| 10:57 | <smaug____> | I assume letting document.write to be called would make parsing algorithm more complicated or something, but not sure. |
| 11:28 | <annevk> | JakeA: why do you bring up images in https://github.com/whatwg/fetch/issues/355#issuecomment-237813169? |
| 11:28 | <annevk> | JakeA: and what is a "supported image header"? |
| 11:29 | <JakeA> | annevk: I thought that was one of the avenues for response end? |
| 11:29 | <annevk> | JakeA: also, what do you mean by "Hm, ok, so it does require two requests."? The attack currently doesn't, although they perform multiple to get more accuracy |
| 11:29 | <annevk> | JakeA: so is <object> or <iframe> |
| 11:30 | <JakeA> | annevk: most image formats can be detected in the first few bytes, so if it isn't a valid image, we can bail early |
| 11:30 | <JakeA> | Are object/iframe accurate enough? |
| 11:30 | <annevk> | JakeA: I'm not sure why they wouldn't be |
| 11:31 | <JakeA> | annevk: I'm struggling to see the attack where you can get header time & body in one fetch() |
| 11:31 | <annevk> | JakeA: through response timing |
| 11:32 | <annevk> | JakeA: I've said it every other comment or so, it's also in the paper |
| 11:35 | <JakeA> | annevk: in didn't realise you'd get response end unless the body was consumed |
| 11:36 | <annevk> | JakeA: I don't follow the "unless" |
| 11:37 | <JakeA> | annevk: if I do fetch(url), but then don't consume the body of the response, it doesn't seem like response ended |
| 11:37 | <JakeA> | Since it was never given to anything that wanted to read it |
| 11:38 | <JakeA> | (unless you used it in a service worker and responsed with it, then an img may read it) |
| 11:38 | <annevk> | JakeA: resource timing is just concerned with network traffic |
| 11:38 | <JakeA> | Giving that data for no-cors seems broken |
| 11:39 | <annevk> | Maybe, but such data can already be gotten through other means |
| 11:39 | <annevk> | E.g., <object> |
| 11:39 | <JakeA> | Right, but in that case it needs to be two requests right? |
| 11:39 | <annevk> | What is new is responseStart for no-cors |
| 11:40 | <annevk> | Just one request to get responseEnd, just like today |
| 11:40 | <JakeA> | Padding onload times for object/iframe/cache add seems doable |
| 11:40 | <annevk> | I think the paper said that was unlikely to work, but that's again not solving the root cause |
| 11:41 | <annevk> | The root cause is no-cors fetch() being a new capability |
| 11:41 | <JakeA> | And we're sure this problem doesn't already exist with cors requests rejecting? |
| 11:41 | <annevk> | If we fix symptoms it's likely we'll find ourselves having this discussion again some time from now |
| 11:42 | <annevk> | Those requests include an Origin header |
| 11:42 | <annevk> | But we should investigate and discuss with the authors of the paper |
| 11:43 | <JakeA> | Feels like your proposed fix will have a big impact on service worker performance |
| 11:43 | <JakeA> | No more streaming for no-cors |
| 11:44 | <annevk> | Yeah, sucks, but this leak is pretty bad |
| 11:47 | <JakeA> | annevk: another option is for no-cors to always resolve instantly. Then you lose detecting a fetch failure |
| 11:48 | <JakeA> | But keep performance |
| 11:50 | <annevk> | JakeA: I'm not sure what that means |
| 12:07 | <JakeA> | annevk: I'm typing while walk, sorry, will type up thoughts properly tomorrow morning |
| 12:09 | <JakeA> | (thought was fetch() would instantly resolve with an opaque response if no-cors and cross-origin. That opaque response may be an error) |
| 12:11 | <annevk> | That doesn't really help, we can already figure out if the resource exists |
| 12:11 | <annevk> | We're not defending against that |
| 12:34 | <JakeA> | I realise that, but it also defends against knowing when headers arrive, but doesn't prevent response streaming from a service worker |
| 12:39 | <annevk> | JakeA: don't we expose url on the response? |
| 12:39 | <annevk> | JakeA: and we might expose status |
| 12:39 | <annevk> | JakeA: wouldn't work with too early, only late |
| 12:40 | <JakeA> | Yeah :( |
| 12:40 | <JakeA> | Would have to make breaking changes to make it work |
| 13:33 | <wanderview> | annevk: we don't expose url and status on opaque responses, though |
| 13:34 | <wanderview> | JakeA: resolving immediately here would require your theorized "isResponseOk()" thing to be async... for detecting something that would cause respondWith() to fail |
| 13:47 | <JakeA> | Yep. And I guess that would have to buffer the whole body if the response is ok |
| 13:49 | <JakeA> | Static routes wouldn't have this problem :D |
| 13:59 | <wanderview> | annevk: JakeA: I think part of the problem with resolving opaque responses immediately is you may not know its opaque until after some network traffic... think a same-origin request.url that is redirected cross-origin... for a no-cors request that gives you opaque |
| 13:59 | <wanderview> | if its ok to resolve as soon as we determine it will be opaque, then it could probably work |
| 13:59 | <wanderview> | I believe all the consumers of opaque responses are async |
| 14:00 | <wanderview> | so opaque responses could contain an internal "response is really available" promise... any async API accepting an opaque response would just do their normal async logic waiting on that internal promise |
| 14:00 | <wanderview> | although I guess this issue makes it harder to resolve immediately: https://github.com/whatwg/fetch/issues/357 |
| 14:15 | <annevk> | wanderview: I thought we did expose url, hmm |
| 14:16 | <wanderview> | annevk: thats only on opaqueredirect... opaque exposes nothing |
| 14:46 | <tobie> | Anyone can point me to an HTML diff tool that wouldn't choke on custom elements? (I have some <emu-val> in my HTML.) |
| 14:48 | <tobie> | Context: I'm trying to clean-up the output of XSLT transform with a custom script and wan't to make I don't modify the HTML by doing so. |
| 15:03 | <annevk> | wanderview: not even whether it's redirected? |
| 15:04 | <annevk> | wanderview: I thought we did expose that |
| 15:04 | <wanderview> | annevk: redirected is based off the URL list... its hidden: https://fetch.spec.whatwg.org/#concept-filtered-response-opaque |
| 15:05 | <annevk> | wanderview: yeah, I noticed, but I wonder if that's correct |
| 15:05 | <wanderview> | seems consistent to me |
| 15:05 | <wanderview> | and its what we are shipping |
| 15:06 | <annevk> | wanderview: https://github.com/whatwg/fetch/commit/e54f6bd1e75f46cd4b8202f5ee3bfa68e9ded906 mentions it fixes https://github.com/whatwg/fetch/issues/79 so it was meant to expose redirects for opaque responses |
| 15:06 | <annevk> | wanderview: so that seems like a bug in the spec |
| 15:06 | <annevk> | wanderview: I'll reopen the issue |
| 15:07 | <wanderview> | annevk: we internally still do the check for redirected opaque responses... its just not exposed to script |
| 15:07 | <wanderview> | annevk: I don't follow where it says it was supposed to be exposed to script in those links |
| 15:07 | <annevk> | wanderview: the issue reads "Add a bit to Opaque Responses to distinguish redirects" |
| 15:08 | <wanderview> | annevk: we look at the URL list of the unfiltered internal object to implement that bit... but its *not* exposed to script AFAICT... and I don't see why we would want to |
| 15:08 | <annevk> | wanderview: because that issue wants it to be exposed? |
| 15:09 | <annevk> | wanderview: and because we determined in that issue that there's no foul in exposing it? |
| 15:09 | <annevk> | Anyway, I reopened the issue |
| 15:12 | <wanderview> | annevk: I don't think we need to expose this to script... the currently implemented spec blocks the exploit linked to in that issue |
| 15:12 | <wanderview> | annevk: and I haven't been able to find anything about why it would need to be exposed to script anyway... we just need to track it internally and check in respondWith() |
| 15:12 | <wanderview> | annevk: please don't change this without a good reason |
| 15:13 | <annevk> | wanderview: slightlyoff gives several reasons there |
| 15:13 | <annevk> | wanderview: you can already determine it |
| 15:13 | <annevk> | wanderview: if you want to argue for removing the API since you only need the internal bit, that's fine |
| 15:14 | <annevk> | wanderview: and I suggested as much since nobody noticed the original request went unaddressed |
| 15:14 | <annevk> | wanderview: but the issue asked about redirected being exposed for opaque responses |
| 15:14 | <annevk> | wanderview: what you're talking about is a bit that existed long before that |
| 15:14 | <wanderview> | annevk: its nice to have the getter for same-origin and cors... I see no reason to provide an exception to our previous model for opaque |
| 15:15 | <annevk> | wanderview: I'm not sure what model you're referring to |
| 15:15 | <wanderview> | annevk: and I don't really care what the original request was in the issue... only that the exploit is no longer feasible |
| 15:15 | <wanderview> | annevk: the model of "don't expose anything on opaque... make it identical to a network error" |
| 15:15 | <wanderview> | we've been consistent in that throughtout |
| 15:16 | <annevk> | wanderview: a network error doesn't surface as a response, so that isn't really true anyway |
| 15:17 | <wanderview> | annevk: I'm talking about this spec non-normative note: In other words, an opaque filtered response and an opaque-redirect filtered response are nearly indistinguishable from a network error. When introducing new APIs, do not use the internal response for internal specification algorithms as you will leak information. |
| 15:17 | <wanderview> | annevk: which is in the spec... I think you know what I mean |
| 15:19 | <annevk> | Sure, but I still don't see why we'd have redirected then, you can just compare the response url to the request url for same-origin/cors; the only interesting case is opaque |
| 15:20 | <annevk> | And I think we've been okay with making some exceptions to the network error comparison when it's clearly observable |
| 15:20 | <wanderview> | annevk: because you may not have the request in the code examining the response? |
| 15:20 | <annevk> | E.g. that's why opaque redirects expose the url field |
| 15:26 | <wanderview> | annevk: if you want to remove the .redirected I guess I don't mind... I'm just opposed to exposing the actual .redirected value on opaque responses |
| 15:28 | <annevk> | wanderview: on the grounds that opaque responses should never have properties that return something meaningful? |
| 15:28 | <annevk> | wanderview: it's a little hard to understand the motivation |
| 15:29 | <wanderview> | annevk: to be consistent with the principal that we expose no information on opaque responses that we've had since day one... because we're being defensive and don't fully understand the implications of allowing no-cors fetch |
| 15:29 | <wanderview> | annevk: I mean... we're in a condition now where we are trying to remove information (timing) of opaque... I think its not wise to then add more information to opaque |
| 15:30 | <annevk> | Yeah, we should certainly first figure out that in depth before turning this around |
| 15:31 | <annevk> | Hopefully Chrome implements redirected in the same way |
| 15:34 | <wanderview> | anyway, thats my motivation |
| 16:00 | <gsnedders> | annevk: am I right in thinking most of the recent security issues around the same-origin policy have been using side-channels? |
| 16:00 | <gsnedders> | annevk: like, say, the timing sidechannel of the most recent attack (or is that not the most recent anymore, idk)? |
| 16:05 | <annevk> | gsnedders: in a way |
| 16:06 | <annevk> | gsnedders: I guess the question is when a sidechannel becomes data |
| 16:07 | gsnedders | would simply call anything outwith the request/response contents a sidechannel |