01:16:10 marcosc has joined #tagmem 01:21:37 marcosc_ has joined #tagmem 01:38:15 marcosc has joined #tagmem 02:18:44 marcosc has joined #tagmem 02:20:42 marcosc has joined #tagmem 06:10:22 marcosc has joined #tagmem 08:04:52 timbl has joined #tagmem 08:43:02 JeniT has joined #tagmem 08:43:06 dka has joined #tagmem 08:43:40 rrsagent, start telcon 08:43:40 I'm logging. I don't understand 'start telcon', JeniT. Try /msg RRSAgent help 08:48:11 dka_ has joined #tagmem 08:51:23 Zakim has joined #tagmem 08:54:15 annevk has joined #tagmem 08:57:24 mnot has joined #tagmem 08:59:16 Chair: Peter Linss 08:59:20 Scribe: Jeni Tennison 08:59:24 ScribeNick: JeniT 08:59:49 Topic: HTTP2 (and general IETF topics) 09:00:34 Present: Tim Berners-Lee, Dan Appelquist, Peter Linss, Anne van Kesteren, Jeni Tennison 09:00:45 Present+ Mark Nottingham 09:07:33 Topic: HTTP 2.0 & IETF stuff 09:08:46 mnot: we're 80% done on drafts for HTTP 2.0 09:09:04 ... we have a few meetings, including one in London 09:09:16 ... I suspect we'll then see public implementations 09:09:23 ... technical work done by middle of year 09:09:36 ... done by end of year 09:09:50 ... currently discussion dominated by security issues 09:10:05 ... we're probably not going to require use of TLS 09:10:15 ... market will choose 09:10:56 ... we're on GitHub http://http2.github.io/ 09:11:06 dka: we discussed notion of trusted proxy 09:11:18 ... how's that work going? 09:11:35 mnot: still really early days, we'll talk about it in Zurich 09:11:51 ... there's a lot of interest, less clear that every browser will support new kinds of proxies 09:12:21 ... we're not going to require an enterprise-friendly proxy model, for example 09:13:08 dka: what would be useful from us at this point in the process? 09:13:41 mnot: HTTP 2.0 is a mechanical replacement for HTTP, avoids big issues 09:14:10 ... it would be nice to have clarity for the model for user interaction on the web 09:14:22 ... and the role of intermediaries 09:14:40 slightlyoff: is that hard because the people who own the networks think they own the networks? 09:15:02 mnot: yes, some network vendors are reacting to TLS by doing TLS man in the middle 09:15:23 ... architectural guidance about the model for the web would be useful 09:15:47 ht: the larger question that I'm concerned about is that the framing narrative for HTTP is out of date 09:16:07 ... proxies are a marginal issue as we move to TLS, until we rethink how they work 09:16:21 mnot: do we think that, in the main, those sorts of things can be prevented? E.g., if someone owns the network today, won't they simply lock out devices they don't authenticate (and usually own at a deeper level)? 09:16:22 ... as you said, doing that requires us to think again about what the overall architecture is 09:16:39 dom has joined #tagmem 09:16:44 ... we can go ahead with the technology without doing that 09:17:07 ... your group is focused on the technology, TAG is focused on web platform at the moment, who is thinking about the web architecture level? 09:17:28 mnot: HTTP & web arch as defined is open ended about what proxies can do 09:17:51 ... they can do lots, the network can do lots, the infrastructure has grown up implicitly 09:18:11 ... with TLS, things change, people are talking about do we need a policy language about what you can do with content? 09:18:54 ... if we make fundamental changes to how HTTP can be used and that gets implemented, we upset a delicate balance and I'm concerned about second-order effects 09:19:03 we are responsible for the predictable consequences of our actions. Do we have data? 09:19:16 ... browser vendors have security folks & UI folks with very deep knowledge & understanding for why browsers do what they do 09:19:42 ... without that knowledge, it looks like they're not doing much because it's very subtle 09:19:47 ... we should be having that discussion in public 09:19:53 with the implication that it's not happening in public now? 09:20:46 timbl: in the old days when proxy behaviour was defined, the protocol guaranteed invariants 09:21:18 ... eg what to do with Expiry dates etc 09:21:42 ... I think that's important; even if you can't specify proxy behaviour, can you specify invariants? 09:21:58 ... eg that your content will never get rewritten, that you can depend on certain headers 09:22:54 ... the airport Wifi problem: the proxies completely mess up my machine 09:23:47 ht: that intersects with DNS space, it intercepts DNS lookups 09:24:31 timbl: yes, so two questions: can we specify proxy invariants? and what are we doing about captive portals? 09:24:49 mnot: we're starting to talk about clients talking to the network directly 09:24:57 ... but the answers to a lot of this is "use TLS" 09:25:42 timbl: no, because that just makes you accept bad certificates 09:26:22 ... I want the captive portal to add something at the HTTP level to say "you have to go here to log in to access this page" 09:27:14 twirl has joined #tagmem 09:27:20 ht: just to put a marker down: yes, we should be having discussion across W3C/IETF/browser constellation, before standards phase is completely baked 09:27:33 mnot: we've had discussions within IETF, but we don't have the impetus 09:27:47 ... you need to involve browser, OS vendors, proxy vendors, Wifi alliance 09:27:56 ... it needs concentrated effort 09:28:31 ht has joined #tagmem 09:28:46 slightlyoff: whenever we have these discussions, the captive portal and the TLS proxy come up 09:29:21 Ownership is also at the heart of the [the problem that dare not speak its name] discussion . . . 09:29:50 ... if someone owns a device, they can do what they like 09:30:12 FYI: https://github.com/http2/http2-spec/wiki/Proxy-User-Stories 09:30:16 ... we think that organisations own networks, people own devices, but that's false 09:31:17 ... I don't think we know whether trusted proxies are important or not: do we have data about this? 09:31:38 timbl: I think we also have to imagine worlds that are different 09:32:18 ... when you're thinking about an architecture, considering different use cases is useful and you might not get that from data 09:32:54 ... you can imagine social situations where a trusted proxy is reasonable 09:33:07 ... we might have to imagine them, think outside the box, not just measure what's in the box 09:33:15 ... because the current web is broken in so many ways 09:34:08 mnot: eg BYOD, my employer tells me to install certificates, and they can man-in-the-middle all my traffic 09:34:29 ... we could mitigate that with certificate packages plus a better UI 09:34:48 ... that feels to me like the best type of solution 09:35:04 ... it doesn't solve issues when the employer owns the computer 09:35:30 ... a separate certificate store, and if websites could opt out, refuse service if you're man-in-the-middled 09:35:49 ... proxies would work on harmless pages, but not into banks 09:36:00 dka: maybe that will happen through who upgrades to HTTP 2.0? 09:36:12 mnot: I think it's separable, it's about how the web uses PKI & TLS 09:36:29 ... difference for HTTP 1.0 to HTTP 2.0 should be invisible to end users and mostly invisible to sites 09:37:14 plinss: what are our next steps here? 09:37:22 dka: any other IETF stuff to talk about? 09:37:27 slightlyoff: what about JSON? 09:38:37 mnot: there are no objections currently 09:39:09 slightlyoff: there was a lot of discussion between IETF & ECMA about technical issues and social issues 09:39:23 ... technical issues are resolved, social issues aren't 09:39:33 ... IETF draft doesn't include normative reference to anything else 09:39:46 ... because eg there's no ABNF version in the ECMA version 09:40:10 ... because eg semantics are important, and ECMA doesn't include semantics 09:40:23 ... we have a situation where TC39 has expressed strong frustration 09:40:28 ... TAG has asked for coordination 09:40:37 ... IETF has resolved to do nothing 09:41:19 ... is that accurate? 09:41:38 you dropped 09:42:54 ht: there was a point where things were looking up, there was discussion about what kind of reference might be appropriate 09:45:07 darobin has joined #tagmem 09:46:25 q+ to discuss the media type registration 09:47:23 slightlyoff: the lack of browser involvement in IETF is problematic, particularly if the ECMA documents start changing 09:47:24 (thanks for scribing, JeniT!) 09:47:42 dka: is there still opportunity to make an objection? 09:47:55 mnot: only area directors can make objections 09:48:03 timbl: who's the area director? 09:48:11 mnot: Pete Resnik 09:48:32 timbl: the TAG could talk to him 09:49:28 ... or this is something we could mention at the I* meeting 09:49:34 [some objections to going nuclear] 09:50:29 timbl: this is relevant to liaison between standards bodies, to NIH 09:50:40 ... classic ways in which standards work messes up 09:52:01 mnot: it's really out of Pete's hands right now, it's very late in the process 09:53:58 dka: we could write a blog post about this 09:54:12 mnot: what about the London meeting? 09:54:27 annevk & ht aren't available 09:54:32 dka will be there 09:54:53 mnot: if anyone wants to come along, we can arrange help 09:55:05 ... and there's the STRINT workshop the week before 09:55:39 ... though I'm not sure I'll be there 09:56:03 dka: are there any recommendations for us for London, are there key items or decisions where we should weigh in? 09:56:35 mnot: the agenda should be out soon, we can flag things at that point 09:56:40 plinss: looping back on captive portal issue 09:56:50 ... there's a mess here, but beyond W3C & TAG to fix 09:56:55 ... how could we address it? 09:57:14 mnot: it's surprisingly complex; we can talk about it, starting to describe the problem space would be useful 09:57:29 ... we can start that in HTTPbis and loop you in, engage the folks in the Wifi world 09:57:33 timbl: why Wifi? 09:57:42 mnot: because they run them 09:57:50 ... Wifi roaming and stuff like that 09:58:00 timbl: isn't it DHCP? 09:58:11 mnot: it touches a lot of places in the stack, which is why it's not easy 09:58:26 timbl: it's a broken level breaking situation 09:58:34 ... breaking level at HTTP level would be clean 09:58:57 mnot: I think it's the security issue because DHCP is inherently untrustworthy 09:59:33 dka: would a joint task force be useful? couple of people from TAG, couple of people from HTTPbis to start working on such a document, to define the problem space? 09:59:57 mnot: I can ask in Zurich if anyone's interested, we can ask around browser/OS vendors too 10:00:15 timbl: I'm surprised you're not oozing motivation to fix this 10:00:47 ... I guess it's because it's a web level thing? shouldn't we fix it with HTTP? 10:01:15 ... we could do an HTTP return code tomorrow afternoon 10:01:37 mnot: we standardised one a year & a half ago, but we don't have the contacts with the implementers 10:01:59 ... I think it's useful to write down the problem, and I can put time into that 10:02:29 dka: I can imagine holding a workshop with enough of the right people there 10:02:37 ... but I agree it starts with articulating the problem, as you say 10:02:38 -> http://tools.ietf.org/html/draft-nottingham-http-portal-02 The Network Authentication Required HTTP Status Code 10:02:52 timbl: if you have pointers, that would be useful 10:02:59 ... we can raise awareness at TPAC for example 10:03:07 -> http://tools.ietf.org/html/draft-nottingham-http-portal-02#section-2 428 Network Authentication Required 10:03:28 http://tools.ietf.org/search/rfc6585#section-6 10:03:50 mnot: the only other thing is we're meeting in Zurich, if any of you want to come along, we can arrange that 10:03:52 -> http://tools.ietf.org/search/rfc6585#section-6 511 Network Authentication Required 10:04:16 ... that's 22-24 January 10:04:32 http://http2.github.io/ 10:04:34 http://http2.github.io 10:06:10 Present- Mark Nottingham 10:17:09 http://www.w3.org/2014/Talks/dhm-tag-permissions/ 10:18:16 Present+ Alex, Sergey, Dom 10:18:23 Topic: Permissions for Web Applications 10:18:31 details of our captive portal detection system: http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection 10:19:18 dom: this is a bit of a repeat of a presentation from 2 years ago 10:19:39 ... summary is that there are lots of things on the web that require user consent 10:19:53 ... and lots of ways in which that requirement is addressed, and it's a mess, and I'd like the TAG to help with the mess 10:20:07 [slide 2] 10:20:25 dom: I care about people choosing web over native 10:20:48 ... one thing that people complain that you can't access device features from web apps 10:20:55 [slide 4] 10:21:12 dom: when you use an API to access a hardware feature, you create a new risk for the user 10:21:19 ... a hole in the sandbox 10:21:24 ... privacy risk and security risk 10:21:37 [slide 9] 10:21:59 dom: to protect the user, we've created some mitigations when web apps need to access something 10:23:06 ... we need to get the consent and indicate that consent has been given 10:23:27 ... to highlight that your location is being tracked, your camera is being used 10:23:38 ... how do we keep these decisions meaningful to the end user? 10:23:41 [slide 10] 10:24:10 dom: there's been a preference to avoid prompts, particularly modal prompts 10:24:55 ... the recommendation is to integrate consent into interaction with the user 10:25:12 ... but this is the exception rather than the rule, most APIs use prompting 10:25:12 q+ to point ask whether the app can explain what will be done with the access, e.g. send a tweet the user has aced to send, add a flight in a calendar, download & sell entire calendar, etc etc 10:25:16 [slide 11] 10:25:54 dom: we have a sandboxed model 10:26:10 ... this is good, but creates challenges 10:26:26 ... five permissions involves prompting five times, you can't combine them 10:26:49 ... this is horrible user experience, hard for testing, but too many choices are a bad thing 10:27:23 ... using UI is particularly difficult, with indicators for permissions given, on small screens 10:27:55 dka: eg "your location is being used" gives an icon on the top of the screen 10:27:57 q+ timbl2 to talk about beneficent apps 10:28:13 [slide 12] 10:28:15 http://dontcallmedom.github.io/web-permissions-req/matrix.html 10:28:26 dom: this is a review of specs that require consent 10:28:39 ... I'm not sure this is all the specs 10:28:52 ... the first part of the mess is we don't know how big the mess is 10:29:29 ... there's lots of commonalities in what you want to achieve when asking for consent, but there's no coordination 10:30:00 ht: we should discuss how to get more eyes on this 10:30:21 dom: we should have a better way of getting a picture on this 10:30:35 ... I've chosen a few parameters, based on the issues I'm most concerned about 10:32:45 ... there are different ways to request permission 10:33:04 ... different times at which you ask for permission, two do so upfront 10:33:41 ... difference in how persistent the permission is, where I've documented what happens in Firefox & Chrome 10:34:17 q? 10:34:22 ack timbl 10:34:22 timbl, you wanted to discuss the media type registration and to point ask whether the app can explain what will be done with the access, e.g. send a tweet the user has aced to 10:34:25 JeniT: is persistence defined in the specs? 10:34:26 ... send, add a flight in a calendar, download & sell entire calendar, etc etc 10:34:31 ack timbl2 10:34:31 timbl2, you wanted to talk about beneficent apps 10:34:38 dom: sometimes it's just obvious, but we don't have a structured way of thinking about it 10:35:04 timbl: a lot of this matrix assumes you understand what someone is going to use the data for 10:35:39 ... on the iPhone, apps can ask for Calendar access for example just to put a particular event into my calendar 10:36:05 ... a student analysed use of permissions in Google Play, found that free apps use the Calendar for personal profiling 10:36:45 ... it's important to know the details about how the permission is going to be used 10:37:09 ... a massive difference between sending messages to my friends when I click a button, to when the app feels like it 10:37:55 ... some applications are built to serve the user, beneficent applications 10:38:20 ... and others that aren't 10:39:09 ... it would be good for app stores to have beneficent flags against particular apps 10:39:19 ... we could define what a beneficent app is 10:39:32 ... but also when you ask for a permission, you should say what you're doing with it 10:39:49 dom: one area of activity is about blessed applications 10:40:21 ... on the 'tell me why' question, the model in web APIs so far is that the chrome of the browser will not relay that information 10:40:26 ... because it needs to be trusted 10:40:37 ... but the content of the page can provide that information 10:40:47 ... tell the user why the permission is being asked for 10:40:55 ... that's a good practice for application design 10:41:21 slightlyoff: in Boston I outlined some work that I've been doing arising from Chrome App Store & with Android 10:41:31 ... bundling requests for permissions is useful 10:41:58 ... enabling developers to rely on some permissions being there is broken 10:42:23 ... we should preserve user agency 10:43:10 ... the pattern I suggest people use is that in order to access eg the Calendar, you have to use a Promise, so it's always async 10:43:22 ... the key enabler is that the APIs are async 10:43:34 ... the insulation model is interesting because it grants more authority 10:43:56 ... with regular web content the closest thing we have for authority is CSP 10:44:27 ... eg the timeliness of the geolocation prompt is up to the UA, and browsers differ 10:44:42 dom: I've started to create a set of screenshots 10:44:55 https://github.com/dontcallmedom/web-permissions-req 10:45:50 dom: follow-up work would be to look at other browsers and mobile devices 10:46:02 ... some of this is UA dependent and should remain so 10:46:21 ... but there's a cost of making all of this UA dependent, because it's costly for developers 10:46:37 ... it's useful to align where there's an emerging good practice 10:46:57 ... going quickly through the other parameters 10:47:17 ... next is whether there is an indicator about the permission having been granted 10:47:42 ... also how you can change the given permission, whether you can revoke it or not, which is UA dependent 10:48:06 ... how the permissions work with embedding, eg asking permission from an iframe, this is fairly consistent 10:48:27 ... in Chrome & Firefox you can request permissions from within an iframe, the only exception being with fullscreen 10:48:53 annevk: otherwise a malicious ad could take over the window 10:49:04 timbl: then you could fake something 10:49:20 dom: that's always an issue, and why the UA display the warning 10:49:36 ... I'm not sure whether it's good that an ad can request a permission 10:50:00 annevk: it's good for eg YouTube in an iframe might want to go fullscreen 10:50:25 dom: mostly you can ask for the permission 10:50:42 annevk: even cross-origin? 10:50:55 dom: yes 10:51:06 ... I also looked at what happens when permission is denied 10:51:07 slightlyoff has joined #tagmem 10:51:25 ... there's lots of variation 10:51:44 sorry...wasn't getting updates via irccloud 10:51:49 what'd I miss? 10:51:54 slightlyoff_ has joined #tagmem 10:52:23 dom: I didn't cover everything, there's Crypto 10:52:29 annevk: Push notifications 10:52:32 the model I'm suggesting is something like: 10:52:34 navigator.requestAlarmPermission("reason").then( 10:52:34 function(alarms) { 10:52:36 var a = new alarms.Alarm({ period: 30 }); 10:52:37 alarms.set("name", a); 10:52:37 dom: Application cache has a prompt in Firefox 10:52:37 }, onDenied); // Everything can fail 10:52:45 (on one line this time) 10:52:59 dom: network service discovery might be another one 10:53:09 navigator.requestAlarmPermission("reason").then( function(alarms) { var a = new alarms.Alarm({ period: 30 }); alarms.set("name", a); }, onDenied); // Everything can fail 10:53:11 annevk: is that something we're exposing to web content? 10:53:24 annevk: I think we need to stop thinking in those terms 10:53:47 annevk: the question is more like "will that permission something you'd ever be able to successfully get without an install?" 10:53:53 dom: there are others where there aren't permissions, eg for the accelerometer, though you can detect keyboard through that 10:54:55 ... finally, in the comments, sometimes the permission requests do get merged 10:55:04 slightlyoff: I don't know what an install is 10:55:13 annevk: FFOS has one of these steps = ) 10:55:25 annevk: and you were there in boston when I outlined a system that would enable that 10:55:27 slightlyoff: Firefox OS apps are not web 10:56:13 annevk: not sure why the pedantry.... 10:56:27 I'm not sure we can ever meaningfully teach people a difference between "bookmark" and "install" 10:56:39 would it be useful for us to talk about a combined permission API? 10:56:49 http://dontcallmedom.github.io/web-permissions-req/tests/all.html 10:57:03 dka: slightlyoff, do you have more input here? 10:57:15 slightlyoff: I'm continuing to work at this 10:57:29 ... bundling permissions has no API 10:57:34 annevk: we used to have it, no one wanted it 10:57:38 dom: it got dropped 10:58:05 slightlyoff: often you can't describe what you want to use the permission for 10:58:59 timbl: do you mean in code or in English? you can't enforce it? 10:59:16 slightlyoff: there are some things that we can detect and shut off 10:59:46 timbl: the analogy is with the car, which stops you doing a few things eg suddenly going into reverse, but can't stop you driving on the sidewalk 11:01:18 slightlyoff: coordinating these APIs is something the TAG should have an opinion about 11:01:27 ... do we have enough data to go on? what should that opinion look like? 11:01:38 dom: there's a long term problem about making permissions not suck 11:01:51 ... but also one about managing the existing system so it doesn't get even messier 11:01:56 ... particularly for new APIs 11:02:05 ... this is clearly something that the TAG should look at 11:03:04 [demonstration of asking for all permissions] 11:03:22 [dka's laptop is bricked] 11:04:26 http://dontcallmedom.github.io/web-permissions-req/tests/all.html 11:07:04 dom: with the Firefox UI, you can't do a screenshot, if you click away from it the prompts disappear 11:07:07 ... back to slides 11:07:12 [slide 13] 11:07:36 dom: on desktop, it's a free-for-all, once installed apps have access to everything (or gated by admins) 11:08:06 dka: on Mac when an app accesses the location, you are prompted by the OS & you get an indicator in the menu bar 11:09:06 dom: on mobile it's sandboxed, this is reasonably successful for developers, users less so 11:09:18 JeniT: and you just click yes, like you do for cookies 11:09:39 [slide 14] 11:09:59 dom: SysApps WGs have been exploring a model for getting access to permissions via a trust model 11:10:11 ... they're not quite sure where they're going at the moment 11:10:16 I filed https://bugzilla.mozilla.org/show_bug.cgi?id=957558 based on that page 11:11:07 ... not sure if they can get consensus in the group about all the systems operating with the same permissions model 11:11:40 annevk: those systems are clones of iOS & Android, not interesting for the web 11:12:21 dom: well, that's a question in the SysApps WG 11:12:35 annevk: I gathered they were shifting to working to things that can be exposed on the web 11:12:44 dom: I've been there before on DAP 11:12:57 ... the group is starting to get stuck on this problem as well 11:13:08 annevk: the problem with packaged app is that you're designing a new ecosystem next to the web 11:13:16 ... reusing the technology from the web in a completely different context 11:13:33 ... when we tried it with widgets, we found you can make it work but there's a ton of problems 11:13:37 ... and what you really want is the web 11:14:01 ht: there's a bunch of stuff you get that you don't want, eg access to the file system, but why do you think that's broken? 11:14:18 annevk: I think the main reason they use packaged apps is to get offline to work 11:14:19 [I think I've heard signature as more important than offline for packaged apps] 11:14:40 ... and instead of a decentralised model of distribution you have a centralised model that isn't portable across systems 11:14:47 ... the web has portability built in 11:14:58 ... you're back to having an app store for each device 11:15:15 ... we want to go to facebook.com and get Facebook rather than downloading a new app on each device 11:15:31 dom: packaging is important so that you can sign the app 11:15:42 ... hosted apps are a pain to sign 11:17:22 JeniT has joined #tagmem 11:17:58 s/packaging is important/I've heard that the reason packaging is important/ 11:18:02 slightlyoff: the issue is with static analysis 11:19:05 annevk: eg at Mozilla we want to be in charge with all the bits in a packaged app, for a trust model 11:19:38 dom: you could require Mozilla signing before it's installable on Firefox OS 11:19:49 s/signing/signing hosted apps/ 11:19:52 timbl: you don't have to zip things up to sign them, and you can refer to them through git hashes 11:20:13 annevk: you could have a model where you say you trust certain domains, and the domains get the permissions 11:20:29 ... but those domains can get XSS'd or CSRF'd and then the attacker has access 11:20:38 ... I'm just wondering whether those permissions are needed on the web 11:20:58 ... eg do we need access to TCP sockets (we already have email clients on the web) 11:21:06 timbl: Gmail isn't an email client 11:21:29 ... a web app ought to be able to be a browsers & email clients 11:21:35 q? 11:21:46 annevk: you can imagine that happening 11:22:03 q+ to suggest we partition the discussion into ordinary permissions and exotic permissions 11:22:05 timbl: a trusted app has access to my file system, knows how to send messages out in my name 11:22:20 ... it's very powerful; being able to make programs like that is really important 11:22:54 slightlyoff: how do we achieve this while still having URLs, a unified model that makes sense to web developers & users 11:23:11 ... I think signing is a red herring, I don't think it provides the model we think it provides 11:23:31 ... we should revisit the packaging conversation 11:23:51 ... until we have a web-based solution for packaging, we only talk about them as things that are signed 11:24:12 ... we should unbundle the concerns, we shouldn't talk about these in the context of permissions 11:24:24 ack dka 11:24:25 dka, you wanted to suggest we partition the discussion into ordinary permissions and exotic permissions 11:24:38 dka: I agree, we're talking about two different kinds of permissions 11:25:08 ... eg exotic permissions like telephony 11:25:40 ... I think there's work to be done here, based on Dom's presentation, just on the normal permissions that he's outlined 11:26:07 ... there's some more fundamental things that we might want to look at, rather than bundling it into one conversation 11:26:22 ... exotic permissions involve more complex arguments that involve packaging and signing 11:27:00 timbl: when you use a banking website, you go through additional permissions when you need to make a transfer from when you're checking your balance 11:27:18 ... this could apply to apps too, there are permissions you can give an app based on where it came from 11:27:50 ... but if you're giving it a lot of power then the OS could make a hash of the fixed part of the app, record that it has permissions for that hash 11:28:06 ... or you might check that it's signed 11:28:16 ... that's where I see that going 11:28:58 annevk: I think we want a model where your IMAP client is imap.com rather than some binary blob 11:29:12 timbl: imap.com can be spoofed or DNS hacked 11:29:41 ... I want to have more guarantees about the code that's running on my computer 11:30:11 dom: there are short-term issues and much bigger questions, to look at gaps 11:30:55 http://www.w3.org/wiki/Mobile/articles#API_Permissions 11:30:59 ht: do we have contacts in the HCI community? 11:31:20 ... there's an enormous community that cares about UI 11:31:37 dom: the link is a starting point that summarises research 11:32:11 ... just done on my copious spare time, but a more systematic approach would be really useful 11:32:18 plinss: what's the role of the TAG here? 11:32:22 http://www.w3.org/2014/Talks/dhm-tag-permissions/#%2817%29 11:32:39 ... there's UI issues, models of how we validate permissions, how can we bring benefits to the table? 11:33:05 dom: you've taken a role in reviewing APIs, you should include in that review thought about permissions 11:33:23 ... taking on the larger review that I've started would be good 11:33:45 ... the Web & Mobile [something] Group is having a task force which should help 11:33:58 annevk: we shouldn't be looking at UI 11:34:05 s/[something]/Interest 11:34:13 plinss: yes, we should be looking at the APIs, create a cleaner permissions model 11:34:22 annevk: you want to figure out the UI then figure out what API suits that 11:34:40 dom: I want the TAG to own the problem rather than provide the solution 11:34:52 ... to coordinate the WGs, research etc 11:35:21 ... the problem has been lingering for 5-6 years, and no one has taken ownership of it 11:35:40 ... the TAG is the natural owner 11:35:52 annevk: none of us are UI people 11:36:14 dom: this is a technical architectural problem, you should pull in the people you need to address it 11:36:39 timbl: a lot of people here know bad UI where they see it 11:36:57 dom: the UI is the last piece of the puzzle, the question is how you model permissions for the user 11:37:08 ... we need a more systematic approach 11:37:16 timbl: it has to be grounded in the UI 11:37:59 dom: the TAG should pull in experts from the HCI field 11:38:21 ... from academia & within browser vendors 11:38:52 slightlyoff: our role is to coordinate, we can coordinate coherent API within the web platform 11:39:07 ... but we can't control UI within browsers 11:39:35 dka: there's a grey area 11:39:45 slightlyoff: we need to enable UI 11:40:01 dka: whether or not something is intended to be modal or async informs UI 11:40:13 ... doesn't dictate 11:40:27 plinss: sync API dictates UI 11:40:49 slightlyoff: we can work on the APIs to make them coherent 11:41:12 plinss: we can do things like enforcing async when asking for permission 11:41:21 ... but it's an implementation decision about merging those prompts 11:41:46 ... we should create a unified API but it should facilitate the creation of the UI 11:42:15 dom: the async model is fairly well accepted 11:42:25 ... you have to understand the UI you want to enable to know what the API needs to capture 11:42:35 ... eg the additional explanation about why the permission is being requested 11:42:57 plinss: we don't have to design the ultimate UI, but we can think of the implications of API on the UI 11:43:29 dom: my point is that people have done research on this, you should talk to them 11:43:40 ... but even convergence onto something less messy would be great 11:43:46 ... there's only so much anyone can do 11:43:56 slightlyoff: that's a meaningful & useful thing for us to do, yes 11:44:12 ... if the pattern is flexible enough it might address other problems 11:44:29 dom: if there's some research that's needed, the Mobile Interest Group is willing to help 11:44:32 ... those resources are there 11:44:42 plinss: what specific actions should we take to move this forward? 11:44:58 slightlyoff: we can look at specifics of the APIs in question 11:45:03 ... come up with a best practice 11:45:10 ... evangelise it, ask them to adopt a common pattern 11:45:26 annevk: there might not be a common pattern 11:45:34 slightlyoff: that will come out of the analysis 11:45:43 annevk: I think that's been done 11:46:01 dka: we could start with what Dom's done to help understand what's out there in the wild 11:46:22 E.g. http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html and associated emails 11:46:22 dom: that table might not be accurate & it's not exhaustive, some APIs are undergoing development 11:46:43 ... it would be good for the TAG to ask the WGs which APIs they have that request permissions 11:47:19 ... I also didn't mention is that for getUserMedia permission is that if you request access to the camera you get not just access to it, but information about the other cameras on the device 11:47:27 ... there might be other cases like that 11:47:42 annevk: the page gets controlled over which camera you use? 11:47:57 dom: no, you have to ask for access to the other cameras, but you get told which are available 11:48:40 ... you don't usually have that access, to avoid fingerprinting, but once you have access to a camera you can get a list 11:49:29 annevk: fingerprinting is really easy 11:50:00 dom: there's a difference between active & passive fingerprinting, and between detecting & preventing fingerprinting 11:50:21 ... there's no consensus about this, and the WGs are paying the price 11:50:38 q+ 11:51:06 http://w3c.github.io/fingerprinting-guidance/ 11:51:13 annevk: who says fingerprinting is not a lost cause? 11:51:24 dom: the Privacy Interest Group 11:51:48 ... the direction is towards making fingerprinting detectable 11:52:45 ... look for JSs that looks at all your fonts etc 11:53:11 ... not static analysis, but monitoring the actual access 11:53:43 timbl: meanwhile in Europe, there are laws about data protection 11:53:52 dom: I'm not hopeful about this document. I can think of productive things to do (an tag, e.g.) 11:54:05 ... eg they say that cookies are a problem 11:54:13 dom: but the language here isn't useful 11:54:18 ... how should that be rephrased 11:54:27 ... they could say fingerprinting was a bad idea instead 11:54:56 annevk: the EU law is dreadful 11:55:09 s/EU law/EU law about cookies/ 11:55:32 slightlyoff: websites should only do things that you expect them to 11:55:43 ... a secure program is one that only does what you expect it to and nothing more 11:55:59 ... a trustable website or browser is one that only does things on your behalf, and only what you expect it to do 11:56:18 ... we provide the ambient authority to fingerprint to all content all the time 11:56:38 ... if I go to malicious.com then I expect it to be able to do stuff, but not things that are embedded 11:57:07 ... a technical solution would be to give different permissions/scopes to different actors 11:57:27 timbl: we should avoid having a technical solution that's perverse because it's trying to achieve a mismatched social goal 11:57:47 ... and a social solution (a law) that's chasing a technical solution that isn't a good match 11:59:23 annevk: I once when to the Privacy Interest Group, they were more on the policy side than the technical side 11:59:38 slightlyoff: can we engage with them effectively? 11:59:57 dom: if there was a one-line TAG finding that said fingerprinting was a lost cause, that would be helpful 12:00:15 slightlyoff: we shouldn't conflate current state with our agenda 12:00:33 ... fingerprinting may be a lost cause at the moment, but that doesn't mean we shouldn't want to improve the current state 12:00:52 dom: the question WGs are asking is whether it's something they need to take into account in their API design or not 12:01:07 slightlyoff: it would help to analyse the sets of scenarios people are worried about 12:01:28 timbl: there are different ones: the person in the street is worried about being tracked by ad companies 12:01:42 ... from that point of view it might be a lost cause 12:02:12 ... a different scenario is the malicious operative trying to track a particular individual using a lot of computer power and additional information about that individual 12:02:28 ... and targeting them for a phishing scheme 12:02:54 plinss: we've already taken a position on privacy in API design 12:03:18 annevk: there's a difference between fingerprinting and some of the APIs, which is more about tracking across sessions 12:03:38 ... one makes it easy to track across sessions, and the other one you have to do a bunch of work 12:03:54 ... eg handing out a unique identifier for a given user seems like a bad idea 12:04:10 ... having varying bits across users, similar to what we have for Accept-Language, the User-Agent header, that's OK 12:04:17 ... but the Device-ID is not OK 12:04:31 ... because then if the site has other information about the user they can do way more than they can before 12:04:45 ... you can determine on a bits-by-bits basis whether it's OK to expose the bits 12:04:53 slightlyoff: we should analyse who's doing what & in what context 12:05:12 ... we're concerned about going to example.com and google.com knowing what I'm doing 12:05:38 ... different actors are being composed together with the same permissions and we should look at that 12:05:55 ... imagine we had a sandboxing element you could put around content 12:06:06 timbl: who'd be responsible for doing that? the publisher? 12:06:13 slightlyoff: yes 12:06:30 plinss: a wrapper around content that you don't have control over 12:06:37 timbl: that would be nice 12:07:26 plinss: trying to tie this up into something going forward 12:08:50 ... I'd like to see people take specific actions 12:08:56 ... do we want to write a document? 12:09:21 slightlyoff: we should build on Dom's work with examples, figure out a unification 12:09:48 plinss: who'll pick that up? 12:09:57 slightlyoff: it should probably be me, let's say that 12:10:04 https://github.com/dontcallmedom/web-permissions-req/tree/gh-pages/tests 12:11:19 ACTION: alex to start documenting web permission patterns with code examples 12:11:19 Created ACTION-849 - Start documenting web permission patterns with code examples [on Alex Russell - due 2014-01-15]. 12:11:26 JeniT has joined #tagmem 12:11:35 ACTION: DKA to send mail to chairs to ask about APIs using permissions 12:11:35 Created ACTION-850 - Send mail to chairs to ask about apis using permissions [on Daniel Appelquist - due 2014-01-15]. 13:05:26 twirl has joined #tagmem 13:16:08 http://xkcd.com/1314/ 13:16:34 bkardell has joined #tagmem 13:18:19 https://joindiaspora.com/posts/1653418 13:20:26 twirl: 500 error on link? 13:22:44 Topic: Service Workers 13:24:19 slightlyoff: Service Workers are an in-browser proxy that handle fetches 13:25:09 ... they're origin-centric, installed on your origin, proxying all your requests from that origin to anywhere 13:25:44 ... they're installed the first time you go to the site, but they don't start working right away 13:25:52 ... this is to avoid loading spinners 13:26:07 ... this is progressive enhancement from the network perspective 13:26:43 ... gives programmatic control over requests, responses & caches, but doesn't change how you write your links 13:26:52 ... but scripts can access them 13:27:14 ... they're shared Web Workers, possibly across multiple tabs 13:27:19 ... it can be killed at any time 13:27:53 ... to avoid possibly memory leaky code from running from a long time 13:28:00 ... the process is install then upgrade 13:28:16 ... you should be able to recover from installing a Service Worker 13:28:34 ... you register with navigator.registerServiceWorker("/*", "sw.js", "..."); 13:28:42 ... third argument is CSP stuff 13:28:47 ... returns a Promise 13:28:58 [example content of a service worker] 13:29:56 slightlyoff: use importScripts() to install dependencies (eventually installed through modules) 13:30:23 ... "install" event to set up 13:31:59 ... "fetch" event for all requests from the page or other pages within the scope of the glob of the registerServiceWorker first arg 13:32:37 ... "fetch" events only issued after installation is all done 13:32:51 dka: does the service worker wake up & do stuff on its own? 13:33:14 slightlyoff: we expect in the future there will be data sync, notifications, anything that needs a background context, can be sent to the worker as an event 13:33:30 ... so yes, not yet, but that's coming 13:33:59 ... this is an extensibility point: provide a new type of event 13:34:11 dom: how does the imported script get cached? 13:34:50 yoav has joined #tagmem 13:34:54 slightlyoff: on original registration, the script is imported; all the scripts & dependencies are cached independently 13:35:26 ... user agent will re-request the second arg on the register service worker on a frequent basis 13:36:01 ... import scripts are cached with the original script 13:36:22 plinss: can you add event listeners even when there are syntax errors? 13:36:32 slightlyoff: event listeners don't add anything meaningful 13:36:59 ... we expect listeners to be added through libraries 13:37:51 annevk: when is there going to be a draft spec? 13:38:07 ... eg URL shouldn't be an object here 13:38:11 slightlyoff: yes it should 13:38:58 [pop] 13:39:12 slightlyoff: I'm working on the spec right now, that's my day job 13:39:24 ... we're trying to send a draft spec to WebApps WG in the next month 13:39:30 ... they are expecting it 13:39:47 ... we're working through issues on GitHub 13:39:59 ... implementations are coming, we've been prepping in Chrome 13:40:05 ... Firefox has begun an implementation 13:40:14 ... Twitter has been working on a node.js-based polyfil 13:40:29 ... which will have API compatibility 13:40:57 dom: are you expecting to provide the draft only when the issues are solved? 13:41:09 slightlyoff: once it hangs together ok, not everything solved 13:41:29 ... we just want to cover enough of the ground 13:41:45 ... cache objects were in debate for a long time, but we're keeping them rather than using IndexDB 13:41:58 ... because IndexDB doesn't handle serialisation of an opaque object 13:42:38 dom: how can we spread the word? 13:43:04 https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md 13:43:18 slightlyoff: there are some big open issues 13:43:41 ... same-origin restriction wrt where the service worker script can be hosted 13:43:48 s/word/work/ 13:44:19 ... it's CDN hostile because we do a byte-by-byte comparison 13:45:13 https://github.com/slightlyoff/ServiceWorker 13:45:41 slightlyoff: if I go to example.com and I include a third-party thing that registers a Service Worker, that script will have to live on example.com 13:46:39 ... a compromised third-party server would be able to intercept all fetches 13:47:01 ... it's also possible for the CSP behaviour to cause astonishing things to happen 13:47:14 ... for instance, what happens when I serve the Service Worker script with a CSP header 13:47:20 ... and the document has another CSP header 13:47:41 ... and another navigation goes to the Service Worker and comes back with a CSP header set by the Service Worker 13:48:00 ... these might have different policies, and it's possible to weaken the policies through the Service Workers 13:48:12 dka has joined #tagmem 13:48:16 ... so should there be policy inheritance? 13:48:20 ... we currently think no 13:48:38 annevk: the WebAppSec Group decided that web apps have their own CSP 13:48:52 slightlyoff: the question is about documents created by the Service Worker 13:49:53 ... the CSP policy for the script can be set in the register*() function rather than through HTTP 13:50:06 ... we have it in the function because it's hard to set HTTP headers 13:50:37 dom: that seems like a nice addition but possibly problematic 13:51:25 slightlyoff: the issue is about the CSP policy for the document created in response to the "fetch", by the Service Worker 13:51:40 ... there's also things like Like buttons & Twitter etc 13:53:17 ... composition we thought about was to allow people to use importScript() to embed in handling from third-parties 13:53:29 ... as there's only one Service Worker running at one time 13:53:41 ... eg Font hosting 13:54:14 ... there are lots of third-party services 13:54:32 ... you can't delegate to other origins 13:54:52 ... this is an open question 13:55:09 annevk: you should let the UA deal with not duplicating content on disk 13:55:25 slightlyoff: we could maybe reduce the burden for third-party content 13:56:50 ... if we have big things like fonts, we want a way of having it pervasively available to avoid redownload of something the browser already has 13:57:05 annevk: it's in the browser cache 13:57:22 slightlyoff: the Service Worker's caches aren't the same as the browser caches 13:57:38 annevk: but when fetching the document, the browser is still going to look in its cache 13:57:50 slightlyoff: the browser cache has additional semantics around invalidation 13:58:11 annevk: if it's invalid at the HTTP level, you have to refetch it 13:58:29 zakim, who is here/ 13:58:29 I don't understand 'who is here/', dka 13:58:34 zakim, who is here? 13:58:34 sorry, dka, I don't know what conference this is 13:58:35 On IRC I see dka, yoav, bkardell, twirl, JeniT, slightlyoff, darobin, ht, dom, annevk, Zakim, timbl, marcosc, wseltzer, projector, RRSAgent, wycats_, plinss, Yves, trackbot 13:58:39 zakim, this is tag 13:58:39 sorry, dka, I do not see a conference named 'tag' in progress or scheduled at this time 13:58:46 trackbot start meeting 13:58:48 RRSAgent, make logs public 13:58:50 Zakim, this will be TAG 13:58:50 I do not see a conference matching that name scheduled within the next hour, trackbot 13:58:51 Meeting: Technical Architecture Group Teleconference 13:58:51 Date: 08 January 2014 13:58:53 slightlyoff: there's a similar issue with sites like mobify 13:59:14 zakim, who is here? 13:59:14 sorry, dka, I don't know what conference this is 13:59:15 On IRC I see dka, yoav, bkardell, twirl, JeniT, slightlyoff, darobin, ht, dom, annevk, Zakim, timbl, marcosc, wseltzer, projector, RRSAgent, wycats_, plinss, Yves, trackbot 13:59:29 zakim, start teleconference 13:59:29 I don't understand 'start teleconference', dka 13:59:43 zakim, start meeting 13:59:43 I don't understand 'start meeting', dka 14:00:06 zakim, help 14:00:06 Please refer to http://www.w3.org/2001/12/zakim-irc-bot for more detailed help. 14:00:08 Some of the commands I know are: 14:00:08 xxx is yyy - establish yyy as the name of unknown party xxx 14:00:08 if yyy is 'me' or 'I', your nick is substituted 14:00:08 xxx may be yyy - establish yyy as possibly the name of unknown party xxx 14:00:09 I am xxx - establish your nick as the name of unknown party xxx 14:00:09 xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group 14:00:09 xxx also holds yyy - add yyy to the list of participants in group xxx 14:00:09 who's here? - lists the participants on the phone 14:00:09 who's muted? - lists the participants who are muted 14:00:09 mute xxx - mutes party xxx (like pressing 61#) 14:00:09 unmute xxx - reverses the effect of "mute" and of 61# 14:00:10 annevk: I'm worried about lazy sites that won't load anything until the Service Worker is installed, because it's easier to write the site that way 14:00:10 is xxx here? - reports whether a party named like xxx is present 14:00:10 list conferences - reports the active conferences 14:00:12 this is xxx - associates this channel with conference xxx 14:00:12 excuse us - disconnects from the irc channel 14:00:12 I last learned something new on $Date: 2013-03-03 19:18:47 $ 14:00:48 slightlyoff: people want to be able to intercept their first-load content 14:01:29 slightlyoff: the Quota API is kind of a mess right now 14:01:36 ... we think people are going to hit limits of storage 14:01:52 ... and we don't have a way of notifying them & asking permissions 14:01:55 zakim, what is the code? 14:01:55 sorry, dka, I don't know what conference this is 14:02:04 ... and we can't just invalidate objects in the cache 14:02:22 ... that's current state: we're implementing, spec out for discussion by end of month 14:02:32 Topic: PushAPI 14:03:06 zakim, room for 4? 14:03:07 ok, plinss; conference Team_(tagmem)14:03Z scheduled with code 26632 (CONF2) for 60 minutes until 1503Z 14:05:01 Team_(tagmem)14:03Z has now started 14:05:09 +DKA 14:05:49 ok 14:13:44 -DKA 14:13:45 Team_(tagmem)14:03Z has ended 14:13:45 Attendees were DKA 14:14:04 Ok - we are going to push push until later in the agenda. 14:35:45 Topic: Packaged Apps / Hosted Apps 14:36:07 annevk: hosted apps have their own caching context 14:36:23 slightlyoff: that's useful though, the ability to ask for your own storage partition 14:36:27 dom: it should be an option 14:36:38 slightlyoff: the use case is that the web is horribly insecure 14:36:43 annevk: it's a feature 14:36:50 slightlyoff: you should be able to have some control over it 14:37:02 dka: how do Chrome Apps work? 14:37:09 slightlyoff: they operate in a separate partition 14:37:27 dka: does anyone know how Apple save-to-homescreen web apps work? do they run in a separate partition? 14:37:37 annevk: I don't know, I know Opera Widgets did 14:37:46 dka: I think they don't 14:38:17 slightlyoff: if I'm a bank, I'd want to turn off all the ambient authority granted to all the other things in the world 14:38:29 ... and all the iframes underneath me 14:38:38 ... don't let other tabs poison my experience 14:38:52 annevk: would a bank never want to allow the user to share something? 14:39:16 slightlyoff: in the banking scenario, I can't suggest I want to include things from third-parties 14:39:32 annevk: on a normal bank website, you might to have a personalised map there showing you your nearest bank 14:39:50 ... on the banking bit, where you transact money & stuff, I don't want to do that 14:39:59 timbl: because you don't want to include third-party scripts? 14:40:15 annevk: yes, I'm assuming they want to have it locked down 14:40:57 dom: another use case: say I'm Twitter & I want to enable users to access different profiles 14:41:10 annevk: some browsers have that as a feature, you can have a separate session/profile 14:41:21 ... but maybe it would be better to delegate that to sites, I don't know how that would work 14:41:45 dom: it seems there are reasonable use cases 14:42:03 annevk: I'm having a hard time coming up with attack scenarios in the shared/ambient authority 14:42:47 ... if I'm logged in to Facebook and the bank, who suffers 14:43:29 dom: why are we talking about this? 14:43:33 JeniT: http://infrequently.org/14/tag_01/service_workers.html#1 14:43:52 annevk: hosted apps have their own context, and the question is whether other apps might want to create their own context 14:44:05 ... maybe you want to have an asymmetric relationship 14:44:17 ... the bank can get stuff from others, but others can't get stuff from the bank 14:44:58 dka: the high-level topic was about hosted web apps and the idea that when the user saves the icon to the home screen, the web app executes in a chrome less view in a separate context 14:45:04 ... with its own storage / cookies etc 14:45:21 ... that seems to be something we ought to think about 14:45:45 slightlyoff: this is clearly useful behaviour; it's bundled with hosted apps, but it should be possible for any web page 14:45:57 dom: +1! 14:46:04 dka: this is all over the map at the moment 14:46:18 ... it would be more desirable to have control over it 14:46:34 ... codifying it explicitly, sorting out the questions 14:47:50 ... I think the goal was to prevent normal web to get access to hosted app API/access 14:49:15 annevk: it's an additional layer of security 14:49:24 ... it would at least be defence in depth 14:55:27 slightlyoff: a more common case is abuse of existing tokens, cookies and so on, which should not be stored across storage partitions 14:56:29 dka: is there concrete TAG work on this? 14:56:36 ... or should we let things develop? 14:57:27 slightlyoff: we should ask relevant WGs whether they've thought about this 14:58:01 annevk: we should ask WebAppSec ... it could be a CSP thing 14:58:45 dka: wouldn't Jonas have some strong views on this? shall we ask him to join a future TAG call? 14:59:36 annevk: sure 15:01:00 JeniT: can I help scribe? 15:01:27 Zakim: scribenick: slightlyoff 15:01:57 [discussion of Extensible Web Summit planning] 15:02:13 [ trying to find a venue ] 15:10:27 Wilto has joined #tagmem 15:14:03 Any discussion of format for summit? 15:15:00 bkardell: some discussion of unconference style...annevk is the keeper of the plan, it seems 15:15:06 [ discussion of f2f planning ] 15:15:06 I think it would be important to actively work on getting folks from all the browser vendors there 15:15:14 bkardell: agree 15:16:39 public-nextweb@w3.org has folks who might help organize invitations like that if asked 15:16:55 bkardell: slightlyoff: the plan is to get those folks to attend 15:17:29 bkardell: I don't just want folks from browser vendors, I'd like the implementers and standards people, not necessarily devrel 15:17:46 Yes 15:17:47 and framework web devs 15:18:12 [ more discussion of f2f dates and locations ] 15:18:15 and then not too many of them so it all still fits :) 15:18:52 annevk: that is just what i meant too 15:19:01 I'd like to figure out if we can do the F2F bit of standards in this way rather than in these three-day meeting settings 15:19:16 bkardell: cool cool, I guess we need to confirm a venue first 15:19:37 bkardell: we can discuss registration then 15:20:01 or maybe we should do both at the same time, have a critical mass and then do some kind of occupy movement :p 15:20:30 :) 15:23:25 [ short break ] 15:34:27 ScribeNick: JeniT 15:34:32 Topic: Zip URLs & Packaging 15:34:59 old minutes: http://www.w3.org/2001/tag/2013/10/01-minutes.html#item06 15:35:17 annevk: what's new? 15:35:24 slightlyoff: nothing, and that's the problem 15:35:32 annevk: no one on the browser side seems interested in it 15:35:40 slightlyoff: we're interested in a solution but we don't have a design 15:36:26 ... we looked at zips, and they have no method of providing the content types and the URLs of the items in the package 15:36:40 ... which means you can't just use zips for packaging up 15:36:56 ... the easy solution was multi-part mime 15:37:48 JeniT: in what way is that easy for users? 15:38:16 slightlyoff: the thought was that you would have a tool to do the packaging up into the relevant package 15:38:38 ... the two related problems were about what the format would be 15:38:42 ... and how to address into it 15:38:50 ... and what the origin of the content is 15:39:01 annevk: the problem with multi-part mime was the need to reconfigure the server 15:40:16 ... you can't indicate within the multipart message what the boundary is for the parts 15:41:17 JeniT: why not just have a zip file + manifest, if a tool has to do it anyway 15:41:42 slightlyoff: in a zip file, the contents are listed at the end of the file 15:41:50 ... which is painful when streaming off the network 15:42:50 ... the multi-part mime would mean you wouldn't have a manifest 15:43:23 twirl: to create the package, you have to make HTTP requests for the files 15:43:56 Notes from last time: https://gist.github.com/wycats/220039304b053b3eedd0 15:45:08 JeniT: the reason I'm interested is because of the CSV packaging 15:45:08 scribenick: DKA 15:45:13 ... where we want more metadata anyway 15:46:08 anne: data on the web use case - you have a file and bunch of csv files - youw ant to package them together... 15:46:11 see eg http://dataprotocols.org/simple-data-format/ 15:46:24 AR: let's assume that there is demand and figure out what it looks like. There are open questions about the delimiter and the format. 15:46:26 see also https://developers.google.com/public-data/ 15:46:35 avk: that requires research. 15:46:50 AR: Henry you had views about whether it should be server assisted... 15:47:13 JT: I'm motivated to engage with it. Maybe I should review where we got to... 15:47:35 HT: If the kind of static options- -if that space has been explored and come up dry, then i won't stand in the way. 15:47:42 JT: what way are you advocating? 15:47:59 http://wiki.whatwg.org/wiki/Zip#URLs 15:48:03 HT: the alternative paths we were looking at... 15:48:37 AR: One of the desires yehuda was expressing - you can take a file and put on a server without requiring exotic server configuration... 15:48:54 AR: server-assisted solution might be more elegant but elegant does not mean deployable. 15:49:38 HT: I would like URIs to work - http URIs - either they give 404 or something stable or useful... 15:50:00 HR: the dual nature of the fragment identifiers is intentioned with that goal. 15:50:13 s/HR/HT 15:50:49 HT: Question was how you differentiate frag ids in a component of the collection from he frag ids you use to distinguish those components themselves... 15:50:57 HT: I care about the URLs. 15:51:35 AR: The questions around the delimiters were: it must support fragments, should work in a backwards compatible way, not break in the face of ../, 15:52:29 AR: Don't know what new there is to discuss here... 15:52:47 s/AR/AVK 15:53:17 AVK: this is an invasive change to URL parsers in browsers... for this to happen I suggest it will take a long time... 15:53:28 ... a lot of people seem skeptical of the benefits over http2. 15:53:34 JT: What are the objections? 15:53:41 AVK: The objections are that it will be slower. 15:54:15 ... I haven't really seen many people keen on working on this... 15:54:30 http://esdiscuss.org/topic/generic-bundling#content-62 15:54:33 looks a lot like WAR format for servlets 15:54:36 AR: I think there are people who are keen to get this done... 15:55:25 tbl: one could add an http herder instead but to give a 200 but to return something not what the URL identifies breaks the web. 15:56:12 ... one way to do it is to say here's a zip file and within the zip file (you have a base address within he package) and everything within the package are equivalent to things on the web starting with this space... 15:56:19 ... that gets around the uri problem. 15:56:48 BTW, zip format allows to store metadata assoiciated with files http://en.wikipedia.org/wiki/Zip_%28file_format%29#Extra_field 15:57:11 ... some metadata - whenever you have a URI that starts with (this) within your package then it's equivalent to (this) URL on the Web. 15:57:32 ... I'd like to use 209 for that because you shouldn't give a 200 and not return what the browser asked for. 15:57:52 ... The client asked for something that is the main html page of the package, and the server returns a package. 15:57:58 twirl: interesting 15:58:06 ... at that point it would use a 209. 15:58:27 HT: Why would you do that if you know enough to know it's a package? why not give them what they asked for? 15:58:34 tbl: because what they asked for is too little. 15:58:54 ... you put it in a package because you didn't want to have to think about it... 15:59:31 ht: [argues dumb clients might trip up on this] 15:59:42 tbl: if it's a dumb client it'll just download it. 15:59:51 AR: We don't want to trigger the download UI... 16:00:06 ... that's why we were discussing the delimiter format... 16:00:07 dump clients will always be unable to process directly a package, you need either a capable client, or a server serving flat the package 16:00:43 AR: Content negotiation is fraught.... 16:00:56 ... do we require that only people with new versions of apache can serve? 16:02:05 AR: one potential answer is - we don't need this with http2. 16:02:21 AR: there are others who think it would be nice to be able to publish one file. 16:02:40 AR: you package something up and then you can hand it around as one thing and that enables things like signing. 16:02:52 tbl: It's orthogonal to signing. 16:03:02 AR: Agree. 16:04:15 HT: general points accumulating here: (1) nobody is going to start sending hashes (fragments) across the wire - we're not going to change http 1.1. Hashes don't get sent across the wire. that limits the ways we can use hashes for these purposes. 16:04:27 AR: Don't they get sent? 16:04:32 [consensus no] 16:05:37 HT: (2) if some servers will give different responses to the key requests because they don't recognize server or delimiter then the servers can't use 200 [response] 16:05:59 ... this is new. We can allow something to come back without using 200 or 30x then that's different. 16:06:39 PL: the reason we had the delimiter in the URL was so that the client aware of this format would only sent the URL up to the delimiter. Then a 200 request would be appropriate because you requested the package. 16:07:06 ... the header was so that the client could say "i'm interested in this bit inside." 16:08:17 Yves: we noted last time that we can't use "naked zips" because of the x-domain security consideratins 16:09:08 Yves: the idea is that we need some way to distinguish zips that are meant to be requested-into from those that expect to be "inert" 16:09:21 ScribeNick: JeniT 16:09:40 Yves: in Java Server world there are zips with specific instructions on how to process those zips 16:09:54 ... also parallel with packaged apps 16:10:17 ... something may be processed by the server, maybe processed by the client 16:10:30 ... may have to look at that rather than talking about HTTP codes etc 16:10:54 ... these involve a manifest format 16:11:18 JeniT: what's the motivation for Chrome people interested in this? 16:11:35 slightlyoff: it's about how soon we can expect HTTP 2.0 pervasively 16:11:42 ... and deploying without rsync 16:11:53 ... to have advantages like you have from chrome extensions 16:11:58 and http2 would good for the zip case, as youcan expect that those URIs sill be served form the same URI subtree as the zip itself 16:12:14 ie: taking benefit of its advantages 16:12:32 annevk: but URL parsing will only change long term 16:12:37 slightlyoff: we can change that rapidly 16:12:45 ... it needs to be backwards compatibility 16:13:03 s/compatibility/compatible/ 16:13:43 ... we need the backwards compatibility from exploding the file on the server 16:14:44 timbl: there's lots of implementations of URL parsing, you're not going to update all of them 16:15:14 annevk: you can say that there's a second level of parsing on the normal URL parsing 16:15:34 slightlyoff: I agree, that's why backwards compatibility is important 16:16:12 timbl: a micro syntax of the path is a good story 16:16:35 ... like that not all query strings have the param=value microformat 16:17:30 slightlyoff: browsers that support the syntax would request something different 16:17:51 annevk: it's like someone taking JSON and saying it now allows comments 16:18:41 ... it's suddenly turning around and changing the definition of URLs 16:19:12 slightlyoff: many clients could choose to start to interpret particular JSON properties in particular ways, that's fine 16:19:40 timbl: would you expect curl to change? 16:20:06 slightlyoff: it's only different processing for URLs that contain that particular delimiter 16:21:05 annevk: the core syntax of URLs includes all characters, and some URLs may include particular characters, which you're now interpreting differently 16:21:15 talking about URI delimiter syntax and a-priori processing of it... a good read is https://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-00 16:25:07 JeniT has joined #tagmem 16:25:24 [discussion about whether this would just be http: URLs] 16:25:42 [annevk raises blob and data URLs] 16:26:00 dka: there's been discussion about this vs HTTP 2.0, can you explain how this is addressing the same problems? 16:26:16 annevk: in HTTP 2.0, if you fetch one file the server can respond with other files as well 16:26:23 dka: ah, I see 16:26:46 slightlyoff: this wouldn't be as efficient as HTTP 2.0, where you can have multiple fetches etc 16:27:03 ... this would occupy a space that could shrink with the deployment by HTTP 2.0 16:27:15 dka: you also talked about using this for packaging up a web application 16:27:31 ... which is different, with that package being signed, which I guess HTTP 2.0 wouldn't accommodate 16:27:56 slightlyoff: HTTP 2.0 doesn't accommodate that natively, but it could be done in another way 16:28:10 HTTP2 can also push you content 16:28:40 ht: the concern is that it might change meaning 16:29:21 annevk: you can ask whether . parsing changes the model of the URL 16:30:25 ht: my third piece of guidance to Jeni is that the backwards compatibility is very important 16:30:54 timbl: adding a magic string that would have to be detected in every URL necessitates changes everywhere 16:31:05 ht: did we start out saying this would work for arbitrary schemes? 16:31:08 annevk: I thought so 16:31:27 slightlyoff: I'd be happy for it to be only HTTP 16:31:42 annevk: because blobs, and a bunch of other custom schemes that Mozilla have 16:32:23 Zakim has left #tagmem 16:35:39 timbl: you want a good backwards compatibility story, that's important, but you also have to make sure that the changes that people have to make are limited to those doing HTTP GETs 16:35:53 ... not those who are using URLs in XML namespaces etc 16:36:11 slightlyoff: agreed 16:36:29 annevk: if you introduce new URL syntax then it's going to be generic and significant 16:36:51 ... but if you just do it at the fetch layer, then you can limit it to HTTP 16:38:39 ... URLs already have a problem where different schemes require different parsing 16:38:51 ... generic syntax never really works out 16:43:17 [discussion about polyfilling] 16:44:12 annevk: the killer is relative URL parsing 16:44:43 ht: yes, the standard response to simple solutions was about knowing where to split the path 16:44:48 ... and URLs are in that space 16:45:55 annevk: so if you have a!b where a is a package, b is an HTML document 16:46:03 ... and in b you have a link like ./c 16:46:23 ... you want it to resolve to a!c and it won't 16:46:30 ... without affecting URL parsing 16:46:55 slightlyoff: that's why Yehuda was talking about HTML being separated somehow 16:47:23 annevk: Jonas and Yehuda definitely want this to work 16:47:34 ... and for that you must change the URL parser 17:06:16 [adjourn] 17:47:18 annevk has joined #tagmem