| 01:18 | <MikeSmith> | annevk: great response from Jonas in TAG discussion about CORS credentials handling https://lists.w3.org/Archives/Public/www-tag/2016Jan/0015.html |
| 01:20 | <MikeSmith> | annevk: mnot is really not helping in those discussions; instead he seems to just be reinforcing misconceptions https://lists.w3.org/Archives/Public/www-tag/2016Jan/0012.html |
| 01:20 | <MikeSmith> | > "It's pretty impenetrable now, and even security folks don't profess to know all of the details behind CORS any more." |
| 01:23 | <MikeSmith> | it's true that a lot of web devs don't (yet) know they need to use withCredentials with XHR to get cookies set (or the "credentials" request option with fetch) |
| 01:25 | <MikeSmith> | e.g., on StackOverflow I think there is new question at least weekly or so where somebody is running into a problem where something's not working they way they expect and it turns out to be because they're not using withCredentials/credentials |
| 01:27 | <MikeSmith> | so I think Jonas is right that some more awareness-raising is needed |
| 02:15 | <annevk> | I'm not security folk, but I know how this works and why… |
| 03:19 | <MikeSmith> | annevk: yeah I don't know what motivates those comments from mnot. It seems like he's being disingenuous because it's a bit hard to believe he really thinks it's that "impenetrable". |
| 03:21 | <MikeSmith> | I remember how outspoken he was in opposition to the original Access Control spec back in the beginning but I'd thought we were way past that now. Water under the bridge |
| 03:32 | <annevk> | Doesn't matter I guess, it's there |
| 09:34 | <ondras> | several questions re. iframe sandboxing |
| 09:35 | <ondras> | not sure if this is the proper place to ask |
| 09:35 | <ondras> | serving potentially dangerous ads (generic html+css+js soup); is a sandboxed iframe the correct way to go? |
| 09:54 | <philipj> | zcorpan: what were you saying to me a few days ago? http://krijnhoetmer.nl/irc-logs/ is down |
| 09:55 | <philipj> | ondras: yes, that sounds right. mkwst is the expert on these things |
| 09:55 | <philipj> | or at least he added a sandbox keyword once :) |
| 09:56 | <zcorpan> | philipj: what did i eat a few days ago? lol don't remember :-) |
| 09:56 | <ondras> | :) |
| 09:56 | <zcorpan> | there's logs.glob.uno/?c=freenode%23whatwg though |
| 09:57 | <ondras> | cool. |
| 09:57 | <ondras> | Basically, I have two question re. iframe sandboxing |
| 09:57 | <philipj> | zcorpan: ok, you were asking about JSON.stringify(new DOMMatrix(...)) |
| 09:57 | <ondras> | 1) the sandbox does not seem to apply if the iframe -- no src set -- was already appended to DOM |
| 09:57 | <ondras> | is this intentional? |
| 09:57 | <philipj> | zcorpan: did you figure out the answer yet? |
| 09:57 | <zcorpan> | philipj: yeah, just found it. i changed the spec so no need for more pondering :-) |
| 09:58 | <ondras> | 2) if I do not want my src-less iframe to be able to access the parent, how can I set its contents after sandboxing (unable to do contentDocument.write)? |
| 09:58 | <ondras> | via data-url src? |
| 09:58 | <ondras> | mkwst: ^ please :) |
| 09:59 | <philipj> | ondras: maybe some combination of sandbo and srcdoc, in the right order, will do what you want |
| 10:00 | ondras | never tried srcdoc, let me read its docs first |
| 10:01 | <philipj> | zcorpan: great! |
| 10:02 | <ondras> | philipj: right, sounds like an answer to my #2 question! thanks. |
| 10:08 | <philipj> | ondras: as for #1, the spec says "When an iframe element with a sandbox attribute has its nested browsing context created (before the initial about:blank Document is created), and when an iframe element's sandbox attribute is set or changed while it has a nested browsing context, the user agent must parse the sandboxing directive ..." |
| 10:09 | <philipj> | so it looks like you should be able to change it at any time |
| 10:09 | <philipj> | implementations might disagree, haven't checked |
| 10:35 | <ondras> | philipj: I found this: These flags only take effect when the nested browsing context of the iframe is navigated. Removing them, or removing the entire sandbox attribute, has no effect on an already-loaded page. |
| 10:38 | <zcorpan> | ondras: set the attribute(s) before inserting the iframe to the document |
| 10:39 | <mkwst> | ondras: 1. The `sandbox` attribute only applies at load-time. Changing the attribute won't effect a running document. |
| 10:39 | <ondras> | okay |
| 10:40 | <mkwst> | ondras: 2. It seems like you'd get what you want by seting the `sandbox` attribute, navigating the frame to something (`about:blank`), and then populating it. `srcdoc` would certainly work as well. |
| 10:41 | <mkwst> | And `srcdoc` (or `data:text/html,...`, which boils down to the same thing) is likely your only option if you need to push the frame into a unique origin. |
| 10:41 | <ondras> | mkwst: okay. so if the sandboxing is in effect (the not-allow-same-origin one), the only way to populate is .src and .srcdoc, right? |
| 10:42 | <mkwst> | Blink (and, I think, WebKit) supports sandboxing a document into a unique origin via `<meta http-equiv="Content-Security-Policy" content="sandbox ...">`, but I don't believe that Firefox supports that. |
| 10:42 | <ondras> | I am looking for the widest browser support available |
| 10:42 | <mkwst> | (And it's currently a spec violation, but one I'm arguing against, so...) |
| 10:42 | <mkwst> | Then navigating to a data: URL is probably your best bet. |
| 10:42 | <ondras> | :-) |
| 10:43 | <ondras> | perhaps "sandbox" and "srcdoc" have the same compatibility status |
| 10:43 | <ondras> | will check that |
| 10:43 | <ondras> | thanks a lot! |
| 10:43 | <mkwst> | I'm pretty sure they don't. But they might! |
| 10:43 | <zcorpan> | ondras: data: doesn't give you a unique origin in firefox, i believe |
| 10:43 | <zcorpan> | at least not effective script origin |
| 10:43 | <ondras> | zcorpan: I would have to set a sandbox, of course |
| 10:44 | <zcorpan> | yeah with sandbox i suppose it's safe |
| 10:46 | <zcorpan> | caniuse says srcdoc is not supported in IE or Edge |
| 10:46 | <zcorpan> | but sandbox is |
| 10:47 | <zcorpan> | but <iframe src=data:> doesn't work in IE/Edge either, does it? http://caniuse.com/#search=data%20uris |
| 10:48 | <ondras> | not good :/ |
| 10:50 | <zcorpan> | i tried <iframe src="data:text/css,hello"> but no luck :-D https://www.browserstack.com/screenshots/69af9c645a26c24974cea20db88e0f2c6a113e75/win8.1_ie_11.0.png |
| 10:51 | <jgraham> | Do blob urls work in edge? |
| 10:51 | <ondras> | this is interesting |
| 10:51 | <ondras> | https://github.com/jugglinmike/srcdoc-polyfill/blob/master/srcdoc-polyfill.js |
| 10:55 | <zcorpan> | ondras: javascript: URLs don't have a unique origin |
| 10:57 | <zcorpan> | jgraham: http://caniuse.com/#search=blob%20url says yes |
| 10:57 | <jgraham> | You could perhaps use that to solve the problem then? |
| 10:58 | <ondras> | zcorpan: well even with the sandbox attribute? |
| 10:59 | <zcorpan> | ondras: yeah, was just going to say... probably need to test it, maybe it's fine |
| 10:59 | <ondras> | right |
| 11:52 | <nox> | Are custom elements a thing that will indeed happen? |
| 11:54 | <jgraham> | Yeah |
| 11:54 | <nox> | Ah. :( |
| 11:55 | <nox> | So when will they land in Firefox? |
| 11:56 | <jgraham> | I think there's a pref |
| 11:57 | <jgraham> | https://bugzilla.mozilla.org/show_bug.cgi?id=889230 |
| 12:00 | <annevk> | Details of custom elements will be discussed later today in Cupertino… |
| 12:52 | <zcorpan> | ok i'm done spamming caniuse with PRs for today |
| 13:51 | <ondras> | so |
| 13:51 | <ondras> | apparently populating a sandboxed iframe in IE/Edge is hard. |
| 13:52 | <ondras> | but works, in a VERY HACKY way |
| 13:52 | <ondras> | the vehicle for that is .src = javascript:stuff_that_returns_html_content |
| 13:52 | <ondras> | but this works only without sandboxing |
| 13:52 | <ondras> | but there is a way |
| 13:52 | <ondras> | 1) append; 2) enable sandbox; 3) set .src |
| 13:52 | <ondras> | this does not work in regular browsers (sandbox has to be enabled before appending), but works in IE/Edge |
| 13:52 | <ondras> | :/ |
| 13:58 | <jgraham> | ondras: Did you try blob urls? |
| 13:59 | <ondras> | jgraham: no |
| 13:59 | <jgraham> | ondras: Seems arguably less bad than js urls |
| 14:00 | <ondras> | jgraham: i will have a look then |
| 14:00 | <ondras> | jgraham: but the strange taste of "in order to change src of a sandboxed iframe, I have to set the sandbox later" remains :/ |
| 14:01 | <ondras> | jgraham: so the plan is to create a Blob out of that content and convert it to url via createObjectURL, right? |
| 14:03 | <jgraham> | ondras: Yeah |
| 14:04 | <ondras> | jgraham: blob urls do not seem to work at all in IE/Edge |
| 14:05 | <beverloo> | annevk, what's your take on re-using NotificationEvent vs. splitting it up in Notification{Click,Close}Event? |
| 14:05 | <beverloo> | the former would remove a fair amount of duplication/overhead, but the latter feels like the right thing to do |
| 14:07 | <jgraham> | ondras: Oh well |
| 14:07 | <ondras> | http://codepen.io/grimen/pen/lBuiG |
| 14:07 | <ondras> | I also googled this sample |
| 14:07 | <ondras> | does not work in IE |
| 14:07 | <ondras> | :/ |
| 14:15 | <annevk> | beverloo: due to action? There's many precedents set either way... I guess the click one could be a subclass if we really didn't want that action member on close |
| 14:15 | <beverloo> | Yes. It would always be "null" I guess |
| 14:16 | <beverloo> | I don't feel strongly either way, but in the future it's something we may want to look at? |
| 14:16 | <annevk> | Well, I guess we could, but it would be safer to be sure now |
| 14:17 | <annevk> | I don't think it matter much though. E.g., MessageEvent is used for dozens of things without anyone complaining |
| 14:17 | <beverloo> | one case I'm thinking of is inline replies - Mac is pushing this quite strongly, and Windows would be able to support it as well |
| 14:17 | <beverloo> | that'd be some kind of `notificationinput` event that's different again |
| 14:18 | <beverloo> | (this is rather far down our list of things to do, though) |
| 14:19 | <annevk> | Even that would likely just be a simple string that could be empty for the other events |
| 14:20 | <annevk> | I don't really care strongly either way I think |
| 14:20 | <beverloo> | I'm OK with that, keeps things simple |
| 14:20 | <beverloo> | same |
| 14:21 | <beverloo> | I'll merge his PR :) |
| 14:33 | <annevk> | beverloo: please don't do it like that again going forward |
| 14:33 | <annevk> | beverloo: see https://github.com/whatwg/html/blob/master/TEAM.md |
| 14:33 | <annevk> | beverloo: also, the commit needed to be updated as bikeshed had not yet been run |
| 14:34 | <annevk> | anyway, for next time, I should probably add a section on Merging to the README everywhere to make it clear this applies everywhere, not just to HTML |
| 14:35 | <beverloo> | I was just updating bikeshed and fixing that indeed |
| 14:35 | <beverloo> | I'll read that page, sorry |
| 14:36 | <annevk> | don't worry, we haven't communicated this widely enough I think |
| 14:37 | <beverloo> | it's the first time I see that page, but I may've been out of the loop :) |
| 14:42 | <beverloo> | annevk, shall I push the html rebuild? |
| 14:42 | <annevk> | beverloo: yeah sure |
| 14:48 | <beverloo> | ok that worked. thank you! |
| 14:49 | <beverloo> | except for s/60/61/, meh. I'll play around with and learn the new git magic |
| 14:50 | <annevk> | beverloo: is Chromium still on subversion? |
| 14:51 | <beverloo> | no, we use git, but my workflow is limited to a few commands |
| 14:51 | <beverloo> | a lot of it is hidden by other commands (e.g. our gclient tool) |
| 14:51 | <annevk> | ah |
| 14:52 | <beverloo> | anyhow, sorry for the noise! |
| 15:29 | <MikeSmith> | has there been any more movement on requestAutocomplete? |
| 15:30 | <MikeSmith> | I remember us having some discussion of it a year or so ago (or at least it seems like that long), but then nothing |
| 15:31 | <MikeSmith> | and I mean specifically as a way to help with solving problems with making payments easier in Web apps |
| 18:00 | <smaug____> | MikeSmith: does WebEx have some webby UI? |
| 18:00 | <smaug____> | I see Java and iOS and Android stuff |
| 18:41 | <ritsyy> | annevk: could you review this https://github.com/Ritsyy/html/commit/07ef4887e1af957bdc6dbf05b96db7ab547e56a7 |
| 18:43 | <annevk> | ritsyy: the </dd> should remain adjacent to "specified.", just as before |
| 18:43 | <annevk> | ritsyy: looks good otherwise |
| 18:43 | <ritsyy> | but it is exceeding 100char per line then |
| 18:45 | <annevk> | ritsyy: then you'll need to put it on the next line |
| 18:46 | <annevk> | ritsyy: but we don't want to add spacing between opening tags and text, and closing tags and text |
| 18:47 | <ritsyy> | annevk: oh okay i'll just add the specified and </dd> in the new line |
| 18:49 | <ritsyy> | annevk: for this issue https://github.com/whatwg/html/issues/248 , i was figuring out that, should the line that says about removing the collection of rows/cells when empty just be removed |
| 19:04 | <annevk> | I'm not sure I understand |
| 19:04 | <annevk> | I guess we should test what browsers actually do with those methods when there are no cells/rows to remove |
| 19:04 | <annevk> | And then write that down |
| 19:08 | <ritsyy> | annevk: okay, will do that, thanks |
| 21:58 | gsnedders | wonders if it's worthwhile for the TAG to do anything about testsuites for specs… probably not, but maybe? |
| 22:05 | <TabAtkins> | You mean the lack of them? |
| 22:08 | <jgraham> | OK, without wanting to sound more cynical than is absolutely required, the TAG are about the last people on earth I want pontificating about testsuites |
| 22:09 | <jgraham> | It's not like they're actually going to spend time writing tests |
| 22:13 | <gsnedders> | no, but some of the non-webapps non-CSS groups which have even larger problems with testing do listen to the TAG |
| 22:13 | <gsnedders> | And now the TAG is full of sensible people |
| 22:17 | <jgraham> | Which non-webapps non-CSS groups that will listen to TAG but not plh do you have in mind? |
| 22:24 | <gsnedders> | "but not plh" may well be a decent point :) |
| 23:36 | <nox> | What's TAG? |
| 23:37 | <gsnedders> | Technical Architecture Group, of the W3C |
| 23:38 | <nox> | Do I want to know about any of this? |
| 23:40 | <jgraham> | A few years ago their function was to tell people they had to use RDF for everything and debate HTTP semantics. Then there was a revolution and their function was to tell people that they had to use promises for everything and expose lower levels of the platform to js. Shortly later they decided to get into the pushing-back-against-https game. Now I don't know what they are doing. |
| 23:40 | <jgraham> | Scare quotes implied |
| 23:49 | <annevk> | I think pushing-back-against-HTTPS was only timbl |
| 23:55 | <nox> | jgraham: I see. |
| 23:57 | <hober> | assuming video.controls starts out false and there's a mutation observer on it, does video.controls = true; setTimeout(function() {video.controls=true;}, 0)} fire the MO once or twice? |
| 23:59 | <annevk> | hober: twice |
| 23:59 | <annevk> | hober: setTimeout creates a new task by definition, mutation observers run end-of-task |
