09:01:34 RRSAgent has joined #tagmem 09:01:34 logging to http://www.w3.org/2014/01/07-tagmem-irc 09:01:47 zakim, room for 3? 09:01:48 ok, plinss; conference Team_(tagmem)09:01Z scheduled with code 26631 (CONF1) for 60 minutes until 1001Z 09:02:01 Team_(tagmem)09:01Z has now started 09:02:08 +??P2 09:03:34 zakim, ?p2 is [ODI] 09:03:34 sorry, plinss, I do not recognize a party named '?p2' 09:03:47 zakim, P2 is [ODI] 09:03:47 sorry, plinss, I do not recognize a party named 'P2' 09:04:01 zakim, ?P2 is [ODI] 09:04:01 sorry, plinss, I do not recognize a party named '?P2' 09:04:19 zakim, ??P2 is [ODI] 09:04:19 +[ODI]; got it 09:08:11 projector has joined #tagmem 09:11:55 dka has joined #tagmem 09:12:37 trackbot, start meeting 09:12:39 RRSAgent, make logs public 09:12:41 Zakim, this will be TAG 09:12:41 ok, trackbot, I see Team_(tagmem)09:01Z already started 09:12:42 Meeting: Technical Architecture Group Teleconference 09:12:42 Date: 07 January 2014 09:12:46 +Yves 09:14:24 annevk has joined #tagmem 09:16:07 JeniT has joined #tagmem 09:17:29 -[ODI] 09:19:32 +??P2 09:22:32 ht has joined #tagmem 09:22:43 ScribeNick: ht 09:22:50 Scribe: Henry S. Thompson 09:22:56 Meeting: TAG F2F 09:23:07 twirl has joined #tagmem 09:23:09 Chairs: Dan Appelquist, Peter Linss 09:23:18 Topic: Agenda planning 09:24:04 [Per Wiki: http://www.w3.org/wiki/TAG/Planning/2014-01-F2F] 09:24:10 Agenda: http://www.w3.org/wiki/TAG/Planning/2014-01-F2F 09:29:50 YK: DRM? Draw a line and say "not our pblm"? 09:30:12 YK: Too much politics for us? 09:30:30 TBL: I had hoped for some technical clarification 09:30:38 YK: AB more than us? 09:30:48 TBL: Interop is our business 09:31:19 YK: I think the consensus (minus TBL) was that the proposed technology _would_ harm interop 09:31:52 TBL: Users of [NetFlix] think it's useful -- they are worried about an open platform 09:32:04 YK Tech. focus needed if we put this on the agenda 09:32:14 s/YK/YK:/ 09:32:55 DA: Yes, we need to go back to the architecture of components and interfaces 09:33:31 HST: I'll do a 5-minute intro based on the thread from November [ref?] 09:33:49 TBL: Focus on architecture 09:34:39 -ODI 09:36:54 +??P0 09:37:21 http://www.w3.org/wiki/TAG/Planning/2014-01-F2F 09:39:44 s/November [ref?]/October (http://lists.w3.org/Archives/Public/www-tag/2013Oct/0050.html) 09:40:18 s/November [ref?]/October (http://lists.w3.org/Archives/Public/www-tag/2013Oct/0050.html)@g 09:40:44 s@November [ref?]@October (http://lists.w3.org/Archives/Public/www-tag/2013Oct/0050.html)@g 09:45:10 darobin has joined #tagmem 09:52:21 -ODI 09:53:15 +??P0 09:56:36 last work on logfile was... in 96 10:00:01 -ODI 10:06:00 disconnecting the lone participant, Yves, in Team_(tagmem)09:01Z 10:06:01 Team_(tagmem)09:01Z has ended 10:06:01 Attendees were [ODI], Yves, ODI 10:07:15 Topic: Capability URIs 10:07:29 JT: Ref. previous set of slides 10:07:39 http://w3ctag.github.io/capability-urls/2014-01-03.html 10:08:21 q? 10:08:24 zakim, room for 3? 10:08:25 ok, plinss; conference Team_(tagmem)10:08Z scheduled with code 26631 (CONF1) for 60 minutes until 1108Z 10:08:26 zakim, who is here? 10:08:26 apparently Team_(tagmem)09:01Z has ended, dka 10:08:27 On IRC I see darobin, twirl, ht, JeniT, annevk, dka, projector, RRSAgent, Zakim, wycats_, plinss, slightlyoff, Yves, trackbot 10:08:35 timbl has joined #tagmem 10:08:37 Team_(tagmem)10:08Z has now started 10:08:44 +??P5 10:08:52 +Yves 10:09:35 JT: Discussion happening about why, whether, and how to use Capability URLs 10:10:06 s/Discussion happening/Document discusses/ 10:10:15 s/about // 10:10:34 YK: APIs might need some thought 10:11:00 JT: Haven't got to recommendations on what standardization is needed to help take this forward 10:11:21 JT: My main question is whether we should encourage this 10:11:35 YK: Moot -- they're already in widespread use 10:12:01 JT: So, OK, is the work needed to improve things/standardize/etc. worth the potential improvement? 10:12:26 YK: Well, e.g., Github users risk getting sniffed, overlooked, etc. 10:12:47 JT: There are _lots_ of ways in which URLs get leaked, not just over-the-shoulder 10:12:55 ... e.g. Referrer header 10:13:11 YK: Cross-domain? 10:13:13 JT: I think so 10:13:18 AvK: I think not 10:13:43 s/Cross-domain/Cross-domain when https/ 10:14:35 AvK: Some amount of Referrer control under development, opt-in 10:14:54 YK: Good to have a list of exposure points 10:15:15 Referer policy browsers are converging towards (I think only Chrome has this at the moment): http://wiki.whatwg.org/wiki/Meta_referrer 10:15:32 JT: I have some of these in the document -- plain http is always a bad idea, 3rd-party scripts, ... 10:15:55 q+ to wonder whether the document mentions the comparison with user id that because everyone uses the same capability it is harder to know when the secret is leaked than with username and password. 10:16:08 YK: Best practice: Don't Leak This 10:16:20 DA: TAG recommendation along these lines? 10:17:10 YK: Header which says "this is secret" 10:17:27 AvK: CSP directive ? 10:17:34 й+ 10:17:36 q+ 10:18:08 DA: Risk/exposure is in scope for the document 10:18:43 TBL: The simple observation that putting security in URLs, when URLs are in wide use, is intrinsicly risky 10:18:54 s/observation/observation is valuable/ 10:19:08 YK: Too late to say "don't do this" 10:19:26 JT: Not saying that, saying: here are the risks, consider them before going ahead 10:19:41 YK: Yes, but also, look for mitigation strategies 10:19:53 DA: Suggest a WG do this? 10:20:12 DA: Focus on this document -- what more needs to be done before publishing it 10:20:27 YK: Looks good to me -- but check the Referrer facts 10:21:33 JT: Wrt risks, mitigations are listed: -- always use https, several levels; capability URLs should expire, no links to 3rd-party scripts 10:21:50 YK: Github ones can't be expired 10:21:52 q? 10:22:10 ack twirl 10:22:19 AvK: better _untrusted_ 3rd-party ... 10:22:54 SK: No use of capability URLs by robots 10:23:16 ... Google Analytics, MS Mail, etc. 10:23:27 ... because then open to e.g. searching 10:23:53 JT: Yes, search engines find URLs whereever they can 10:24:08 -ODI 10:24:08 SK: Yes, once you find one, you can find lots via wildcarding 10:24:25 +??P6 10:24:35 JT: robots.txt is only as good as crawlers let it be 10:25:18 TBL: Signalling that a cap URL is an important secret is a bit counter-productive -- it just tells bad guys where to focus their efforts. . . 10:26:05 DA: Well, how can we avoid cap. URLs being crawled if robots.txt isn't the right way 10:26:48 PL: I put poison links at the front and back of every page which I protect with robots.txt 10:27:01 ... Anyone who follows them twice gets firewalled 10:28:32 TBL: Higher level thought: when we think about using URL for important stuff is that if one _does_ leak, then I have no way of knowing who's accessing my data 10:29:09 HST: But you have server logs 10:29:29 TBL: You have IP addresses, but not identity 10:30:11 TBL: So in the document, between 4.1 and 4.2, need something about _recognizing_ compromises 10:30:23 ... That is, how can I tell that it's been compromised 10:30:56 TBL: JAR would be arguing _for_ capabilities 10:31:13 AvK: Capabilities are great, we're talking about using URLs for caps 10:31:22 s/we're/but we're/ 10:31:40 YK: But URLs are the basic currency of the Web, it's natural to want to use them 10:31:59 ... Trying for the perfect cap. system would be too complicated 10:32:16 JT: What about caps via email -- any recommendations? 10:32:35 AvK: At least make it expire quickly 10:33:03 YK: Suggestions wrt shoulder-surfing section should move higher up 10:33:30 JT: Using replace-state means you can't bookmark 10:33:46 ... So the back button won't work 10:34:10 ... the swap mechanism fixes that 10:34:39 ... but not the bookmarking problem 10:34:56 AvK: And that's important 10:35:37 ... Note that gist.github would then be completely useless 10:35:57 JT: OK, so I'll take it out 10:36:16 HST: No, just explain what it doesn't work for/breaks 10:37:16 -ODI 10:37:37 -Yves 10:37:38 Team_(tagmem)10:08Z has ended 10:37:38 Attendees were Yves, ODI 10:37:50 TBL: Suppose all cURLs were recognizable by browsers, then would it be obvious how to modify browsers to do the right thing 10:38:10 AvK: Treat it like a password -- blur, etc. 10:38:35 YK: Yes, doesn't go into history 10:38:44 TBL: But then you can't cut and paste it 10:39:15 YK: I said before, this is a big open-ended topic, suitable for a new (or existing) WG, not us 10:39:58 JT: Another issue wrt moving forward 10:40:19 ... when you have a resource (a doc, e.g.), and there are cURLs to enable others to edit 10:40:35 ... How do you indicate they are all for the same resource 10:40:44 ... rel=canonical isn't really right 10:41:32 YK: Seems like a lot of the semantics are correct 10:41:49 TBL: If I give out two cURIs for a calendar, neither of them is canonical 10:42:14 YK: But one could be 10:42:41 TBL: Giving bad guys too much information? 10:42:59 JT: Not all would be listed, all would point only to the core one 10:43:09 ... And it could be the one with access control 10:43:36 AvK: [Flicker example -- scribe didn't catch] 10:43:54 YK: Making the canon accessed-controlled is the right move 10:44:16 AvK: But we don't want them indexed. . . 10:44:50 YK: Similar to cache -- you want to cache the canonical one 10:45:21 AvK: Hunh? 10:45:43 JT: At least you have some abiitity to do comparisons across users 10:47:29 HST: So, something about this does belong in the document 10:47:53 ... How it does correspond to the core use of canonical to some extent 10:48:06 ... And what it does and doesn't give you 10:48:23 AvK: OK, but not v. important 10:48:35 AvK: The redirecting thing is more important 10:48:45 JT: 301 Moved Permanently? 10:48:47 AvK: Yes 10:49:17 AvK: Say anything about what happens if you try to use a cURL which has expired? 10:49:45 JT: Not sure what the right response is 10:49:49 AvK: 404? 10:50:03 HST: Too weak -- wait, I see, maybe that's right, don't giving anything away 10:50:19 JT: 410 Gone might be more appropriate 10:50:57 AvK: Possible, but not required 10:51:15 YK: But 404 is retryable, but 410 is not 10:51:30 TBL: Does _anyone_ ever distinguish between 4--? 10:51:44 YK: Yes, I did 10:51:58 I don't know any implementation caring about the real meaning of 301 or 410 10:52:03 AvK: I tried using it, people kept re-fetching. . . 10:52:19 is there any browser modifying/deleting bookmarks based on such response? 10:53:09 DA: So what does the doc. say? 10:53:23 HST: See YK's meta-point -- this is part of further work 10:53:48 DA: So add something saying the 410 is right in principle, but may not be well-supported 10:54:35 DA: In practice, if you try for an expired cURL, do you get a 200 or a 404? 10:55:04 YK: Tried an example with gist.github, it gives a 404 10:55:34 AvK: To give a 410, you would have to have a history of your issued capabilities 10:55:51 Actually, keeping a history is probably a good idea anyway, IMO 10:56:30 [Meta discussion about publishing] 10:57:06 HST: +1 to Finding 10:57:08 note that giving a 404 hides that there was a capability 10:57:18 401 leaks that there was one 10:57:33 I vote :shipit: 10:57:35 Yves, yes, 10:58:08 like github giving out 404 for hidden/protected projects instead of 403 10:58:58 HST: Rec Track requires an AC review, I don't think we want to go there 10:59:46 Suggest process going forward: going to working draft, seeking some public feedback, and then publishing as a "finding." 10:59:48 JT: Use 2219 words officially? 11:00:13 AvK: In accordance with them, but not 'officially' . . . 11:01:19 TBL: Referencing the RFC isn't necessary 11:01:42 ... w/o a Conformance section it doesn't make sense 11:02:05 JT: Best Practice boxes. . . 11:02:45 timbl has joined #tagmem 11:02:47 DA: So, yes, publish a (F)PWD, seek feedback, we address, then publish a finding 11:03:10 JT: Not including standardisation 11:03:27 DA: Agreed, but identifying gaps/further work is good 11:03:36 ... w/o discussing solutions 11:04:35 RESOLUTION - we move ahead with the publication of Capability URLs towards a TAG finding. 11:14:42 No 11:19:20 Open issues: http://www.w3.org/2001/tag/group/track/issues/open 11:19:48 TAG products: http://www.w3.org/2001/tag/products/ 11:20:19 Github repo: https://github.com/w3ctag 11:20:56 Spec review list (github issue tracker): https://github.com/w3ctag/spec-reviews/issues 11:25:16 s/No/Topic: Closing issues/ 11:25:52 DA: Should we clarify where we're actually working 11:26:12 ... I've edited the home page to suggest the way we're moving to Github 11:27:43 DA: Do we want to keep any of these issues? 11:28:27 ... Is there things we should bring forward? Or have abandoned or been overtaken? 11:28:38 YK: URIs for packages? 11:29:56 DA: Charter says Issues are what we're working on 11:30:07 ... And we have two places where we are recording them 11:30:30 YK: Propose that onus is on individual to move issue from old list to Github 11:31:04 ht: thanks for that crisper articulation 11:31:05 DA: Proposed resolution: Github issues list shows what we are commited to work on 11:31:38 JT: Archived? 11:31:52 PL: working on that, but not in place yet 11:31:58 This is our github issue tracker: https://github.com/organizations/w3ctag/dashboard/issues 11:32:01 YK: Can be exported at any time 11:34:00 DA: So if we move one, we would need to point back to the old Issue 11:34:13 DA: Happy not to go through the old list 11:35:11 Scribe: JeniT 11:36:19 dka: we should close some of these issues 11:36:22 Scribe: ht 11:36:30 Re issue-60, I propose that we record this as closed since the TAG has published work on this topic. 11:37:46 issue-67: html and xml - we had a task force, we've done everything we intend to do here. 11:37:46 Notes added to issue-67 HTML and XML Divergence. 11:38:14 Henry: issue-64 and issue-65 can be closed 11:40:05 PROPOSED RESOLUTION: Summarily close all other issues except issue-57 unless TAG members wish to reopen them in github. 11:40:54 JT: Close 25, Deep Linking? 11:40:58 issue-25 can be closed - we have published work on this. 11:41:03 DKA: Yes 11:42:47 Issue-40 can be closed as we have completed work in this space - it can be re-opened if there are key URL/URI topics we need to work on. 11:43:45 Closing 40 should mention both capability URL and FragId drafts 11:44:30 PL: Used Postponed to indicate we 'closed' w/o review? 11:45:11 DA: Fooling ourselves? 11:45:41 HST: The substance will persist on the Web regardless of what we call it 11:46:10 PROPOSED RESOLUTION: Summarily mark as "postponed" all other issues (not explicitly noted above) except issue-57 unless TAG members wish to reopen them in github. 11:46:18 PL: Thought it was worth it 11:46:32 TBL: Better to make the distinction 11:46:46 HST: Right, OK, because 'Closed' means we actually _did_ something 11:47:22 RESOLUTION: Summarily mark as "postponed" all other issues (not explicitly noted above) except issue-57 unless TAG members wish to reopen them in github. 11:47:40 Products: http://www.w3.org/2001/tag/products/ 11:47:50 DKA: Moving on to Products 11:48:43 DKA: Obsolete this page, and ref. Github? 11:48:52 ... Not updated for some time. . . 11:48:56 YK: +1 11:49:12 (Note also http://www.w3.org/2001/tag/group/track/products) 11:49:31 PROPOSED RESOLUTION: we obsolete the tag products page, explicitly state on our home page that the current tag work is in github and info can be find in the github readme files associated with each product. 11:51:23 DKA: We can move some things to Completed, and then note that no further changes will be made 11:51:34 RESOLUTION: we obsolete the tag products page, explicitly state on our home page that the current tag work is in github and info can be find in the github readme files associated with each product. 11:52:14 ACTION: dan to make edits to the tag home page and product page accordingly. 11:52:14 Created ACTION-846 - Make edits to the tag home page and product page accordingly. [on Daniel Appelquist - due 2014-01-14]. 11:53:03 DA: Github next, but we need AR for that 11:55:11 Topic: IETF London Action Plan 11:55:26 http://www.ietf.org/meeting/89/index.html 11:55:31 https://www.w3.org/2014/strint/Overview.html 11:56:04 Security workshop (aka STRINT) is 28/2--1/3, Friday and Saturday 11:56:27 DA: Will be in London 11:58:39 DA: I'll be there 11:59:42 DA: Emphasis is, I believe, on technical issues 12:00:17 IETF is at Hilton Metropole 3-7/3 12:00:28 DA: I'll attend the HTTP part of that, at least 12:00:56 Yves, are you going? 12:02:31 DA: What other APPSDIR stuff should we be looking at? 12:02:59 HST: Get Your Truck off my Lawn? We can ask MN tomorrow if he wants any help 12:03:06 HST: JSON? 12:03:11 DA: We'll come back to that 12:09:38 dka, I don't know yet if I'll be there (london ietf) or not 12:32:31 Zakim has left #tagmem 12:45:03 dka has joined #tagmem 12:45:20 We will re-convene at 13:00. 12:45:55 twirl has joined #tagmem 12:57:24 darobin_ has joined #tagmem 13:02:01 http://weather.aol.com/2014/01/06/look-swirling-polar-vortex-over-northern-us-seen-from-space/ 13:02:40 Pause for lunch 13:02:54 ScribeNick: annevk 13:03:00 Scribe: Anne van Kesteren 13:03:57 Topic: Data Activity 13:04:07 Present+ Phil Archer 13:05:13 PhilA has joined #tagmem 13:05:32 http://www.w3.org/2014/Talks/0701_phila_tag/ -> PhilA slides 13:06:33 [Recap: capability URLs will become a TAG finding. If you have feedback slightlyoff please pass it on.] 13:07:05 [We did not close ISSUE-37. If you care about an issue you need to open it in GitHub. We did not talk about HTTP2.] 13:07:20 http://www.opc.ncep.noaa.gov/UA/USA.gif 13:08:24 PA: A decade ago I ended up sniffing around this W3C organization. I ended up in one of Dan's groups. 13:08:28 DA: I take no blame! 13:08:58 PA: If it's data and not something else, say HTML or XML, it's part of the data activity. 13:09:15 [Goes through aforementioned slides.] 13:10:06 s/close ISSUE-37/close ISSUE-57/ 13:10:29 PA: Interested in government data (e.g. mapping criminal activity), but also scientific data, such as free access to papers 13:10:50 PA: in the scientific world there's a question how you can have open access while still have peer review 13:11:41 [Slide projects web applications on one side and spreadsheets/data/etc. on the other side.] 13:12:01 PA: we'd like to bridge the gap between the data and the application, make it easier 13:12:59 PA: if you want to do more involved things with data you end up with semantic web technology 13:13:31 PA: a lot of the RDF stuff is done 13:14:29 PA: if you export to CSV (or tab-separated, etc.) you lose a lot of data 13:15:13 PA: we want to be able to describe the metadata separately 13:15:21 PA: so they can be independent actors 13:16:25 annevk: this is the open-vs-closed dataset issue I keep brining up 13:16:27 PA: we want to find the middle ground between RDF and CSV 13:17:06 annevk: in a world where people have incentives to lie, and data isn't pre-groomed, schemas are suggestions 13:17:13 and say very little about quality 13:18:46 HT: I have a PHD student that works on extracting scientific data out of HTML tables and RDFa 13:20:03 HT: you partition datasets around dimensions such as geography and/or time 13:20:21 HT: then we map these partitions on URLs 13:20:39 HT: so they make sense within the context of the web architecture 13:21:12 HT: and then you end up with HTML tables with RDFa annotation (through a small vocabulary) so the data can be extracted 13:22:12 and generic visualation and processing tools (e.g. Map-Reduce) can be deployed w/o prior knowledge of the particular format 13:22:39 PA: You can see this on e.g. Google when you query "Population of London" 13:22:41 I'll send a link to our XML Prague paper in a week or two 13:23:31 PA: The CSV group is trying a more practical approach 13:23:46 PA: taking existing data and annotating that in a structured way 13:24:05 PA: That's not the only thing, there's another WG on best practices 13:25:49 PA: we need to know how often datasets are updated 13:26:05 PA: whether they are kept alive 13:26:20 PA: how you cite datasets 13:27:41 PA: We have some workshops coming up [see slides] 13:30:13 Topic: Data Activity and the TAG 13:30:26 PA: we might need some work around packaging of data 13:31:22 PA: work around access control and payments 13:32:18 I'm logging. Sorry, nothing found for 'log' 13:32:31 RRSAgent, draft minutes 13:32:31 I have made the request to generate http://www.w3.org/2014/01/07-tagmem-minutes.html annevk 13:33:01 PA: having rendering of maps in the browser directly 13:33:18 AR: What does that even mean? 13:34:22 PA: Have more control over maps in the browser 13:35:05 TBL: when Google Maps started it was precomputed images 13:35:22 TBL: now more of it is vectors 13:35:29 AR: we switched rendering technology, yes 13:35:56 AR: I still don't understand what is being meant here 13:36:00 darobin has joined #tagmem 13:36:30 TBL: Google Maps allows overlays, PA is proposing to have this in 3D 13:40:01 PA: the idea would be to have maps in the browsers, just as you have videos in the browser 13:40:35 [Discussion went into how this would be enormously complex went unminuted.] 13:41:35 [Question about URL fragments.] 13:41:56 JT: There's an RFC for addressing individual cells in a CSV file 13:43:02 JT: There's also addressing data within a packaged file, which is part of a larger issue we discussed before 13:43:31 TBL: Linking into text/plain would be good 13:43:47 JT: There's an RFC [draft?] for that too 13:44:31 [Scribe notes that because browsers render text/plain using text/html you might get some problems there.] 13:45:34 PA: this was about all I had 13:46:02 twirl has joined #tagmem 13:46:36 DA: In the TAG we've been talking about how to add features to the platform. "Extensible Web". I wonder how this relates and what it means to web developers. 13:47:18 DA: There's a huge ecosystem of startups and developers that want to make use of this data and the reality is that people always have to scrape data in the most heinous way possible. 13:48:31 PA: Part of that is political. When the Boris Bikes app went live it used a scraper because the API was not provided. 13:49:39 PA: The scraping went wrong sometimes because of staleness in one of the three mirrors. 13:50:12 PA: After the mayor enforced an open API and the website started using that, everything worked a little better, at the fine tune of one million pounds 13:50:30 [JT mentions it's not really open] 13:50:43 q? 13:50:54 trackbot, this is tag 13:50:54 Sorry, dka, I don't understand 'trackbot, this is tag'. Please refer to for help. 13:50:54 PA: We want to make more data available, with more metadata 13:51:00 trackbot, start meeting 13:51:02 RRSAgent, make logs public 13:51:02 Zakim has joined #tagmem 13:51:04 Zakim, this will be TAG 13:51:04 ok, trackbot; I see TAG_(AWWSW)9:00AM scheduled to start in 9 minutes 13:51:05 Meeting: Technical Architecture Group Teleconference 13:51:05 Date: 07 January 2014 13:51:08 PA: Someone said RDF is not web native 13:51:12 PA: this is not true 13:52:15 TBL: The person that said that is a great hacker. He's trying to make sure the W3C doesn't force RDF on people 13:52:32 TBL: He's a good guy 13:53:25 JT: There was fragment identifiers into packaging 13:53:39 JT: We also think we should package CSV and the metadata 13:53:51 JT: And we need something for that and probably coordinate that 13:59:44 Present+ Phil 13:59:49 Present+ Virginie 14:02:43 AR: For a web developer a CSV file is not useful; I need to bring my own toolchain 14:03:07 YK: JSON is useful because it uses the data structures you are already familiar with 14:03:13 YK: This is also the problem with XML 14:03:46 [and the endemic issue with RDF] 14:04:32 AR: There are two small primitives we added, mutation observers and Object.observe() 14:04:46 AR: They allow for data binding in your application with relatively high fidelity 14:05:26 virginie has joined #tagmem 14:05:43 AR: I can't just have some source of data and render it 14:05:59 TBL: What is missing? The databinding? 14:06:12 AR: Just feeding UI elements with data really 14:06:17 AR: There's no mechanism for that 14:06:40 PA: Here is an example of CSV rendered in the browser 14:07:13 AVK: The point AR made is that you need to write that whole application 14:08:39 TBL: A lot of things that come out of SPARQL are tabular 14:08:55 TBL: What would be nice is to be able to feed a table in your DOM with data 14:09:25 AR: As a web developer my task is to make a table useful 14:09:37 JT: Currently passing around tabular data is extremely poor 14:10:17 AR: What is my API story around some CSV 14:11:54 JT: Way it would fit into the extensible web story - eventually we would like to have native platform API for access csv or tabular data files... that's way off... 14:15:19 AR: It seems to me that even if you describe CSV, there's still no advantage to the web developer 14:15:25 AR: they still need to scrape and do things 14:17:44 [Argument about whether this should be part of the W3C] 14:18:00 PA: I had this same argument with JJ 14:18:08 PA: The XML community has this argument too 14:18:54 TBL: PHP is part of the ecosystem, should we do that? 14:20:50 JT: The group just started out scoping out use cases and requirements 14:21:14 JT: As part of that wondering how it relates to the browser is something we could do 14:21:15 DA: We should be focusing on the interfaces between layers, including the client (browser)... 14:21:34 AR: As a first pass I wonder what it makes sense to parse that 14:23:01 PA: it would be great to have something like Microsoft Excel in the browser 14:23:14 HT: This is about lowering the bar for publishers 14:24:44 HT: Let me make it clear, this is about lowering the bar for producers, in particular 14:25:17 AR: I was curious to know to what extent the question around data life cycle is on the table 14:25:24 PA: We don't have that as a specific thing 14:26:56 AR: Synchronization - if I'm watching a time series i.e. stocks, how do I keep the data [on the client] in sync? 14:28:01 TBL: In an ideal collaborative environment changes happen on all clients simultaneously 14:28:31 AR: I was thinking about best practices 14:28:49 AR: Doing it cleanly across multiple clients is very hard 14:28:54 JT: Not currently in scope 14:29:48 worth pointing to Max Ogden's work on dat in this context too 14:30:09 https://github.com/maxogden/dat 14:30:33 DA: I think it's important to focus on the client 14:30:43 DA: How does this improve the life of a web developer 14:30:56 DA: Hopefully you can help us out here JT 14:31:17 JT: My concern with the CSV group is that it's mostly a SemWeb crowd 14:31:45 DA: My concern with that SemWeb crowd is that they don't get web developers 14:32:16 JT: It might be that they're interested in other things than web developers 14:32:26 DA: Then it might not be relevant to the web platform stack 14:33:26 wseltzer has joined #tagmem 14:38:43 Topic: Web Crypto 14:38:45 [wseltzer joins via webrtc] 14:39:13 Present+ Wendy 14:39:38 VG: We are about to go to Last Call with Web Crypto and would like a review from the TAG 14:39:54 VG: DK asked me to present where we are 14:41:08 http://www.w3.org/2014/01/W3C_Web_Crypto_API_status_january_2014.pdf -> Virginie's slides 14:42:13 [VG goes through slides] 14:45:39 VG: Not much feedback on the specification 14:46:01 VG: The specification is low-level and requires crypto knowledge to do the right thing 14:46:13 VG: That was the sole feedback we got, from Dan Boneh 14:46:43 VG: We were not comfortable defining a high-level API as we were not sure what is correct 14:47:41 API examples here: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#examples-section 14:48:02 dka_ has joined #tagmem 14:49:22 Chair: Peter 14:49:34 TBL: I like that this is at the binary level 14:49:55 VG: We decided to not touch on SSL 14:50:07 VG: We think SSL should be a separate stack 14:50:14 VG: from Web Crypto 14:51:25 VG: The API is shaped around creating a key and then allowing it to be used by the app 14:51:46 VG: Where the key is stored and such is not up to the implementation 14:53:49 q? 14:54:13 VG: We are not here to provide high security 14:55:38 YK: Can you enumerate what is supported? 14:55:41 VG: No 14:56:04 AR: So from a developer you cannot tell which browsers support what. You don't know what is supported. 14:56:37 AVK: Is there a baseline? 14:57:54 AR: There's no baseline because you can remove it 14:58:19 AVK: It seems if there's no baseline developers will end up relying on what's supported across UAs 15:01:46 AVK: What's the idea around interoperability? Is there a race to the bottom? 15:01:57 AVK: Do you have algo Y in browser A and Z in B? 15:01:59 YK: Yes 15:02:45 AVK: That seems bad 15:03:00 Present+ Dom 15:03:26 TBL: What is this implemented in? 15:03:32 AR: C++ 15:03:42 YK: Prolly JavaScript too through Emscripten 15:08:29 ht has joined #tagmem 15:08:30 YK: The process of determining whether an algorithm is present or not is slow and currently synchronous 15:08:35 YK: which seems bad 15:10:17 dom has joined #tagmem 15:10:46 (we should note that we want something like subtleCrypto.availableAlgorithms().then(function(list){ ... }); 15:10:47 ) 15:11:28 also, the specific issue that YK flagged is that Section 18 should ensure that the errors are sent to the Promise error handler instead of throwing errors 15:15:58 AR: Can I implement an algorithm in JavaScript? 15:16:50 http://code.google.com/p/crypto-js/ 15:17:08 http://bitwiseshiftleft.github.io/sjcl/ 15:18:53 AR: Netflix might want to ensure the algorithm they want really is the algorithm they want. 15:19:09 AR: If they can supply the algorithm that would be possible 15:20:00 AR: This would be a secure worker of sorts 15:20:39 AR: That has access to the secure memory the same way these built-in algorithms do 15:21:35 VG: [idea of a trusted worker which would have higher security requirements] 15:24:22 VG: Web Crypto API Key Discovery is an idea from Netflix about reusing a key 15:24:32 VG: Microsoft has implemented an older version of the draft 15:24:43 q+ to ask about common UI for key discovery for security 15:26:15 VG: What are the TAG next steps? 15:26:35 AR: let's say two weeks 15:26:42 action: alex to draft a review of web crypto api 15:26:42 Created ACTION-847 - Draft a review of web crypto api [on Alex Russell - due 2014-01-14]. 15:26:43 VG: thank you very much] 15:26:49 s/much]/much/ 15:28:39 Topic: Security in general 15:29:32 [Small introduction about the various security issues the TAG is looking into, but has no work item on, around TLS, HTTP, etc.] 15:30:34 VG: In W3C there are a couple of groups that discuss security 15:31:27 VG: WebAppSec WG, Web Cryto WG, SysApp WG, Web Security IG (trying to revive this one), W3C AC 15:31:46 VG: I would say the real group working on it is the WebAppSec WG 15:32:08 [Continues going through slides...] 15:36:04 [I'd say we have a strong security community when asked specific questions; I'd ask the TAG's help in engaging the Web community in thinking about security at an architectural level.] 15:36:07 VG: We should have systematic security review 15:37:29 AVK: I'm confident that features implemented in browsers will have to pass security review 15:37:42 AVK: And therefore specifications will have had security review 15:37:48 AVK: We could have more, of course 15:40:42 PhilA has left #tagmem 15:41:27 http://www.fidoalliance.org 16:00:32 virginie has joined #tagmem 16:01:24 https://www.w3.org/2014/strint/program.html 16:01:34 https://www.w3.org/2014/strint/ 16:01:46 Topic: STRINT Workshop (A W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring) 16:02:19 [Censor. Monitor that.] 16:02:40 DA: Should the TAG have an opinion? 16:02:56 AR: Is there anything we can do here? 16:03:18 q+ 16:03:30 [TAG is unsure whether they can do anything meaningful in life.] 16:03:45 RESOLVED: TAG is in favor of world peace 16:04:39 DA: We should raise security on the existing web 16:05:22 A question for TAG: are there Web analogs to the protocol-level principles IETF has adopted (i.e., encrypt all transports)? 16:05:28 HT: It's not clear that would be good for the W3C and IAB at that level to discuss 16:05:50 I'd like to note that the questions are very technical: https://www.w3.org/2014/strint/Overview.html 16:06:02 DH: The TAG could provide structural advice as to how the W3C should handle security manners 16:06:17 q? 16:06:22 ack timbl 16:06:22 timbl, you wanted to ask about common UI for key discovery for security 16:08:32 ht: I agree with that...what high-level things do you think they can accomplish? 16:09:14 A question for TAG: are there Web analogs to the protocol-level principles IETF has adopted (i.e., encrypt all transports)? 16:10:03 [Remote participants are being censored... Unclear whether it's on purpose.] 16:11:22 s/I could tag you as "offensive user" in the webrtc interface…/I think you are all so charming/ 16:11:29 censorship of th elog 16:13:09 High-level, What can be W3C's unique contribution to enhanced security against pervasive monitoring? 16:13:24 wseltzer: what do you think? 16:14:39 seltzer, what do you think? 16:15:22 [Censor has been removed. Most seem happy.] 16:15:25 q+ about Web RTC security requirements described in IETF architecture document 16:15:31 q? 16:15:34 q+ 16:15:46 ack wseltzer 16:16:19 WS: Are there places for web security with non-vague architectural principles. Like recommending TLS on the protocol level? 16:16:29 YK: CSP is one thing we should totally recommend 16:17:01 AR: CSP is defensive-in-depth, helps against certain kinds of attacks 16:17:36 AR: Where are we going with this? 16:17:58 DA: Putting more meat around best practices [link?] we put out before 16:18:28 WS: I plan to attend and propose some inputs 16:19:08 WS: In the IETF there's a question across WGs about what pervasive monitoring means to their protocol 16:19:21 WS: What's the analogous question for the W3C? 16:19:21 dom: there's an uncomfortable question about what performance we'd be willing to give up to get resiliance 16:19:33 dom: I honestly think fingerprinting is a lost cause 16:19:34 there's no resilliance against fingerprinting 16:19:38 right 16:20:08 dom: but it'd be good if users could turn up a slider and become more resiliant to metadata snooping 16:20:53 " 16:20:54 The overall goal of the workshop is to steer IETF and W3C work so as to be able to improve or “strengthen” the Internet in the face of pervasive monitoring. A workshop report in the form of an IAB RFC will be produced after the event. " 16:21:16 dka has joined #tagmem 16:21:38 DH: Is there anything beyond the transport layer that needs tackling? 16:21:47 previous minutes: http://www.w3.org/2001/tag/2013/10/01-minutes.html#item04 16:22:03 DH: Possible answers: 1) No; 2) Yes, X, Y, Z; 3) Yes, but not sure 16:22:17 YK: We know about XSS, CSRF, etc. 16:22:38 DH: This is about pervasive monitoring, not security in general 16:23:01 YK: If I were the NSA, I would government-in-the-middle all the time 16:23:22 s/government/[government]/ 16:23:33 JeniT, in response to your earlier question, possibilities might be in UI, better identity management/authentication, stronger browser bindings for transport security and DNSSEC (DANE) 16:24:01 YK: It's pretty clear that the exploits that exist will be used for monitoring 16:25:50 YK: App has ads, ads can execute code, boom 16:27:02 AR: making pervasive monitoring visible, tamper-evident... [in general more difficult] should be a goal... 16:27:59 +1 on making monitoring tamper-evident 16:28:27 q- 16:28:38 q? 16:29:30 TBL: Should we encourage encryption on the client so the server does not know the data? 16:29:44 AR: With Web Crypto we could enable that 16:33:15 [Scribe missed a bunch :/] 16:33:28 AR: Key management is the thing that's kills crypto systems 16:33:44 HT: Problem for XML digital signatures too 16:35:47 pong 16:36:22 annevk_ has joined #tagmem 16:36:27 TBL: I use PGP, it integrates nicely with the mac client, but the key management is appalling 16:37:54 dka_ has joined #tagmem 16:37:57 action: alex to prepare an input into the STRINT workshop from the TAG 16:37:57 Created ACTION-848 - Prepare an input into the strint workshop from the tag [on Alex Russell - due 2014-01-14]. 16:38:31 ScribeNick: JeniT 16:38:37 VG: One of the STRING topics is webrtc... 16:39:09 ScribeNick: dka_ 16:39:27 s/STRING/STRINT/ 16:39:41 VG: In WebRTC there are some security/identity requirements (from IETF) which need to be addressed... 16:40:13 DH: My understanding is that this will depend on the browser - not from w3c. We provide the hooks on which the browsers can provide the interfaces... 16:40:34 scribenick: dka 16:40:36 DH: It's purely in the domain of the browser. 16:40:58 DH: If you are communicating p2p then you make pervasive monitoring more difficult... 16:42:51 [thanks for the discussion. I'll look forward to following up with you.] 16:46:35 https://www.google.com/moderator/#15/e=20fe09&t=20fe09.40 16:50:11 twirl has joined #tagmem 17:04:55 JeniT has joined #tagmem 17:10:12 Was there a plan about food? 17:10:44 there was the possibility of ordering pizza from Campus I think 17:14:42 Ahhhhh...ok 17:49:38 annevk has joined #tagmem 17:54:20 annevk_ has joined #tagmem 17:59:20 ht has joined #tagmem 18:06:08 timbl has joined #tagmem 18:20:12 JeniT has joined #tagmem 20:29:35 marcosc has joined #tagmem 20:30:06 marcosc_ has joined #tagmem 20:30:10 Zakim has left #tagmem 20:53:20 annevk has joined #tagmem 21:20:19 timbl has joined #tagmem 21:26:12 marcosc has joined #tagmem 21:54:58 marcosc_ has joined #tagmem 22:38:51 marcosc has joined #tagmem 23:14:51 marcosc_ has joined #tagmem