| 01:09 | <MikeSmith> | annevk: http://stackoverflow.com/questions/32897921/why-does-this-cors-request-to-a-google-drive-sheet-fail-in-firefox-works-in-c |
| 02:22 | <zewt> | what the holy shit |
| 02:22 | <zewt> | adblock hijacked new window on chrome to show an ad for itself |
| 02:23 | <zewt> | google should kill the extension outright for that level of abuse |
| 02:24 | <zewt> | time to try ublock |
| 06:54 | <zcorpan> | jgraham: i nominate cvrebert for push access to web-platform-tests |
| 06:59 | <MikeSmith> | zcorpan: seconded |
| 07:22 | <annevk> | MikeSmith: seems like a security bug in Chrome |
| 07:22 | <annevk> | MikeSmith: they're not requiring CORS headers on redirects |
| 07:24 | <MikeSmith> | annevk: oh |
| 07:25 | <annevk> | I would have thought that would be covered by the testsuite though |
| 07:25 | <annevk> | But perhaps Chrome is not really trying to conform to it |
| 07:32 | <MikeSmith> | Ms2ger: > zcorpan: jgraham: i nominate cvrebert for push access to web-platform-tests |
| 07:32 | <MikeSmith> | Ms2ger: > MikeSmith: zcorpan: seconded |
| 07:32 | <Ms2ger> | thirded |
| 07:32 | <MikeSmith> | k |
| 07:33 | <MikeSmith> | Ms2ger: so we can either wait to get confirmation from jgraham or one of us can just flip on his push perms now |
| 07:34 | <Ms2ger> | Go for it |
| 07:37 | <MikeSmith> | done |
| 08:30 | <mkwst> | annevk: Good morning! Would you prefer that I specify `frame-ancestors` as a network error in Fetch, or as a something something for Documents in HTML? |
| 08:30 | <mkwst> | MikeSmith: I think that CORS issue is an artifact of Chrome's HSTS handling. |
| 08:31 | <mkwst> | MikeSmith: docs.google.com is preloaded in Chrome, so the redirect never really happens. |
| 08:32 | <annevk> | mkwst: I'm not sure |
| 08:34 | <mkwst> | annevk: Me neither. :) |
| 08:35 | <mkwst> | Fetch is appealing, because it seems straightforward and avoids the work necessary to figure out _where_ in HTML to do the check. |
| 08:36 | <annevk> | mkwst: sounds reasonable |
| 08:36 | <annevk> | mkwst: if it's trivial to do in Fetch, just do it there I guess |
| 08:36 | <mkwst> | annevk: I'll type it up and then we can go back and decide it was a bad idea later. |
| 08:36 | <annevk> | mkwst: can always refactor |
| 08:36 | <annevk> | mkwst: either way it needs to behave as a network error |
| 08:38 | <mkwst> | Actually, we have a CSP hook at the bottom of main fetch anyway. I'll just do it there. Ha. |
| 08:39 | <mkwst> | But it might be reasonable to have a check for `x-frame-options` as well? |
| 08:39 | <mkwst> | Hrm. |
| 08:57 | <annevk> | mkwst: can't CSP also handle x-frame-options? |
| 08:57 | <annevk> | mkwst: seems like the easiest for CSP to just define both headers |
| 08:58 | <annevk> | mkwst: and handle them in the same algorithm |
| 08:58 | <annevk> | mkwst: presumably that's what implementations do too |
| 08:58 | <mkwst> | If only they acted the same. |
| 08:59 | <mkwst> | x-frame-options is a bit broken, as it only checks the top-level origin. |
| 08:59 | <mkwst> | But sure. *shrug* Isn't there an RFC? |
| 09:00 | <annevk> | there is http://tools.ietf.org/html/rfc7034 it seems but that's kind of useless without integration |
| 09:00 | <annevk> | also very verbose... |
| 09:00 | <mkwst> | Well, let me finish the things I know I need to do before I grab more work. :) |
| 09:02 | <annevk> | if you don't specify it please file an issue on Fetch |
| 09:02 | <annevk> | seems like a shame to not define how that header actually interacts with Fetch |
| 09:34 | <mkwst> | annevk_: yes. it ought to be defined. if i have time, i'll do it. |
| 09:34 | <annevk_> | \o/ |
| 09:58 | <yhirano_> | annevk_: can you take a look at https://github.com/whatwg/fetch/pull/128? |
| 10:18 | <annevk> | yhirano_: will do today, sorry |
| 10:24 | <yhirano_> | annevk: thank you |
| 10:54 | <annevk> | I think I understand mounir's feelings about reviewing a little better now |
| 10:54 | <annevk> | It's no fun |
| 11:04 | <mounir> | annevk: tell me more about that :) |
| 11:04 | <botie> | will do |
| 11:06 | zcorpan | slaps botie |
| 12:09 | <annevk> | mounir: reviewing PRs to standards is not the most fun thing to do |
| 12:10 | <annevk> | mounir: but it's necessary to grow the set of folks who can write them |
| 12:15 | <annevk> | Domenic: basically, the problem is that if you assign a blob URL to a number of elements, you want to know which one ends up using it |
| 12:16 | <annevk> | Domenic: if I assign a blob URL to two <a> elements, and it sorta depends which one ends up getting the reference to the blob as to where the user clicks, that'd be suboptimal |
| 12:16 | <annevk> | (or of which you ended up checking another member) |
| 12:16 | <Domenic> | annevk: how is clicking involved? I don't see any steps in the spec that invoke cloning when you click a hyperlink |
| 12:16 | <annevk> | Domenic: presumably that would lazily figure out the url, no? |
| 12:17 | <annevk> | Domenic: I mean if we don't figure out the url immediately, we'd have to figure it out later |
| 12:17 | <Domenic> | annevk: right now I believe it just lazily consults the internal URL. It doesn't call re-initialise or anything. |
| 12:17 | <annevk> | Domenic: during hover perhaps? |
| 12:18 | <Domenic> | bbiab |
| 12:21 | <annevk> | Mean I really don't want to write all the domintro garbage |
| 12:21 | <annevk> | I should probably just get over it, but given the long list of important bugs to fix I'm finding it hard to justify |
| 12:36 | <Domenic> | Authors will appreciate it! |
| 12:49 | <annevk> | Domenic: well, as long as we're not generating that developer edition |
| 12:52 | <Domenic> | :( |
| 12:52 | <annevk> | Also, not all specifications do this so I have some worries about the longevity of all this |
| 12:52 | <Domenic> | _That_ would be a good intern project... |
| 12:52 | <caitp> | http://caitp.github.io/spidermonkey-wks-security/ wip thing to try to figure out cross-browser cross-origin access to well-known symbol-named properties, just for fun. |
| 12:52 | <annevk> | I really want to work on this meta-language thing for standards |
| 12:53 | <annevk> | Having that defined could simplify the decision making process when defining something new so much |
| 12:53 | <annevk> | But it should really be in IDL and IDL is well... |
| 12:53 | <Domenic> | caitp: SyntaxError in Chrome, blank page in Firefox? |
| 12:54 | <caitp> | nightly is a syntax error for all 3 supported symbols |
| 12:54 | <caitp> | FF nightly* |
| 12:54 | <caitp> | chrome with --harmony is all security errors, but the behaviour Toon wants is very different |
| 12:54 | <Domenic> | Oh HTTPS everywhere is screwing me |
| 12:54 | <caitp> | er, nightly is not a syntax error, it's a security error* |
| 12:55 | <caitp> | which more or less matches current Chrome |
| 12:57 | <mkwst> | annevk: meta-language thing? |
| 12:57 | <annevk> | caitp: you are aware of https://etherpad-mozilla.org/html5-cross-origin-objects and such, right? |
| 12:58 | <annevk> | mkwst: yeah, a more formal definition of what we're doing, including a bunch of convenient shorthands |
| 12:58 | <mkwst> | annevk: for example? |
| 12:58 | <annevk> | mkwst: e.g., ECMAScript is much better at having precise language |
| 12:58 | <caitp> | i've read the etherpad previously, yeah |
| 12:58 | <annevk> | mkwst: but ECMAScript is quite verbose |
| 12:58 | <annevk> | mkwst: Domenic and others came up with a bunch of constructs that make that better |
| 12:59 | <Domenic> | bterlson wants to get rid of ReturnIfAbrupt in ES, which would make it even better. |
| 12:59 | <annevk> | mkwst: however, since we're not defining JavaScript, but IDL, we cannot really reuse that |
| 12:59 | <caitp> | from bugmail it just sounds like SM is getting further along with matching the etherpad semantics |
| 12:59 | <annevk> | mkwst: so what I'd like is for IDL to define that kind of language, that specifications can then use, so they all read the same more or less and it becomes easier to spot bugs |
| 13:00 | <annevk> | mkwst: and also hopefully becomes easier to write them |
| 13:00 | <mkwst> | annevk: makes sense. I'm sure there are constructs that get cargo-culted everywhere. Formalizing them might be helpful. |
| 13:01 | <annevk> | MikeSmith: reporting the error for the correct line just saved me going through a 100 lines of HTML |
| 13:02 | <annevk> | Domenic: added domintro to a/area |
| 13:02 | <annevk> | very basic |
| 13:03 | <Domenic> | annevk: will re-review in a few hours |
| 13:04 | <zcorpan> | TabAtkins: can you have a look at https://github.com/tabatkins/bikeshed/pull/498 ? |
| 13:07 | <MikeSmith> | annevk: glad the line-number reporting is working |
| 13:08 | <MikeSmith> | I need to finish up the remaining changes to the build script |
| 13:32 | <zcorpan> | https://developer.apple.com/library/safari/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html <link rel="icon" sizes="any" mask href="website_icon.svg"> :-( |
| 13:55 | <annevk> | Hmm I thought they fixed that |
| 13:59 | <hasather> | zcorpan: annevk: probably just out-of-date documentation, twitter and pinterest uses rel="mask-icon" |
| 13:59 | <annevk> | hasather: was thinking that too |
| 14:00 | <annevk> | hasather: hober also put himself on the hook for writing a PR for mask-icon so I'm guessing all is fine |
| 14:01 | <hasather> | there's a feeback link at the bottom, I'll use that |
| 14:23 | <Domenic> | Yeah hober where's our PR :) |
| 14:23 | Domenic | is scared of the <meta> area of the spec |
| 14:25 | <wanderview> | annevk: ping |
| 14:25 | <wanderview> | or anyone else who can help with relative URLs in stylesheet subresources |
| 14:27 | <wanderview> | if window a.com loads stylesheet a.com/foo.css which is redirected to b.com/foo.css, and there is a bg-image with URL "./bg.jpg"... is that bg-image URL relative to a.com or b.com? |
| 14:30 | <Ms2ger> | See #content :) |
| 14:33 | <annevk> | wanderview: I would expect b.com |
| 14:33 | <annevk> | wanderview: however, even with workers browsers differ on this apparently |
| 14:33 | <wanderview> | annevk: apparently gecko is loading a.com/bg.jpg according to this test I wrote |
| 14:34 | <annevk> | wanderview: wow, that's very magical |
| 14:34 | <annevk> | wanderview: is that without service workers? |
| 14:34 | <wanderview> | where is the css spec? |
| 14:34 | <nox> | Which one? |
| 14:34 | <wanderview> | annevk: I have a service worker, but its not calling .respondWith() |
| 14:34 | <wanderview> | the latest/best one for defining how bg-image is handled |
| 14:35 | <wanderview> | well, I guess it is calling .respondWith(), but it doesn't matter... since gecko decided this before triggering the FetchEvent |
| 14:35 | <Ms2ger> | CSS doesn't exactly define much here |
| 14:35 | <Ms2ger> | Complain at TabAtkins :) |
| 14:35 | <annevk> | wanderview: the stylesheet is not served through a service worker? |
| 14:36 | <wanderview> | isn't there a github repo for the css specs now? |
| 14:36 | <wanderview> | I can't find it |
| 14:36 | <annevk> | wanderview: because a service worker can have effect on what the URL of the stylesheet becomes, but I guess that might not be play |
| 14:36 | <annevk> | wanderview: https://drafts.csswg.org/ |
| 14:36 | <annevk> | wanderview: doesn't really define any of this though |
| 14:36 | <wanderview> | annevk: I am intercepting the stylesheet, but its just passing the url through to fetch() |
| 14:36 | <wanderview> | annevk: I want to write an issue :-) |
| 14:37 | <annevk> | wanderview: right, so fetch() ends up eating the redirect |
| 14:37 | <wanderview> | oh... |
| 14:37 | <annevk> | wanderview: which means the base URL becomes the request URL |
| 14:37 | <wanderview> | right |
| 14:37 | <wanderview> | hmm |
| 14:38 | <wanderview> | I guess I could make it not call .respondWith() |
| 14:38 | <wanderview> | actually, I can't |
| 14:39 | <wanderview> | since I need to perform async work in the fetchevent handler |
| 14:39 | wanderview | mumbles something about coffee. |
| 14:39 | <wanderview> | annevk: thanks |
| 14:40 | <annevk> | wanderview: it seemed too unlikely that Gecko would not use the "final" stylesheet URL |
| 14:44 | <wanderview> | annevk: actually, isn't this bad? |
| 14:45 | <wanderview> | annevk: it seems this is a case where installing a service worker that just does e.respondWith(fetch(e.request)) changes or breaks the website |
| 14:45 | <wanderview> | annevk: since suddenly the website stops loading b.com/bg.jpg and tries to load a.com/bg.jpg which might not exist |
| 14:46 | <annevk> | wanderview: I defer to JakeA and slightlyoff |
| 14:47 | <annevk> | wanderview: too much other stuff going on, but fetch() is not without side effects, even if we change this somehow |
| 14:48 | <wanderview> | annevk: I'll write an issue |
| 14:58 | <wanderview> | annevk: seems "manual" RequestRedirect could solve it |
| 14:58 | <wanderview> | annevk: but I wrote the issue here: https://github.com/slightlyoff/ServiceWorker/issues/757 |
| 14:58 | <annevk> | wanderview: no that wouldn't solve it |
| 14:59 | <wanderview> | why not? then the stylesheet would see the final URL? |
| 14:59 | <annevk> | wanderview: we cannot expose redirects to the service worker, remember |
| 14:59 | <wanderview> | annevk: well, yea, that would be a side-effect, but whats the problem with it? |
| 14:59 | <annevk> | wanderview: security vulnerability? |
| 15:00 | <annevk> | wanderview: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling |
| 15:00 | <annevk> | wanderview: there's a reason it's an "opaqueredirect"; making it non-opaque is not okay |
| 15:00 | <wanderview> | annevk: I guess the same problem exists for other resources anyway... like a script that uses a relative importScripts() |
| 15:00 | <wanderview> | annevk: wait... it would still be an opaqueredirect... just passed immediately to .respondWith() |
| 15:00 | <annevk> | wanderview: those URLs are resolved against the base URL of the global |
| 15:01 | <annevk> | wanderview: and then always go to the network with no way of making it work offline? |
| 15:01 | <wanderview> | annevk: why wouldn't it get intercepted again? |
| 15:01 | <annevk> | wanderview: how would the CSS loader handle this manual redirect? |
| 15:01 | <annevk> | wanderview: bypass the SW? |
| 15:01 | <annevk> | wanderview: or reveal secrets? |
| 15:02 | <wanderview> | annevk: if its same origin within scope, then yes same SW... otherwise other controlling service worker might handle it |
| 15:02 | <annevk> | wanderview: that's how navigation works, that's not how subresources work |
| 15:03 | <wanderview> | annevk: for script case... where top level script is redirected and we do e.respondWith(fetch(e.request)), what is the global base URL? the original script URL or the final URL? |
| 15:03 | <annevk> | wanderview: so yes, if you feed the redirect-to URL into a SW you created a security vulnerability |
| 15:03 | Ms2ger | wonders if http://test.csswg.org/suites/css21_dev/nightly-unstable/xhtml1/root-box-003.xht is correct |
| 15:03 | <Ms2ger> | (pass condition in <title>) |
| 15:03 | <wanderview> | I guess its defined by the document or worker, and both those have the manual redirect mode |
| 15:03 | <annevk> | wanderview: the base URL of the document |
| 15:04 | <annevk> | wanderview: workers don't have manual mode |
| 15:04 | <wanderview> | annevk: whats the global base URL for a worker, then |
| 15:04 | <wanderview> | ? |
| 15:05 | <annevk> | Ms2ger: I think it might be invalid now |
| 15:05 | <annevk> | wanderview: the final URL |
| 15:06 | <wanderview> | annevk: unless a service worker eats the redirect and then its the same problem as the stylesheet |
| 15:06 | <annevk> | wanderview: ah yeah, for workers that's true |
| 15:07 | <annevk> | wanderview: I'm just saying that manual is not the solution here |
| 15:07 | <annevk> | wanderview: if you want this different we actually need to change the model |
| 15:07 | <annevk> | wanderview: which not be a bad idea, but it's a bit late |
| 15:08 | <annevk> | wanderview: I tried to get this nailed down at some point, but sicking and slightlyoff didn't really want to discuss it much back then |
| 15:08 | <annevk> | wanderview: and we still had this fetch() vs event.default() thing which was weird |
| 15:09 | <wanderview> | annevk: I won't be too upset if people say "corner case... wontfix"... I just want people to be aware of it |
| 15:09 | <annevk> | fair |
| 15:09 | <wanderview> | its a definite footgun for developers, though |
| 15:09 | <annevk> | Yeah, I think we should maybe try to change it |
| 15:10 | <annevk> | We've changed a lot of things in fetch() so that it doesn't break defaults |
| 15:10 | <annevk> | E.g., referrer was a recent one |
| 15:10 | <TabAtkins> | zcorpan: merged |
| 15:10 | <wanderview> | annevk: like this example would break: https://jakearchibald.com/2014/offline-cookbook/#on-network-response |
| 15:12 | <annevk> | wanderview: added a comment |
| 15:12 | <wanderview> | thanks |
| 16:28 | <annevk> | WHATWG aka DOM WG |
| 19:13 | <MikeSmith> | beverloo: http://stackoverflow.com/questions/32908826/multiple-chrome-push-notifications-automatically-closes-except-the-last-one |
| 19:15 | <beverloo> | MikeSmith, 'morning :) |
| 19:15 | <beverloo> | I haven't heard of that before |
| 19:20 | <MikeSmith> | howdy beverloo |
| 19:25 | <beverloo> | MikeSmith, ah I got it |
| 19:25 | <beverloo> | he sets the `tag` as the beginning of the event, and then fetches multiple notifications from his server, displaying them with the same tag |
| 19:26 | <beverloo> | solution is to not use `tag` except for his error notification |
| 19:26 | <beverloo> | let me create an account (way overdue anyway) and reply |
| 19:26 | <beverloo> | thanks for the pointer :) |
| 19:40 | <Domenic> | annevk: so where do we stuff things that we want to put on the global now? |
| 19:40 | <Domenic> | i can't actually find any examples of putting things on the environment settings object |
| 19:41 | <annevk> | Domenic: I've been thinking a bit more about this and putting things on the global instead of document might actually be problematic due to document.open() (which replaces the global) |
| 19:41 | <annevk> | Domenic: but I guess it depends |
| 19:42 | <Domenic> | annevk: so i guess my immediate confusion is that settings objects only have algorithms right now, whereas I want to put a couple data structures on them |
| 19:42 | <Domenic> | where does HTML put all its global state?? |
| 19:42 | <annevk> | Domenic: document |
| 19:42 | <annevk> | Domenic: mostly |
| 19:42 | <Domenic> | annevk: what about in workers? :( |
| 19:43 | <annevk> | Domenic: the environment settings object |
| 19:43 | <annevk> | Domenic: and now a bit on the global too |
| 19:43 | <Domenic> | annevk: any examples? I think I am just searching wrong. |
| 19:43 | <annevk> | Domenic: HTTPS state? |
| 19:43 | <botie> | HTTPS state is poorly defined. I don't think it's in HTML yet. I'm hedging mkwst's bets. :) |
| 19:44 | <annevk> | Domenic: also WorkerGlobalObject's url |
| 19:44 | <Domenic> | annevk: meh, I don't want an algorithm for obtaining a list, I want a list... |
| 19:44 | <annevk> | I'm not really following I'm afraid |
| 19:44 | <annevk> | I also gotta go, so maybe tomorrow |
| 19:44 | <Domenic> | WorkerGlobalScope's URL is better |
| 19:44 | <Domenic> | I'll try to follow that model. |
| 19:54 | <MikeSmith> | beverloo: thanks much! (and upvoted) |
