00:49:29 marcosc has joined #tagmem 05:01:35 JeniT has joined #tagmem 06:34:56 SteveF has joined #tagmem 06:54:39 timbl has joined #tagmem 07:23:38 darobin has joined #tagmem 07:45:14 timbl has joined #tagmem 08:00:23 On my way, running late 08:05:32 dka has joined #tagmem 08:08:29 virginie has joined #tagmem 08:09:33 Hiiii 08:17:15 note that I have created some material to discuss here https://www.w3.org/Security/wiki/images/9/98/Web_Authentication_and_other_security_services.pptx 08:17:18 SteveF has joined #tagmem 08:18:38 ok try https://purl-app.com/uhsh43uo 08:19:50 ok 08:20:55 twirl has joined #tagmem 08:23:35 Man London traffic in the morning is bad news 08:33:38 trackbot, start meeting 08:33:40 RRSAgent, make logs public 08:33:40 Zakim has joined #tagmem 08:33:42 Zakim, this will be TAG 08:33:42 I do not see a conference matching that name scheduled within the next hour, trackbot 08:33:43 Meeting: Technical Architecture Group Teleconference 08:33:43 Date: 01 October 2014 08:33:45 ScribeNick: Domenic 08:34:11 dka: we are about to send over some technical feedback on the EME spec 08:35:13 dka: one of the points of discussion yesterday was about how in some jurisdictions it's illegal to do security testing of DRM mechanisms 08:36:26 dka: wondering if we could have some kind of process lever, similar to the patent policy, to compell W3C members who are part of the EME group to agree not to sue companies or individuals doing this kind of security testing 08:37:21 dka: a good point of discussion between the TAG and the AB, as a new kind of policy-level thing 08:38:16 virginie: are you confident this is illegal? 08:38:39 Domenic: yes, anti-circumvention law in the DMCA in the US 08:39:12 twirl: actually that's very controversial. In theory if you prove you have no intent to crack the system, you wouldn't be in trouble. But in practice it is used a lot. 08:39:30 http://en.wikipedia.org/wiki/United_States_v._ElcomSoft_and_Sklyarov 08:39:41 twirl: if I were a security specialist I would be scared 08:40:45 dka: we thought this would be good to bring up because it's not a part of the technical feedback we want to give, but it is important feedback we want to give, if possible. We are not lawyers so we are not sure, but we wanted to bring it up. 08:41:36 s/to crack the system/to violate copyright 08:50:13 https://www.w3.org/Security/wiki/images/9/98/Web_Authentication_and_other_security_services.pptx 08:54:43 https://www.w3.org/Security/wiki/IG/webcryptonext_workshop 08:56:00 virginie: (reviews slides) 08:56:27 virginie: it was asked which features you would be willing to contribute to in the WG? 08:57:01 virginie: (reviews wiki link) 08:58:24 virginie: it was unclear where to put new topics as they were raised; this is a more general W3C issue 08:58:29 http://lists.w3.org/Archives/Public/public-web-security/ 08:58:54 virginie: there were lots of non-members involved in the discussion, so we decided to have the conversation on public-web-security 08:59:30 Domenic: does webcrypto not have a public mailing list? 08:59:40 virginie: it is readable to all, but not writable to all 08:59:49 virginie: also we did not want to disturb the progress on finalizing webcrypto 08:59:56 Domenic: sounds good :) 09:00:29 virginie: the web security interest group does not have resources at the moment 09:00:44 (next slide, "Other topics") 09:01:27 Domenic: how much interest was there from implementers on new features for web crypto? 09:01:56 virginie: definitely Microsoft is interested in having credentials or sensitive information being stored in something that is external to the browser 09:02:54 virginie: Mozilla already has an implementation to integrate with element, but they are not interested in standardizing it 09:03:27 https://wiki.mozilla.org/WebAPI/WebNFC#Fifth_iteration:_Secure_Element_.28Firefox_OS_v2.2.29 09:03:46 virginie: we could define a way to integrate with other secure (authentication) services, which could offer some of the stuff a element could offer, but we would want it to be as open as possible 09:04:11 cf http://www.w3.org/TR/nfc/ 09:04:30 virginie: FIDO alliance is interested in secure tokens 09:04:36 Domenic: but they're not a browser vendor, right? 09:04:37 virginie: right 09:05:14 virginie: unclear whether these next steps are a high priority in the browsers 09:05:57 Domenic: I am scared that you guys will do good work coming up with cool things and then it won't be implemented in browsers 09:09:18 are you talking about http://mikewest.github.io/credentialmanagement/spec/ 09:09:57 yes 09:10:20 (Domenic asked about interest within webcrypto about that proposal) 09:10:41 virginie: there is nothing too security-related here; we didn't have a chane to discuss it 09:10:46 virginie: also unclear where it should go 09:10:54 virginie: maybe webapps 09:11:03 mnot has joined #tagmem 09:11:28 virginie: probably doesn't need cryptographers to review it 09:11:35 virginie: maybe webappssec 09:11:52 virginie: but once again no security concerns, it's basically about managing data 09:12:07 adoption hacks 👍 09:12:22 Yves: webappssec would be a nice place to have this kind of work 09:12:36 Yves: they could help review to avoid e.g. exposing credentials when you don't want to 09:14:48 ScribeNick: wycats 09:15:25 Domenic: good job getting it over the finish line. I understand it was long and hard. 09:15:31 ... and shipping everywhere is good 09:15:41 virginie: it's not done yet 09:15:44 twirl_ has joined #tagmem 09:15:46 Domenic: it's shipping! 09:16:13 virginie: we have to decide whether to include auth in the WebCrypto charter 09:16:26 ... we could use help to avoid creating thousands of working groups 09:16:58 ... your advice would be helpful 09:17:07 ... would you create a new auth WG? 09:17:18 Domenic: it really depends how people want to work 09:17:26 ... for example the mega-web-apps WG seems to work fine 09:17:30 ... other people may not 09:18:20 wycats: it probably depends on whether the exact same group of people in an existing WG is the same group that needs to work on another work item 09:18:51 dka: unless someone doesn't WANT to work on something, expanding the reach of an existing group seems better 09:19:21 ... 09:20:10 thanks for listening, will keep you informed about the next achievement of chartering discussion 09:20:10 Topic: Yesterday's event 09:20:34 dka: where should we tell people to engage if they're interested 09:20:54 ... specifically engagement on our developer activities 09:21:15 mnot: perhaps we want a repo for meta-issues 09:21:48 wycats: opening issues about developer meetups on github is weird 09:22:02 ... I think specifiction is the new mailing list 09:22:11 mnot: who runs specifiction? w3c? 09:22:14 dka: robin 09:23:44 09:23:50 dka: so specifiction 09:24:21 ... I feel like it should be an issue on Github 09:24:24 Domenic: I like Github 09:24:46 ... instead of having many mailing list, it seems Specifiction / Discourse's model is one big list 09:25:04 ... Github is a place to talk about concrete issues 09:26:54 wycats: The way Ember uses Discourse is as a place for unstructured comments that can get routed to Github Issues 09:27:08 Domenic: this is different from the WHATWG's use of mailing list 09:29:31 wycats: it's good to have a sense of what goes on Github, Stack Overflow, etc. 09:29:54 ... but if you just semi-automatically close issues on Discourse, people feel bad 09:29:59 ... this was our experience in Ember 09:30:25 09:30:41 dka: it seems good to have a developer outreach component to our f2f meetups 09:32:10 wycats: it seems like the group of people who show up are from a closed circle 09:32:44 dka: it depends on the city 09:33:57 wycats: I think that JS users are our dominant audience 09:34:23 dka: last night about 1/2 the audience didn't identify as JS developers 09:35:45 dka: so what's the topic in Discourse? 09:35:55 Domenic: "standards / developer interfacing" 09:43:11 darobin has joined #tagmem 09:44:46 darobin ready to join us? 09:44:50 sure! 09:44:57 do I skype you? 09:45:19 or webrtc something? 09:46:30 http://w3ctag.github.io 09:48:10 Topic: URL 09:50:17 09:51:25 wycats: the optics of this are very bad 09:52:17 Domenic: please proceed Robin 09:52:38 darobin: there's a lot of ground to cover 09:52:55 ... the core of the issue is whether the HTML specification can reference the URL specification normatively 09:53:09 ... and in particular whether it's the WHATWG authored version or the W3C copy of it 09:53:24 ... from a technical perspective I think we're ok 09:53:31 ... the HTML spec is pretty modular 09:53:46 ... but there are more complex social and political issues 09:54:30 dka: this is related to an effort to get the HTML5 spec published 09:54:39 ... I had asked Philippe if the TAG could help 09:55:16 ... I had a goal of trying to figure out where we go from here 09:55:34 ... the initial feedback I had from Philippe is that we need a URL spec in W3C space 09:55:48 ... so we talked about using the same approach as the DOM spc 09:56:02 ... it's not a copy 09:56:12 wycats: in what important ways is it not a copy? 09:56:16 dka: it's a reprint 09:56:36 ... but I didn't realize that WHATWG agreed to snapshots 09:56:47 ... and that there was ongoing IPR efforts 09:57:03 ... I don't think it was the right approach 09:57:06 wycats: in what way? 09:57:16 dka: because they were pointing to the CG W3C agreement 09:57:40 ... and a stronger approach would be to use the W3C patent policy 09:58:38 wycats: it was not clear to me before that the normative reference requirements involve a policy that is as strict as the W3C 09:58:43 dka: moving on... 09:58:56 ... we thought maybe there was a middle ground 09:58:59 q+ to try to process the three aspects of this separately 09:59:01 JeniT has joined #tagmem 09:59:12 ... to make it explicit that the spec was a reprint 09:59:23 ... but to get the stronger IPR from the Web Apps WG 09:59:39 ... it feels like we almost got there 10:00:26 wycats: am I correct in understanding that the current state of the debate is about which CSS stylesheet is applied to the document? 10:00:33 dka: that would be very silly 10:00:40 wycats: I agree, that's why I phrased it that way ;) 10:00:46 darobin: there are several issues here 10:01:09 ... 1) the core technical problems with URL 10:01:13 ... it is far from perfect 10:01:22 ... we have browsers that are not aligned with it 10:01:47 ... how do we unify URLs in browsers with how they are used in other systems 10:02:18 ... we probably can't solve it quickly 10:03:16 ... 2) dka said that there was a controversy about what HTML needs to ship 10:03:22 ... and this was framed as requiring a W3C spec 10:04:21 http://www.w3.org/2013/09/normative-references 10:04:32 http://www.w3.org/community/w3process/track/issues/124 10:04:40 ... the current normative reference draft provides a set of considerations 10:05:22 timbl: indeed. I was misquoted. 10:05:36 ... WHATWG specs can be referenced, but there are case-by-case considerations 10:05:45 ... that are defined by the normative reference guidelines 10:07:08 wycats: the mailing list post said "However, based on my conversations with Consortium staff last week, the Director will NOT permit a Proposed Recommendation to include a normative reference to a WHATWG spec" 10:07:13 ... and it would have been good to get clarification 10:07:22 timbl: it was hard to figure out how to reply 10:07:39 ... for example marcos asked why W3C won't accept WHATWG as a peer org 10:07:48 Domenic: I would like that to get resolved 10:08:11 timbl: for example, when you look at the WHATWG charter, it says it's a closed WG by invitation only 10:08:50 ... it's good to know the clear process 10:09:02 ... the WHATWG advertises it as an invitation-only group 10:09:54 darobin: my personal analysis is that the way that HTML interfaces with the URL spec is sufficiently modular and orthogonal that it's ok to reference something we know is going to be updated 10:10:46 ... Domenic and I worked hard on figuring out a way to do joint applications 10:11:06 ... there are some issues right now but we can find agreement 10:11:42 ... I thought the WHATWG did a friendly thing by handing over DOM parsing to W3C 10:12:25 domparsing.spec.whatwg.org redirects to https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html 10:12:37 dka: I think it's good to have HTML5 in the W3C 10:12:38 and I heartily applaud that 10:12:43 as it was realized the W3C is doing a better job there 10:13:19 dka: enterprise IT consultants want to know that it's stable 10:13:37 timbl: people working in the government want to know if they should revise their procurement policy 10:13:49 dka: they find it important to know 10:14:58 q+ to close that rathole 10:16:03 wycats: nobody is waiting for HTML5 to ship in order to use features that are post-HTML4 10:16:16 ... I think it is self-evidently absurd to claim anything of the sort 10:16:21 darobin: we're not going to get agreement 10:16:33 ... I would like to get it to REC to free up resources 10:18:28 Domenic: a core issue is that it's a big web and many orgs doing many things 10:18:46 ... it's unnecessarily combative 10:18:52 q? 10:18:54 ack dar 10:18:54 darobin, you wanted to try to process the three aspects of this separately and to close that rathole 10:19:22 wycats: the high order bit is whether people are implementing 10:19:38 timbl: let me tell you a story 10:20:33 [timbl explains how W3C was the WHATWG before the WHATWG was cool] 10:21:16 Correction to what I said - I think it’s good to have w3c html5 go to Rec. 10:21:25 q+ 10:21:31 q? 10:21:44 timbl: you said the high order bit is that it's where "cool things are happening" 10:21:46 q+ 10:22:01 ... but what about closed membership? 10:22:03 +1 to Domenic 10:22:18 Domenic: I think the WHATWG meets the criteria by any definition 10:22:23 ... there is just a terminology issue 10:22:23 +1 as well, with explict respect to URL 10:22:48 q? 10:23:30 dka: I think WHATWG meets the criteria 100% 10:23:37 ... especially for URL 10:24:21 mnot: I have historically been circumspect about the WHATWG 10:24:35 ... it would be ok if it was closed to browser vendors 10:24:42 ... but with a clear governance model 10:24:56 ... but if the lawyers at browser vendors are ok with the WHATWG, it seems fine 10:25:28 http://tools.ietf.org/html/rfc2026#section-7.1 10:26:50 mnot: there is precedent for incorporating proprietary specifications 10:27:20 wycats: and proprietary standards are strictly worse than what the WHATWG is doing 10:27:52 mnot: I don't think the high bar is actually required 10:27:59 Domenic: and if you look at the OpenStand principles, I think it is very clear that we [the WHATWG] actually adhere very strongly to those 10:28:27 obligatory http://imgs.xkcd.com/comics/standards.png 10:29:10 dka: what does the IETF think 10:29:18 mnot: we'll clean up whatever mess you guys make 10:29:28 :) 10:29:33 ... we are eagerly awaiting the results 10:29:59 ... many IETF people think that this could be solved via a preprocessing step 10:30:23 ... where "this" means the difference between the WHATWG spec and the the RFC 10:30:50 ... there is a difference between URIs and URLs 10:30:55 Domenic and timbl: no 10:33:37 wycats: real-world cases need to worry about the browser's version of "URL" 10:33:51 timbl: keeping things as a preprocessor ("liberal" vs. "conservative" spec) is a good idea 10:34:33 wycats, which browser version. The unparsed one or the parsed one? (or both) 10:34:51 Yves: the semantics of a URL defined in the platform 10:34:58 which includes both 10:35:22 wycats: 100% of web servers in the real world do some error correction 10:35:35 darobin: we had to write a special server for the platform test 10:36:07 mnot: the WHATWG can own URL 10:38:13 wycats: I like how the HTML5 parser works with "error states" + error correction 10:38:13 http://galimatias.mola.io/ 10:38:20 ... I think it's analogous to what Tim wants 10:38:31 there was also one in C 10:39:18 Domenic: can we normatively reference the WHATWG? 10:39:26 dka: the TAG seems to have consensus 10:40:33 dka: maybe we can scope to URL? 10:40:44 Domenic: we can try to make it precedent 10:41:10 ... get rid of the bad blood 10:41:28 dka: the bad blood is there because there is a perception that that the WATWG actors have negative actions 10:41:56 ... we have to end the fighting 10:42:15 wycats: it's not doing anybody (the WHATWG included) any favors 10:42:22 dka and Domenic: confirm 10:44:34 timbl: things have changed in 25 years 10:44:40 ... we knew we were forking the IETF 10:44:41 correction “also because there is a perception that the whatwg actors have ..." 10:45:08 key word “also” - there has been lots of negativity on both “sides” of this topic 10:46:49 tim: [suggests something needs to happen for w3c to consider whatwg to be a “first class standards” body] 10:46:57 [discussion now on what that would be] 10:47:14 My pereception is that it is a first class standards body. 10:47:18 timbl: maybe we could look through the openstand principles and see if we would want to add things, to define how we should interact with any group 10:47:38 I think it's very destructive to say that a standard that is interoperably implemented is "not a standard" 10:47:49 Tim is talking about a specific thing when he mentions OpenStand: http://open-stand.org 10:48:09 more specifically http://open-stand.org/about-us/principles/ 10:48:25 Indeed. 10:50:32 TLDR “I was a pretty respectful teenager” 10:51:05 TLDR "When I was a boy, children had respect for their elders" :P 10:53:47 q+ to point out that the H264 case is at the extreme end of the spectrum 10:53:52 ack mnot 10:55:49 wycats: is strict patent policy actually a requirement for normative references? 10:56:03 Domenic: points out that non-REC docs don't have patent commitments 10:56:30 darobin: it would be awesome if the W3C would help the WHATWG with patent commitments 10:56:46 ... for example, an experimental attempt to get patent commitments through the process 10:56:55 +1 10:57:05 Domenic: via the CG FSA form 10:57:32 dka: telefonica is prepared to make a commitment through that mechanism 10:58:30 confirmed 10:58:32 Domenic: helping the WHATWG getting a better patent process in place is a good longer-term work item 10:59:07 ... it seems like a new process would be helpful 11:01:23 1+ 11:01:24 q+ 11:01:28 q- 11:01:33 https://pad.w3ctag.org/p/resolutions-1oct2014 11:01:37 q? 11:05:45 A proposed resolution here: https://pad.w3ctag.org/p/resolutions-1oct2014 - please help me wordsmith this so that we can have lunch. 11:06:52 [I just want to go on the record as strongly supporting the idea that we as a community need to do a much better job at flagging what's implemented and what's a proposal] 11:07:01 +1 11:07:18 wycats: if the W3C is pointing at a WHATWG spec that is interoperably implemented, it can sure it will not change 11:09:04 marcosc has joined #tagmem 11:10:33 11:10:52 http://www.w3.org/2013/09/normative-references 11:11:11 wycats, IPR in OpenStand is not very strong but is there — Affirming standards organizations have defined procedures to develop specifications that can be implemented under fair terms. Given market diversity, fair terms may vary from royalty-free to fair, reasonable, and non-discriminatory terms (FRAND). 11:14:30 JeniT has joined #tagmem 11:15:11 resolution: With regard to normative references from w3c documents, we agree that the whatwg adheres to open standards principles and that in principle there is no barrier to w3c documents refeferencing whatwg documents normatively. In the specific case of URL being rerefenced from HTML5, we recommend that the W3C HTML5 spec should reference the whatwg URL specification and that between W3C and WHATWG we should continue to resolve any remaining technical and editorial 11:15:12 issues in the spec. 11:15:17 resolution: we are heartened that the WHATWG has made moves towards having a stronger IPR policy. We propose to issue a call for patent commitments via the WHATCG's FSA patent commitment form: http://blog.whatwg.org/make-patent-commitments 11:23:34 rrsagent, make minutes 11:23:34 I have made the request to generate http://www.w3.org/2014/10/01-tagmem-minutes.html dka 11:23:39 rrsagent, make logs public 11:30:33 hm... 11:31:44 This is the raw IRC log: http://www.w3.org/2014/10/01-tagmem-irc 12:09:59 Topic: Modularization / future of specifiction... 12:10:00 darobin: I was hoping to have a prototype implementation of the ideas 12:10:10 ... I'm behind schedule 12:10:20 ... The feedback from the EWS was very positive 12:10:53 ... TLDR modularize HTML to make it easier to contribute to 12:10:57 I have made the request to generate http://www.w3.org/2014/10/01-tagmem-minutes.html dka 12:10:57 ... put everything on Github 12:11:06 ... use Specifiction for broad feedback 12:11:10 ... specific feedback on Github 12:12:17 ... There was a general discussion about the "CSS Problem" aka millions of standards 12:13:37 ... Another thing that came up was that there's quite a bit of interest 12:14:17 ... people want to submit proposals 12:14:24 ... also we want to standardize on bikeshed 12:21:49 wycats: I talked about feature flags once features are being actively implemented so you can build a "canary" version of the spec vs. a "release" build 12:22:10 ... as a way to enable a more "living standard" approach with more stability marking 12:22:51 stability markings... and implementation reports linked as well? (ala caniuse with a finer grain) 12:22:54 12:23:16 wycats: Yves: yes, you would be able to attach implementation reports to a feature name 12:24:08 dka: it seems like there's a lot of synergistic work going on 12:24:22 darobin: we should all be paying attention to what each other are doing 12:25:34 my closing slide from my talk yesterday: http://note.io/1rGZOo3 12:26:27 dka: so what's the plan? 12:26:41 darobin: some tooling and then some experimental work on pulling out a few initial things 12:28:03 Domenic: it seems weird to have the W3C do the modularity work 12:28:12 ... given that it originates with the WHATWG 12:28:17 darobin: it's more of a proof of concept 12:28:36 ... some of the work will be on new features 12:29:17 plinss: is this like the CSS model (for new work only) 12:29:24 darobin: we'll start that way 12:29:41 ... but it's important to know what's been superseded 12:35:37 Domenic: be clear this is proof of concept so as not to confuse developers, other standards people, etc. 12:35:40 darobin: sounds good 12:36:03 JeniT has joined #tagmem 12:36:23 wycats: this isn't intended to be hostile, so let's make sure that we don't come off that way by accident 12:37:05 Domenic: I liked the way you described the different venues for feedback 12:45:54 dka_ has joined #tagmem 12:48:12 morning all. 12:48:16 hi alex! 12:48:31 we are about to start in on extensible web report card brainstorming 12:48:34 can you join? 12:48:41 yep 12:48:54 domenic will be live-editing an etherpad and we hope to transfer this over to a github repo before the end of the day 12:50:44 https://pad.w3ctag.org/p/ew_report_card 12:52:04 and you still can't participte in serializing something that submits a file 12:54:51 do y'all have a camera on? I can't see London 12:57:34 no worries 13:02:04 Zakim has left #tagmem 13:10:08 isn't there work on ambient light sensors? 13:10:34 https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/AAtN0xjI9Gc 13:36:55 brb, coffee 13:44:02 back,s orry 13:44:47 so I'm not 100% sold that ASM.js plays well with others; its default model makes FFI hard from JS and doesn't exactly have a mapping to DOM 13:45:05 it's good, and enabling, but I'm not sure it's "there" 13:45:19 minor quibbles 13:47:04 on it 13:47:22 wycats: see slightlyoff's take above ^ 13:47:34 slightlyoff: 👍 13:48:06 wycats: move to is disruptive in class? 13:48:15 hm 13:48:18 I am concerned 13:48:31 because I am unsure if FFI ever can be optimal 13:48:40 what do you mean by mapping to DOM? 13:48:46 I agree that these are good things to research 13:48:51 it seems like it could be as optimal as the C++ DOM <-> JS mappings that exist 13:48:58 sure 13:49:01 you should be able to get s/C++ DOM/asm.js 13:49:05 dherman: what do you know about this? 13:49:29 could in theory be more optimal 13:49:34 since you could imagine stronger inlining 13:49:40 but I don't know 13:50:22 we've talked about ways to improve the FFI 13:50:28 I agree it's an area that needs research 13:50:36 it's better than its competitors at FFI ;) 13:51:32 lolol 13:51:45 "better than competitors at FFI" -- I want that shirt 13:51:56 "ASM.js -- it's not SWIG" 14:03:51 dka has joined #tagmem 14:17:48 brb 14:18:04 agree that the event loop is something we can call out 14:18:10 also, coordination with other threads 14:18:21 e.g., render thread 14:18:23 audio thread 14:18:24 etc. 14:24:48 sniffing is not exposed 14:24:52 would be a trivial API 14:24:57 window.sniff(blob) :P 14:25:09 window.👃(blob) 14:29:29 back, sorry 14:30:20