| 01:04 | <MikeSmith> | annevk: will look at https://github.com/whatwg/html-build/pull/39 |
| 01:04 | <MikeSmith> | annevk: oh, merged already |
| 03:46 | <cvrebert> | MikeSmith: What's the policy on merging things in the test suite repos? Their CONTRIBUTING files are just licensing legalese. |
| 04:37 | roc | reads http://homepages.cwi.nl/~steven/Talks/2015/11-06-xml-amsterdam/ |
| 04:37 | <roc> | sigh |
| 04:42 | <caitp> | i guess they aren't fans of js? |
| 04:46 | <roc> | I suspect he isn't a fan of anything that happened on the Web this century |
| 05:02 | <Hixie> | this talk is great |
| 05:02 | <Hixie> | "You can tell by reading the HTML5 spec that it was written by programmers" |
| 05:03 | <Hixie> | meanwhile programmers whine that html is unimplementable and obviously written by theorists |
| 05:04 | <cvrebert> | "CSS is another example of a successful declarative approach" LOL |
| 05:05 | <Hixie> | this talk is so naive it's hilarious |
| 05:05 | <Hixie> | for example, where are the "Advantages of the Procedural Approach"? or the "Disadvantages of the Declarative Approach"? |
| 05:06 | <Hixie> | it's been 10 years now. you'd think they'd understand what went wrong with xforms. |
| 05:06 | <roc> | plus his "declarative" and "procedural" examples aren't even nearly specifying equivalent behavior |
| 05:07 | <roc> | plus his procedural example is padded by specifying non-negative integers, which aren't covered by the declarative example at all |
| 05:10 | <Hixie> | i think the best part of this talk is that it fails to address any of HTML's actual failings or any of the actual risks to the Web platform. |
| 05:10 | <Hixie> | it literally could have been given almost verbatim 10 years ago |
| 05:11 | <Hixie> | the "100 year web" slide in particular |
| 05:12 | <Hixie> | maybe steven doesn't know that i wrote the HTML spec specifically to address that problem (though i was thinking more on the 1000-year timeframe) |
| 05:12 | <Hixie> | and that that is why the text looks like his "Procedural numbers: HTML5" slide |
| 05:13 | <Hixie> | (i don't understand the internal inconsistencies he's referring to in the "Inflation" slide. Is it the bolded text on the previous slide?) |
| 05:14 | <Hixie> | (maybe he subscribes to the "everything should be conforming" camp or the "anything not conforming must be left undefined" camp, but in that case, his "100 year web" slide misses the point even more) |
| 07:05 | <annevk> | That set of slides captures the nuance of Fox News |
| 07:41 | <annevk> | JakeA: finally got around to filing https://github.com/w3c/beacon/issues/14 |
| 07:51 | <JakeA> | annevk: would you expect backgroundSync to have the same restrictions? It doesn't right now |
| 07:51 | <annevk> | JakeA: of course |
| 07:51 | <annevk> | JakeA: that's what we talked about, how that would be broken |
| 07:52 | <annevk> | JakeA: your argument was sendBeacon() throw the first stone, but I don't think that's true in contemporary implementations and we better prevent it from happening |
| 07:54 | <JakeA> | annevk: this makes backgroundSync kinda useless. Eg, I send an email in the elevator when leaving work, put phone in pocket, phone switches from wifi to cell, my message isn't sent |
| 07:55 | <annevk> | JakeA: yeah, needs to be optin |
| 07:55 | <annevk> | I gave this feedback when we started out too, I'm pretty sure |
| 07:55 | <annevk> | But then you decided amongst yourself on a different UX model without taking that into account |
| 07:57 | <JakeA> | annevk: also don't browsers prefetch pages as they're typed into the address bar? Typing into the address bar can make requests to sites you weren't intending to visit. Isn't this the kind of thing we invented private browsing modes for? |
| 07:57 | <JakeA> | It was taken into account |
| 07:57 | <annevk> | I don't think all browsers do that |
| 08:00 | <JakeA> | annevk: the only way I can see of making background sync opt-in is to prompt on browser/tab close |
| 08:01 | <JakeA> | Which gets complicated on mobile in terms of when a tab is closed |
| 08:14 | <annevk> | JakeA: yeah I was thinking something like that too |
| 08:14 | <annevk> | JakeA: it's not ideal to be sure |
| 08:14 | <annevk> | JakeA: we should have a somewhat larger debate about this |
| 08:15 | <annevk> | JakeA: whether it's okay for closed tabs to continue to have some insight into user behavior |
| 08:15 | <JakeA> | annevk: where's good? Background sync github? |
| 08:15 | <annevk> | JakeA: maybe public-webappsec? |
| 08:15 | <annevk> | JakeA: that's the only list I know with security minded folks already subscribed |
| 08:19 | <JakeA> | annevk: makes sense. I'm filming this morning, but can draft something up this afternoon |
| 09:12 | <zcorpan> | how does assignments on github work? i can't assign jungkees in https://github.com/whatwg/html/issues/321#issuecomment-155357371 |
| 09:14 | <Ms2ger> | It only works for people who have push access |
| 09:14 | <Ms2ger> | Other people can't fix issues, obviously |
| 09:14 | <Ms2ger> | Servo uses an "assigned" label |
| 09:23 | <jgraham> | fwiw I was considering using a bot to create one label per reviewer for wpt. You could do something similar with assignments |
| 09:23 | <cvrebert> | https://github.com/isaacs/github/issues/100 |
| 09:24 | <jgraham> | (i.e. r?jgraham would set a label reviewer:jgraham a=jgraham would set a label assigned:jgraham) |
| 09:24 | <jgraham> | (or something) |
| 09:24 | <jgraham> | (the point being that then people could see their review queue/assignment queue) |
| 09:34 | <annevk> | We should add jungkees to the non-push access group |
| 09:34 | <annevk> | I'll do that |
| 09:37 | <abreton> | hello |
| 09:37 | <botie1> | salut, abreton |
| 09:37 | <abreton> | I am wondering if there is a way to make a worker inherit the CSP from the calling document? |
| 09:41 | <annevk> | abreton: not currently, as far as I know |
| 09:42 | <abreton> | annevk: ok thanks |
| 09:55 | <MikeSmith> | cvrebert: whose CONTRIBUTING files? |
| 09:56 | <cvrebert> | MikeSmith: web-platform-tests , csswg-tesy |
| 09:56 | <cvrebert> | *csswg-test |
| 09:56 | <MikeSmith> | the policy is basically that we don't merge things in that are unnecessary or redundant, so if there's anything in that class, we shouldn't merge it |
| 09:57 | <MikeSmith> | or should revert it if it's already been merged |
| 09:57 | <cvrebert> | MikeSmith: What about review requirements? |
| 09:58 | <MikeSmith> | Hixie: I guess it is pretty much the same talk he's been giving for 10 years now |
| 10:02 | <MikeSmith> | cvrebert: the review requirements are, it's a the discretion of the owners / core reviewers in the end |
| 10:02 | <MikeSmith> | cvrebert: which for wpt amounts to Ms2ger and jgraham |
| 10:02 | <MikeSmith> | for csswg-test I don't really know what the review requirements are |
| 10:03 | <MikeSmith> | but for wpt a good rule is that if you have any doubt, ask Ms2ger or jgraham |
| 10:07 | <cvrebert> | MikeSmith: Noted. |
| 10:13 | <Ms2ger> | sup? |
| 10:18 | <cvrebert> | Nothing specific. |
| 11:37 | <JakeA> | annevk: you mentioned a web components meetup that we might want to combine with a serviceworker f2f, any details on the components meetup? |
| 11:52 | <annevk> | JakeA: I don't think anything's been decided yet |
| 11:52 | <annevk> | JakeA: there was a poll of sorts started on public-webapps |
| 11:55 | <JakeA> | annevk: ahh ok. I'll see if it's coming together in a month or so, if not I'll take MS up on their offer of hosting |
| 12:44 | <zcorpan> | i wonder if https://github.com/whatwg/html-build should say to fork html, clone the fork, and then clone html-build. i know build.sh will clone html itself, but if you want to submit a PR for html you have to fork it |
| 12:45 | <zcorpan> | MikeSmith: ^ |
| 12:47 | <gsnedders> | is there any reason why it isn't a submodule of html? |
| 12:51 | <zcorpan> | i dunno |
| 13:00 | <MikeSmith> | the html-build script will clone the html repo if it doesn't find an existing clone in the local environment or you don't point it at one |
| 13:01 | <MikeSmith> | at least that is the intent, though there's an open html-build PR that I need to finish work on |
| 13:02 | <zcorpan> | yeah i see https://github.com/whatwg/html-build/pull/29 now |
| 13:04 | <zcorpan> | but i still think our READMEs should instruct to fork html. iirc there was some contributor that got confused about this and we needed to start over with forking html |
| 13:06 | <zcorpan> | i suppose this is https://github.com/whatwg/html-build/issues/26 |
| 13:06 | MikeSmith | looks |
| 13:06 | <MikeSmith> | yeah |
| 13:07 | <MikeSmith> | sorry, I was working on this stuff pretty actively til roughly one month ago |
| 13:09 | <MikeSmith> | getting back to working again on making it right as soon as possible is a high(est) priority for me personally |
| 13:13 | <MikeSmith> | as far as why we've not set it up at as submodule already, I guess that's because none of us who worked on it initially are big fans of submodules |
| 13:25 | <zcorpan> | i can PR the html-build readme to add a first step saying to fork html if the goal is to PR html |
| 13:46 | <wanderview> | JakeA: annevk: so are we intending to allow service workers to be registered for file:// documents (or event wss:// somehow?) |
| 13:47 | <JakeA> | wanderview: registered? No. Intercepting file:// is more interesting though. I can see us intercepting wss in future too, but it'd be a different event |
| 13:48 | <wanderview> | JakeA: I don't see where we block file:// in the spec any more |
| 13:48 | <wanderview> | JakeA: it seems to just use the "Is origin potentially trustworthy" check, which allows file://, wss:// |
| 13:49 | <JakeA> | wanderview: ohhh, we should specifically prevent file I think. Having a SW running in someone's file system sounds really unsafe |
| 13:50 | <wanderview> | JakeA: ok, I will file a separate issue for that... I had commented in the big "secure context" issue, but I think we should fix this sooner |
| 13:50 | <JakeA> | agreed |
| 13:51 | <wanderview> | JakeA: if we want to allow file:// and wss:// to be intercepted, we also need to relax the restrictions in cache API |
| 13:53 | <JakeA> | wanderview: file:// maybe, but not sure what it means to put a wss:// in a cache. Will those be represented by request/response or something else? |
| 13:53 | <wanderview> | JakeA: not sure... I was just thinking the usual cache patterns in SW should work with FetchEvent.request even if its a wss: scheme... |
| 13:54 | <wanderview> | or at least not explode |
| 13:54 | <wanderview> | I guess we already have some things that conditionally fail... like cache.add() with a POST |
| 13:56 | <JakeA> | wanderview: I don't know enough about the wss protocol to know if request/response makes sense or if it'd need its own event |
| 13:57 | <wanderview> | ok |
| 13:57 | <wanderview> | neither do I... lets burn that bridge later :-) |
| 14:08 | <wanderview> | JakeA: what about an https://foo.com window, that has an iframe with a data:// URI.. I believe the iframe inherits the parents origin there... should the iframe be allowed to register a SW for https://foo.com? |
| 14:11 | <wanderview> | JakeA: or for a javascript:// window that inherits the origin of its opener... shoudl that be allowed to register using its opener's origin? |
| 14:23 | <wanderview> | I guess the origins should just be compared and if the origins are set properly, then it shoudl work |
| 14:25 | <annevk> | wanderview: JakeA: intercepting anything but http/https URLs doesn't work per Fetch |
| 14:26 | <annevk> | wanderview: JakeA: nothing for those URLs gets even close to checking a service worker for a response |
| 14:27 | <wanderview> | annevk: sure... but I don't see anything in .register() currently that would prevent the service worker from registering and controlling such a page |
| 14:31 | <JakeA> | wanderview: yes to both your questions - I think this is how it works already |
| 14:31 | <wanderview> | ok, thanks |
| 14:48 | <annevk> | zcorpan: a constructor cannot return a promise |
| 14:48 | <zcorpan> | annevk: ok. why not? |
| 14:49 | <zcorpan> | though since we need some opt-in mechanism, we can make it be a static method on Worker or so instead |
| 14:49 | <jgraham> | Presumably because a construtor is supposed to construct an instance? |
| 14:50 | <annevk> | zcorpan: well, I guess technically it probably can, but a constructor is expected to return an instance |
| 14:50 | <zcorpan> | yeah |
| 15:13 | <wanderview> | the Promise() constructor can return a promise :-) |
| 15:16 | <wanderview> | JakeA: sorry for more dumb questions... do we intentionally let https://foo.com window to execute .register('javascript://...')? where the service worker script inherits the origin from the window? |
| 15:19 | <JakeA> | wanderview: the SW cannot be a blob/data url, so I guess javascript should be out too |
| 15:19 | <JakeA> | Otherwise you're not proving you can put script on that origin |
| 15:19 | <JakeA> | Wouldn't javascript:// fail the same origin check? |
| 15:20 | <wanderview> | JakeA: no... because I thought javascript:// URIs were supposed to inherit the origin |
| 15:20 | <wanderview> | JakeA: what blocks blob: and data: URLs for the script? I didn't see that last time I looked |
| 15:22 | <wanderview> | JakeA: oh, hmm... I guess the URL spec does not do the origin inherit for data: or javascript:... but it seems it might give you a real origin for a blob: |
| 15:23 | <JakeA> | wanderview: maybe we need to explicitly fail for non http or https schemes |
| 15:23 | <wanderview> | JakeA: yea, I'll add it to the issue I wrote |
| 15:23 | <JakeA> | I'm sure we used to explicitly restrict those |
| 15:23 | <wanderview> | JakeA: yea, it got lost at some point |
| 15:26 | <JakeA> | Thanks for spotting those! |
| 15:27 | <JakeA> | Being able to use a non-network resource as a service worker is a big security issue and footgun |
| 15:27 | <wanderview> | JakeA: np! we are trying to implement the secure context thing which made me start to wonder... we are only blocking file:// right now because we store the SW script in Cache API which rejects it |
| 18:03 | <annevk> | wanderview: are you suggesting Worker should be a promise subclass? :-P |
| 18:04 | <wanderview> | I didn't know we were talking about Worker, but if you say so |
| 18:04 | <wanderview> | I mean, if you think it should be a subclass, ok |
| 18:04 | <wanderview> | :-) |
| 18:05 | <annevk> | Well, I'm joking |
| 18:06 | <annevk> | I wonder if conceptually it makes sense for a worker to be an asynchronous iterable |
| 18:07 | <annevk> | Since it's really just a sequence of message events |
| 18:15 | <caitp> | clearly it should be a subclass of Observable<T> |
| 18:21 | <Ms2ger> | TabAtkins, sounds like you fly too much |
| 18:22 | <TabAtkins> | That was my problem, actually. I *always* fly American out of SFO, so I didn't even check the airport this time. |
| 18:23 | <Ms2ger> | And thank you for https://pbs.twimg.com/media/CTc9sbTUYAAYhar.png |
| 18:23 | <TabAtkins> | Rolled into SFO this morning and checked my terminal, went "lol SFO doesn't have an A terminOH FUCK" |
| 18:24 | <TabAtkins> | Can confirm that list is accurate, have received live scorpions. |
