| 01:27 | <heycam> | tobie: ok, will look today |
| 02:38 | <MikeSmith> | TabAtkins: thanks for the feedbak about the validator bug Bert raised |
| 02:40 | <not-an-aardvark> | Is there a way for a server to block all cross-origin fetch requests with credentials? |
| 02:41 | <not-an-aardvark> | I'm aware that code on the other site can't see the response due to the same-origin policy, but I'm concerned that it's able to figure out other data about the request, such as whether the request is redirected. |
| 02:49 | <MikeSmith> | not-an-aardvark: why can' |
| 02:49 | <MikeSmith> | oofs |
| 02:50 | <MikeSmith> | not-an-aardvark: why can’t server just look at the origin of the request and the headers and then just respond with 403 or whatever |
| 02:51 | <MikeSmith> | anyway it seems like there’s nothing that browsers do that would prevent it, and nothing in any specs for the platform that would prevent it |
| 02:53 | <not-an-aardvark> | Do you mean looking at the Referer header? |
| 02:55 | <not-an-aardvark> | The issue with Referer checking is that the site still needs to be able to handle the case where a user clicks a link from another site without returning a 403. |
| 02:57 | <not-an-aardvark> | My concern is that giving a site the ability to determine whether a credentialed cross-origin request resulted in a redirect seems like a violation of the same-origin policy. |
| 03:00 | <not-an-aardvark> | That would imply that a site can't safely have a redirect available only to specific user sessions, because another site would be able to detect whether the user's request results in a redirect. |
| 03:02 | <MikeSmith> | maybe I am being daft but the same-origin policy doesn’t apply on the server side. It is strictly a client-side restriction in browsers. A fact of life for browsers. It is not a general policy meant to restrict what you can do in your server code. |
| 03:04 | <not-an-aardvark> | My original question was concerning whether it would be possible for a server to distinguish between (a) cross-origin fetch requests with credentials, and (b) any other requests. This would allow the server to always reject the former, which would allow safe user-specific redirects in other scenarios. |
| 03:05 | <not-an-aardvark> | This would be as a workaround for the same-origin policy issue that I mentioned above. |
| 03:05 | <MikeSmith> | ok |
| 03:07 | <MikeSmith> | well if you can wait around for a few more hours you can probably get a better answer from annevk |
| 03:07 | <MikeSmith> | otherwise this time of day this channel is not very active in general |
| 03:07 | <not-an-aardvark> | 👍, thanks for the response anyway |
| 06:05 | <annevk> | not-an-aardvark: not possible |
| 06:06 | <annevk> | not-an-aardvark: you want samesite cookies or whatever the name is these days |
| 06:06 | <annevk> | not-an-aardvark: but only Chrome supports them |
| 06:07 | <not-an-aardvark> | That's unfortunate. Thanks for the answer though. |
| 06:07 | <not-an-aardvark> | What was the reasoning for that decision when fetch was created? It seems inconsistent with how the same-origin policy works in other contexts. |
| 06:55 | <annevk> | not-an-aardvark: what do you mean? It's no different from <img src=http://crossorigin/>; |
| 06:59 | <not-an-aardvark> | With <img src="http://crossorigin/"/>;, a script doesn't know anything about the response. With fetch('foo', {credentials: 'include', mode: 'no-cors', redirect: 'error'}), a script can determine whether the user's credentials cause a redirect. |
| 07:02 | <not-an-aardvark> | Granted, I suppose a script can detect a 404 response with img from the onerror handler. But that information leak is restricted only to endpoints that sometimes have valid images, since a 404 error and a response containing something other than an image are indistinguishable to the client (assuming X-Content-Type-Options is enabled) |
| 07:06 | <annevk> | not-an-aardvark: you can determine a 404 reliably with <object>, iirc |
| 07:11 | <annevk> | not-an-aardvark: good question about redirects though |
| 07:11 | <annevk> | not-an-aardvark: I thought those could be observed, but I cannot remember how |
| 07:12 | <annevk> | not-an-aardvark: that is, I thought you could observe a redirect was made |
| 07:15 | <not-an-aardvark> | Fair enough, but 404 information leaks from <object> and <iframe> can be prevented by the server with X-Frame-Options. It doesn't seem like there is any way to avoid information leaks from redirects in this case. |
| 07:15 | <annevk> | not-an-aardvark: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site is the tool basically |
| 07:16 | <annevk> | not-an-aardvark: redirects were indeed exposed as part of service workers, to be able to handle navigation |
| 07:16 | <annevk> | not-an-aardvark: but timing attacks would already make it possible to observe them |
| 07:17 | <annevk> | not-an-aardvark: this is basically yet another variant of HEIST, which https://github.com/w3c/resource-timing/issues/64 has a pretty good discussion about what we can do standards-wise |
| 07:17 | <not-an-aardvark> | Fair enough, and thanks for the links. |
| 07:17 | <annevk> | not-an-aardvark: I'm sorry it all sucks |
| 07:18 | <not-an-aardvark> | :\ |
| 07:19 | <not-an-aardvark> | Same-site cookies look like they will basically solve the problem, but I would be worried about them being insecure in old browsers before they are widely adopted (since they would just get treated as regular cookies in old browsers) |
| 07:21 | <not-an-aardvark> | Anyway, thanks again for your help! |
| 08:25 | <tobie> | heycam: \o/ |
| 08:25 | <heycam> | tobie: haven't done anything yet though! :) and it's already 4:30pm... |
| 08:26 | <tobie> | heycam: yeah—don't worry. |
| 08:26 | <tobie> | heycam: I'm just getting really good a fixing broken merges. :D |
| 08:26 | <heycam> | hah |
| 08:26 | <heycam> | yeah, they're a pain :) |
| 08:27 | <heycam> | though must be better with bikeshed... |
| 08:27 | <heycam> | oh, this is the target .html file |
| 08:28 | <tobie> | yes |
| 08:28 | <tobie> | heycam: so it's OK when the branch you're trying to rebase is ahead by a single commit |
| 08:29 | <tobie> | heycam: it starts to be a lot more painful when there are multiple commits. |
| 08:29 | <heycam> | tobie: at least if there were no conflicts in the bikeshed file you can just blow away the index.html and rebuild it |
| 08:29 | <tobie> | you basically have to re-run bikeshed between each commit. |
| 08:29 | <heycam> | right |
| 08:29 | <heycam> | but yes, I'll look at this soon. and thanks Domenic for the detailed instructions, that should help :) |
| 08:30 | <tobie> | yes. but given there are never any conflicts in the .bs file, it makes a lot more sense to split these two operations |
| 08:30 | <tobie> | Cool |
| 08:42 | <tobie> | annevk: you had this webidl issue you wanted to talk to me about last week |
| 08:43 | <annevk> | tobie: I don't remember |
| 08:43 | <tobie> | annevk: I'll check the logs |
| 08:44 | <annevk> | tobie: it was about making progress on https://www.w3.org/Bugs/Public/show_bug.cgi?id=27301 |
| 08:45 | <tobie> | right |
| 08:45 | <annevk> | tobie: comment 5 is a good summary |
| 08:47 | <annevk> | tobie: so I guess there's not much left to discuss |
| 08:49 | <tobie> | annevk: oh--did comment 5 happen in the meantime? Thanks. I'll look into this. |
| 08:49 | <annevk> | tobie: yeah, Domenic happened |
| 08:50 | <tobie> | :) |
| 09:02 | <tobie> | I've been tinkering with the idea of adding "note to editors" in the WebIDL spec. Are there precedents that shows this is a bad idea? |
| 09:06 | <annevk> | tobie: there's some precedent, e.g., https://url.spec.whatwg.org/#url-apis-elsewhere |
| 09:07 | <annevk> | tobie: or https://dom.spec.whatwg.org/#defining-event-interfaces |
| 09:08 | <tobie> | annevk: I was even thinking of: <div class="note-for-editors"> |
| 09:09 | <tobie> | annevk: and also <div class="legacy"> with a [ ] hide legacy stuff checkbox at the top of the spec |
| 09:09 | <annevk> | tobie: both sound reasonable in principle |
| 09:09 | <tobie> | annevk: wrt to calling abstract operations with [=abstract op name=](arguments...), do we have a naming convention for the abstract ops? |
| 09:10 | <annevk> | tobie: UpperCamelCase |
| 09:10 | <tobie> | annevk: ok, so we should rename algos that way as we clean them up |
| 09:11 | <tobie> | cool |
| 09:11 | <annevk> | yeah |
| 09:21 | <tobie> | heycam: would be awesome if you could also add a link to the spec and its name at the top of the repo. I added a todo item to https://github.com/heycam/webidl/pull/221 to remind you. |
| 09:22 | <heycam> | ok, will do |
| 09:37 | <tobie> | ty |
| 09:40 | <tobie> | If I have: `interface A : B {};` are `attribute (A or B) foo;` and `attribute B foo;` the same or not at all? |
| 09:41 | <tobie> | I think I asked this question 10x already, so where is this explained in the spec would also help |
| 09:46 | <heycam> | tobie: in theory (A or B) is not legal, since those types are not distinguishable |
| 09:46 | <tobie> | heycam: but, but, but... |
| 09:46 | <heycam> | tobie: since the (a) footnote in the distinguishability table says that it must not be possible for an object to implement both interfaces, and likely it is |
| 09:48 | <tobie> | heycam: my brain refuses to compute that part of the spec. |
| 09:48 | <tobie> | heycam: I thought it was for operations only, not unions on attributes |
| 09:48 | <heycam> | tobie: each type in the union must be distinguishable from the others |
| 09:49 | <tobie> | heycam: oh |
| 09:49 | <heycam> | per the sentence in https://heycam.github.io/webidl/#idl-union that starts "each pair" |
| 09:49 | <tobie> | heycam: oh right, it says that. |
| 09:50 | <tobie> | heycam: so is there no way to say that an attribute can return a class or a subclass of that class? |
| 09:50 | <heycam> | tobie: no, but just "A" by itself means that, doesn't it? |
| 09:51 | <tobie> | heycam: that *was* my question |
| 09:51 | <tobie> | heycam: and the follow-up question is where is that mentioned in the spec? |
| 09:51 | <tobie> | heycam: or is it implicit |
| 09:52 | <heycam> | tobie: that A means "things that implement A or anything that derives from A"? |
| 09:55 | <heycam> | it might not be spelled out exactly. https://heycam.github.io/webidl/#idl-interface says that an interface type represents all objects that implement that interface, and there's kind of a definition of what "inherit" means for interfaces, but maybe nothing that states "if an object implements B and B inherits from A, then the object must also implement A" |
| 09:55 | <heycam> | oh, no there is such a sentence |
| 09:55 | <tobie> | heycam: tbh that's another part of the spec I that makes my head hurt |
| 09:55 | <heycam> | "An object that implements an interface that inherits from another also implements that inherited interface." |
| 09:55 | <heycam> | in https://heycam.github.io/webidl/#idl-interfaces |
| 10:03 | <nox> | Could someone walk me through the test "Namespace generally shouldn't matter" in domparsing/createContextualFragment.html? |
| 10:03 | <nox> | I don't understand why <body> should be parsed the same in a div and in a fake-namespace:div. |
| 10:04 | <nox> | AFAICT <body> in a fake-namespace:div should be parsed as foreign content, no? |
| 10:06 | <tobie> | heycam: right: attribute A foo; just means foo must implement A, not that it mustn't also implement something else |
| 10:06 | <tobie> | heycam: thanks |
| 10:06 | <heycam> | tobie: yup :) |
| 10:06 | <heycam> | still might be worth saying explicitly in the #idl-interface section |
| 10:07 | <tobie> | heycam: yes |
| 10:07 | <nox> | It looks to me like the spec of createContextualFragment is wrong because I don't see how it can behave as tested in "Namespace generally shouldn't matter". |
| 10:34 | Ms2ger | denies everything |
| 11:31 | <tobie> | annevk: would like your thoughts on https://github.com/w3c/ambient-light/issues/17 |
| 11:31 | <tobie> | when you find the time |
| 11:33 | <tobie> | annevk: and https://github.com/w3c/sensors/issues/150 |
| 11:36 | <annevk> | tobie: what is SensorReading? No enum I hope? |
| 11:37 | <tobie> | annevk: an interface |
| 11:38 | <annevk> | tobie: for 17 I think you don't have to redefine it |
| 11:38 | <tobie> | annevk: contains a hr-timestamp and the value(s) of the sensor at that time |
| 11:38 | <tobie> | annevk: cool |
| 11:38 | <annevk> | tobie: only use would be stating a more specific return value, right? |
| 11:38 | <tobie> | annevk: yes |
| 11:39 | <annevk> | tobie: you only do it if you change the type |
| 11:40 | <annevk> | tobie: which is an anti-pattern, but legacy |
| 11:40 | <tobie> | annevk: well, it's a subclass |
| 11:40 | <annevk> | tobie: not sure about 150 |
| 11:41 | <tobie> | annevk: it's very similar to that VR thing in https://github.com/w3c/webvr/issues/107 |
| 11:44 | <tobie> | annevk: well, in practise it's actually the same thing as VRPose (which webvr declares as an interface) |
| 12:48 | <nox> | annevk: Intimate with the subtle details of createContextualFragment? |
| 12:49 | <annevk> | nox: sorry |
| 12:49 | <nox> | Don't be. |
| 12:49 | <nox> | annevk: Know who could help? |
| 12:50 | <annevk> | nox: not really |
| 12:50 | <nox> | Ok. :) |
| 12:52 | <annevk> | Apart from you not many folks have studied the parser bits lately |
| 12:56 | <nox> | annevk: 'Unmark all scripts in <var>fragment node</var> as "already started" and as "parser-inserted".' Does that sound English? |
| 12:57 | <annevk> | nox: it's a little vague, although I think I get the intent |
| 12:57 | <nox> | annevk: Ok. |
| 12:57 | <nox> | https://github.com/w3c/DOM-Parsing/pull/23 |
| 12:58 | <nox> | annevk: Do I have something to do for that ipr failing test? Should I care? |
| 12:58 | <nox> | Or is that W3C bureaucracy that doesn't concern me? |
| 12:59 | <annevk> | nox: don't care |
| 12:59 | <nox> | Perfect. I like it when I don't have to care. |
| 12:59 | <annevk> | nox: it seems HTML is inconsistent with mark / using "already started" as flag |
| 12:59 | <annevk> | nox: oh well |
| 17:44 | <nox> | Wtf is IPR? |
| 17:45 | <nox> | Oh, Intellectual Property Rights, got it. |
| 21:21 | <Domenic> | Wait, I've lost the plot, are data URLs same origin or not? |
| 21:25 | <TabAtkins> | Depends on context, I think? |
| 21:28 | <jgraham> | I thought the answer was "no" in Chrome and latterly in the spec |
| 21:29 | <jgraham> | THere is a lovely test run with this change in gecko: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b |
| 21:39 | <jsbell> | many web-platform-tests rely on data: behaving as in moz. |
| 21:40 | <jsbell> | Oh, hey, I said that before: https://github.com/w3c/web-platform-tests/issues/1999 |
| 21:43 | <jgraham> | Oh look a PR to fix some things |
| 21:59 | <Domenic> | Apparently data is mostly same-origin but not for navigations and workers or something like that https://github.com/whatwg/fetch/commit/6f223de29733e64dbe1dfc6028c6e0a4a5d89398 |
| 22:06 | <caitp> | so presumably code in a data uri can't read secure cookies or anything? |
| 22:07 | <caitp> | from window.opener or whatever |
| 22:07 | <Domenic> | Right so I guess they are different-origin but fetch treats them as same-origin |
| 22:07 | <Domenic> | but only for the purposes of fetching |
| 22:08 | <Domenic> | jsbell: I see that Chrome still supports UTF-32? :( |
| 22:08 | <Domenic> | Oh I see there are recent comments https://bugs.chromium.org/p/chromium/issues/detail?id=417850 |
| 22:30 | <jsbell> | Domenic: Yeah. We'll get rid of it soon. |
| 22:31 | <Domenic> | \o/ |