08:00:31 RRSAgent has joined #tagmem 08:00:31 logging to http://www.w3.org/2010/06/08-tagmem-irc 08:00:32 RRSAgent, make logs public 08:00:32 Zakim has joined #tagmem 08:00:34 Zakim, this will be TAG 08:00:34 ok, trackbot; I see TAG_f2f()3:00AM scheduled to start 60 minutes ago 08:00:35 Meeting: Technical Architecture Group Teleconference 08:00:35 Date: 08 June 2010 08:01:10 Scribe: Dan 08:01:13 ScribeNick: DKA 08:01:42 Agenda: http://www.w3.org/2001/tag/2010/06/07-agenda 08:09:21 [agenda discussion] 08:10:04 Ashok has joined #tagmem 08:10:21 Topic: Content-type Override (sniffing) 08:10:34 jar has joined #tagmem 08:11:09 Present+ Henry 08:11:13 action-370? 08:11:13 ACTION-370 -- Henry S. Thompson to hST to send a revised-as-amended version of http://lists.w3.org/Archives/Public/www-tag/2009Dec/0068.html to the HTTP bis list on behalf of the TAG -- due 2010-05-17 -- PENDINGREVIEW 08:11:13 http://www.w3.org/2001/tag/group/track/actions/370 08:12:13 ht: Yves is one of the editors of the spec. He has suggested putting our requested text into another section (of HTTP bis). 08:12:45 Yves: We have discussed with Mark. He has suggested [and it was the consensus in HTTP bis] that it should be in the security section. 08:13:04 ht: I think it's the best compromise. 08:15:54 http://lists.w3.org/Archives/Public/www-tag/2010Mar/0114.html 08:16:15 ht: [comparing yves's version to henry's version] 08:16:22 We are reviewing the above email, which has suggested ammendments to the TAG 08:16:29 s proposed HTTPbis text on sniffing. 08:16:31 http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0171.html 08:17:03 ht: this is better than the status quo. 08:17:45 ht: the thing that has been taken out is the idea that you shouldn't do any kind of media type change unless you have evidence to support the belief that the media type is mistaken. 08:18:17 noah: [points to "risks of sniffing" proposed text] 08:19:36 noah: text "type of the actual document" doesn't [scan]. If you have an XML document, it is also text/plain in some sense but if you server it as XML then you are signalling that [the receiver] should process as XML. 08:20:09 ht: I feel that 7.3 [Media Type Issue] in Yves's message is a reasonable compromise. 08:22:04 ht: My feeling is that - I would be happy if we closed this issue with the following email to the [http bis] mailing list - "thank you for your response to our suggestion. The prose offered by Yves would be a significant improvement. Further changes suggested by Mark Nottingham would be [fine] but we're not worried.' 08:22:12 noah: I'm not so convinced. 08:22:58 Noah: I'm not happy with the "may not be that of the actual document" text. Also disinclined to close the issue. 08:24:18 ht: how about a response more like : "thank you for re-opening this issue. We think the version suggested by Yves in his message of 24 March would adequately address our concerns. We're less comfortable with the suggested addition in Mark's message of June XX because it confuses..." 08:25:31 ht: I'm not happy that it goes in the security section because the core question is that it overrides user intent but that's a cost I'm willing to accept for getting the text in the document at all. 08:25:58 Noah: this word - "identify" - bothers me. I don't think the content-type header identifies. 08:26:03 ht: Suggest another word. 08:26:35 Noah: I think it's about the sender's intent. If I send you something as [e.g.] PDF, I don't WANT you to interpret it as text/plain. 08:27:10 [some wordsmithing] 08:27:55 noah: ...correctly convey the intended [type] of the content... 08:28:20 Yves: it's worth clarifying the text. 08:28:37 ht: "does not reflect the intended interpretation of the content" 08:29:00 Sounds good to me. 08:29:23 Noah: ok to seek consensus on this? 08:29:59 Tim: What the TAG often ends up doing is coming up with phrases like this that [can only be interpreted] with a background in Web Arch. 08:30:14 tim: I think the new text is fine. 08:31:46 jar: I wonder what it would be in IETF-jargon? 08:32:26 jar: the core idea in IETF is the stack - e.g. the server automatically provides a content type which is not appropriate at the application level. 08:32:28 Ashok has joined #tagmem 08:33:12 Noah: we could say "we don't think it's appropriate to say that the content type identifies the content" and suggest an alternative. 08:33:21 ht: quotes chapter and verse 08:33:57 noah: anyone unhappy? 08:34:06 noah: i think the right concerns have been laid out... 08:34:45 noah: I propose to put down 370... and look at other actions related to sniffing. 08:35:35 Noah: Larry has written an interesting message in relation to ACTION-425. We could go over it... 08:35:45 ACTION-425? 08:35:45 ACTION-425 -- Larry Masinter to draft updated MIME finding(s), with help from DanA, based on www-tag discussion -- due 2010-05-31 -- PENDINGREVIEW 08:35:45 http://www.w3.org/2001/tag/group/track/actions/425 08:36:01 Noah: Shall we do ACTION-387 first? 08:36:26 ht: should we now bring that message up and review it? 08:36:40 ACTION-387? 08:36:40 ACTION-387 -- Henry S. Thompson to review JK/NM's stuff on sniffing, authoritative metadata, self-describing web, incl. http://lists.w3.org/Archives/Public/www-tag/2010Jan/0025.html -- due 2010-06-07 -- PENDINGREVIEW 08:36:40 http://www.w3.org/2001/tag/group/track/actions/387 08:37:00 timbl has joined #tagmem 08:37:28 noah: The real context for this - we had a set of discussions. John Kemp suggested some updates. I had some concerns... We could leave this to this afternoon when John will join us. 08:37:38 ACTION-425? 08:37:38 ACTION-425 -- Larry Masinter to draft updated MIME finding(s), with help from DanA, based on www-tag discussion -- due 2010-05-31 -- PENDINGREVIEW 08:37:38 http://www.w3.org/2001/tag/group/track/actions/425 08:37:53 http://masinter.blogspot.com/2010/06/mime-and-web.html 08:37:55 http://lists.w3.org/Archives/Public/www-tag/2010May/0063.html 08:38:18 Mail 0063 is a draft from Larry that we will now review. 08:39:04 Yves says http://masinter.blogspot.com/2010/06/mime-and-web.html is the same text, with better format. We'll review that. 08:39:29 ht has joined #tagmem 08:39:31 Noah: Brins up Larry's blog entry. 08:41:37 [group reviewing] 08:41:52 q? 08:44:45 tim: I really like this article. 08:45:29 ... and I like the fact that he's passionate about cleaning things up and has included a list of to-dos. To this is a good role model for future TAG things. 08:46:11 ... now the philosophical rant: there has been some misunderstanding in sem web that the semantics of a fragment identifier depend on mime type. 08:46:35 ... we've been telling people to use a URI name but it also depends on the mime type... 08:47:17 ... so that was the confusion. Both things are true - "this [the fragment identifier] is a name" - and when you dereference it the MIME type [needs to be consistent]. 08:48:32 ... in the RDF spec says "if you want to know what the triples are in this document - this is how you parse them into a set of triples." it doesn't say "some of these URIs may include fragment identifiers." 08:49:05 jar: You're right that it doesn't say that but the RDF/XML media type registration does say that. 08:49:29 http://www.ietf.org/rfc/rfc3870.txt 08:50:21 q+ to discuss 3023 08:51:10 jar: you run into trouble if you're using another type - e.g. RDFa. So the HTML doc you get back from the FOAF namespace URI, it avoids the dual use... 08:51:35 tim: There are two designs and an "un-design" 08:52:14 q? 08:52:54 ... design 2: you can have the same ID being used in a way so that the human reader when they look at an abstract property they are directed to a written description. 08:53:09 ... design 3: "we know what we mean..." 08:54:52 ht: second tim's description on 2nd position. There's a sentence on RFD-3986 which says "there's content negotiation and this notion that the media type defines the sematnics of fragment identifies" concluding : if you sue fragment identifies in context of content negotiation it's your job to see to it that the semantics of the fragment IDs are not incompatible with each other. 08:55:20 http://tools.ietf.org/html/rfc3023#page-16 08:55:24 noah: I see [a potential problem] in the RDF / XML space. 08:55:37 ... this is the spec that defines the "+" convention. 08:57:02 http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming 08:57:17 ... spec the + convention spec [specifically calls out] fragment identification. If you look at that section it says "not defined yet." So there is a potential train wreck coming up. 08:57:38 ht: You're right - this is the definitive statement - but nobody pays attention to it. 08:58:02 tim: What's the solution? 08:58:05 http://tools.ietf.org/html/rfc3870#section-3 08:58:17 ht: It's time to look at this again - it's opportune. 08:59:10 Yves: Pointed to fragment identifier section of RDF media type registation... 08:59:18 Noah: This doesn't resolve anything. 08:59:59 ht: the particular question on 3023 BIS is - it does not give any advice. 09:02:30 noah: the problem is that the + stuff is tricky. 09:03:37 ... there is a published rfc-3023 - to which http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming is a proposed revision... 09:05:01 noah: I would remove "fragment identification" as something that can be [automatically] identified... 09:05:15 q? 09:06:20 ht: I think - if you write in a media type registration document e.g. for SCD+XML - if we define in the W3C spec that defines SCD, "fragment identifier semantics is thus and overrides XML semantics"... then that's [OK]. 09:07:46 ht: you're right - the clear implication of http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-03.html#naming as it stands is that if you use the +XML media type you are licensing all the interpretations on 3023bis. 09:09:18 ... the RDF serialisation can do what it does because 3023 is under-specified. Once this new version comes out, we've got a real conflict. 09:09:30 noah: I think the spirit is very similar. 09:09:38 ht: but the letter is different. 09:11:08 ... quotes: if [xpointerfranework] and [xpointerelement] are inappropriate for some XM-based media types it should not follow the naming convention +XML 09:12:23 tim: two options: A) remove stuff about frag id, leave rdf+xml; B) leave frag ID, remove +xml from rdf 09:12:54 ht: I had in mind a 3rd way: unlike the other properties, fragment identifiers can be overridden in a + spec. 09:13:06 ht: that would still require changing the spec. 09:13:42 noah: [seeking clarification on (A)]: "remove stuff about frag id as part of generic processing" 09:13:49 tim: Yes. 09:14:48 noah: I may have written software that doesn't recognize RDF but does know the + convention. Now that won't work for RDF+XML [responding to Henry's 3rd way]. 09:16:27 tim: [names Henry's proposal: "grandfather"] 09:17:20 ht: fragment identifier interpretation happens... 09:19:16 tim:In your FOAF file you can use an XSLT - 09:19:28 jar: If you serve it as RDF+XML it won't work in a browser - you have to serve it as XML. 09:21:12 noah: what are our options? 09:21:27 jar: 4th option: figure out by context what is identified. 09:21:47 yves: pragmatically that's what implementations will do. 09:22:23 yves: [gives an example involving video] 09:22:29 tim: That should be in the spec. 09:23:59 tim: We could say "the video tag must only be used for pointing to a video and all video mimetypes must use media fragments mime types." 09:24:23 ... if you happen to have scalable video graphics or animated SVG as a video then the mime types must support media fragments. 09:25:00 tim: The TAG should change the architecture document to add that text. 09:25:04 noah: I'm OK with that. 09:27:19 yves: [on using the frag id for specifying a part of a video] if the time-range is unknown for the media type then it is ignored. 09:27:41 ht: whatever happened to vertical bar? | server-side fragments? 09:29:12 ... real question: is this what you said, Jonathan: "it's OK for generic processors to process generically and 'RDF' processors to process specially." 09:29:20 jar: [sort of] 09:30:04 ... so the question is: suppose through con-neg you get 2 completely different documents? Then you'd say "that URI is not a good URI because we don't know what it's designating." 09:30:40 jar: this is the HTTP semantics problem. 09:31:44 ht: if you give an Xinclude processor an XML document to process and it finds xi:include elements with href elements, it will interpret the result as an XML document - unless you say not to. 09:32:09 ... whereas an RDF processor goes the other direction. 09:33:29 noah: I'm more worried about people who run generic tools on documents that are lying around ... 09:33:53 tim: ximclude - can I say "xinclude something#foo" ? 09:33:55 ht: yes: 09:34:00 tim: Then this does break. 09:34:45 tim: if you use that to refer to the element tree, in an RDF document it doesn't refer to an element tree it refers [to a concept]. 09:39:02 noah: [calls a break] we will pick this up again tomorrow. I propose what we do is come back to ACTION-425 when Larry can be with us. ACTION-370 we come back to tomorrow. ACTION-387 we come to this afternoon. 10:06:09 [back from break] 10:10:34 Topic: http semantics 10:11:51 jar: [presents slides] 10:12:20 jar: problems that I see in these discussions on "what do URIs mean / name" etc... 10:12:33 ... these are the sorts of questions that I'm trying to model or address. 10:12:40 ... didn't get as far as I wanted to get. 10:13:19 ... not trying to "define meaning." 10:13:33 ... trying to dispel fear and uncertainty around providing metadata for resources on the Web. 10:16:46 ... needs to be grounded [in operational interpretation] but not too soon - you do it formally so what you do has broad applicability. 10:17:13 ... [presents "http semantics landscapes: exchanges" diagram from slides] 10:19:39 ... this is not a class diagram. 10:20:05 ... it's a template for diagrams involving instances. 10:22:43 ... the point is: you can do an ontological account - a scientific account - looking at what really happens in an HTTP exchange. 10:23:26 ... [introducing "exchange variability" diagram] if you want to look at patterns - 10:23:29 BTW: Agenda has been updated at http://www.w3.org/2001/tag/2010/06/07-agenda 10:24:30 ... you can have 2 different request messages that contain the same URI. They can lead to 3 different request messages... This leads to a cascade of events. Eventually you'll have a response. The outcome of these 3 exchanges are these 3 different representations. 10:24:45 ... [e.g. 2 are in PDF and 1 is in HTML] 10:25:20 ... there are some properties of the representation which are common and some which differ. 10:25:34 ... talking about "properties of exchanges." 10:26:26 ... subclasses of exchanges: defined by restriction or by inclusion. 10:27:38 ... in this modelling, we have some basic axioms already emerging - e.g. "every exchange has a send request." 10:28:12 ... which can be expressed in OWL... 10:29:38 ... even with this minimal theory you can do something interesting - e.g. dated URIs used at W3C - a resource with an interesting property in that it only has one representation. It is possible to model meaning to an extent. 10:31:14 HTML Working group draft HTML/XHTML Compatibility Authoring Guidelines now linked from our agenda...we should discussion in tomorrow's revisit of XML / HTML integration 10:31:24 Link is: http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html 10:31:54 ... you could talk about the class of exchanges with this URI - class of exchanges with this URI possesses this invariant. 10:34:11 ... so classes of exchanges talking about invariance on a representation, invariance on the exchange, ... 10:34:38 ... you can also talk about the relation of these exchanges to the world. 10:35:36 ... there are ways you can specify classes not just on restrictions on individual members - you can say "these particular members" or "has been accessed twice" ... 10:37:13 ... [in response to question by Ashok] the origin is specified as a string and a port number... those would be properties of the exchange. If you wanted you could have rule - if the exchange was on this origin then do this... a restriction. 10:38:10 Ashok: It would make this more useful [to add rules]... 10:38:25 jar: you need a good foundation first... 10:38:42 ... [back to slides - "subclasses of Exchange" slide 2] 10:39:37 ... some subclasses: empirical / promise / API / constraint 10:40:44 tim: here we're talking about network protocols and meaning. 10:41:32 ... there are social protocols - e.g. when somebody lies - in order to design something in the real world you need to consider all the possible things an "evil" person could do. Some of these cases you don't have to worry about. 10:41:59 ... we need to distinguish between modelling how things are supposed to work and what happens when they don't work. 10:42:16 jar: this gives a start... 10:42:45 ... 10:43:36 tim: what's interesting to me - what the TAG says is a meta-level promise. If "people behave" the TAG will promise that the server will never complain that people have accused them of saying something they didn't say... 10:44:22 [brief toilet-role discussion] 10:44:34 s/role/roll/ 10:44:58 jar: [back, thankfully, to the slides] 10:45:33 ... you can say : all the exchanges I've observed are members of the following class... 10:46:28 ht: is the following claim a claim you want to make; 2 exchanges that differ in ways which are not captured by these classes are actually not different in any interesting way? 10:46:47 jar: is that a definition of interesting or a consequence of interesting? 10:46:51 ht: definition, I guess. 10:47:10 jar: [my point] 10:47:26 s/[my point]// 10:48:40 tim: [gives example of how ethernet cable gives a promise of containing ethernet packets] 10:50:34 jar: hypotheses - take e.g. dublin core metadata - if you make an assertion that something has this dc:title, etc... there are different ways to interpret that but one way to interpret is that the representation will satisfy those dublin core properties. 10:52:26 yves: when you have a promise - that somebody made the assumption that something will happen - there is a link to time - during this time X the promise might change... 10:52:39 jar: promises might go bad. 10:52:55 ... the time at which it happened is a property of an exchange. 10:53:52 ... last subclass of exchange: induced. 10:54:44 ... if you're a librarian or a scientist, what you're interested in talking about is content, data, measurements, ... 10:55:09 ... e.g. a telescope is an example of an "induced" resource. 10:55:58 ... [more on induced exchange classes] 10:58:33 ... maybe for each kind of thing that you want to allow 200 responses for you state [what happens]. 10:58:44 tim: this is why it's important to model the semantic web stuff. 11:00:31 jar: the question of "what is an information resource" is a rat-hole. The interesting question is what classes of exchange are appropriate to this information resource? And if the answer is "none" then [maybe?] it's not an information resource. 11:01:07 ht: what kinds of differences between representations would be allowed for representations of the same resource? 11:02:52 jar: suppose i want a class of "news sites"? I can do that. but if I were to do that with something that today provides news but tomorrow is frozen in time then tomorrow it wouldn't be news. 11:04:00 yves: the news site is a good example. If you do a get on newssite.com/latestnews then you get back something with a timestamp... 11:05:40 ht: brian smith wrote "semantics of clocks" article - [jar] said you could say "an internet clock is a good internet clock if it returns the accurate time in the response." you could say something parallel about news sites... 11:06:38 DKA: Can you define art? 11:07:01 Scots law requires that responses to offers of oral contracts must be "timeous" for the contract to be binding 11:08:54 jar: I wanted to touch on validators as a possible application. Web architecture validators. A Link http header could be way to communicate promises. Even if you're the one making the promise you might want to self-monitor with a validator. 11:09:57 ... [digression] a promise is a speech act and it has parts. 11:11:32 .... we now have 10 active metadata ontologies - e.g. "on this web page there is a mention of this gene" if they use the URI as the subject of that statement then they are worried it might change, the con-neg might go wrong, etc... 11:11:44 ... their fear is that they won't be understood. 11:12:50 ... what is acceptable to this audience now is things like web citation - "from this URI I got the following stuff or some stuff with these properties at this date..." 11:13:24 ... the link header might give some assurance - if it says "this is stable content" - they would have more assurance to be able to use that URI as a subject. 11:13:45 tim: so "persistence commons" 11:14:53 ... w3c has a draft persistence policy... 11:15:46 yves: they don't want to use the URI because it might change... 11:16:51 ht: there isn't a transparent way to write a URI which is recognisably a reference to a published journal article. 11:17:18 jar: you can say "info:doi/" - [with some caveats] 11:18:14 ht: [+1 to the idea of a validator] 11:18:19 noah: wrap for lunch? 11:28:09 jar has joined #tagmem 11:35:40 Zakim has left #tagmem 12:15:58 http://npdoty.name/location/ 12:31:05 DKA has joined #tagmem 12:37:05 scribenick: ht 12:37:12 scribe: Henry S. Thompson 12:37:19 RRSAgent, location? 12:37:19 I'm logging. Sorry, nothing found for 'location' 12:37:49 Topic: Client-side storage 12:37:51 AM: http://www.w3.org/2001/tag/2010/05/WebApps.html 12:38:05 [AM speaks to the doc't, not scribed] 12:40:29 NM: Is this an API spec? 12:40:41 http://www.w3.org/TR/2009/WD-webstorage-20091222/ 12:40:45 AM: Yes 12:41:44 NM: In this design, the javascript gets the data and can do what it wants, but the browser doesn't do anything automatically (c.f. cookies) 12:41:49 AM: Yes 12:42:44 AM: Name-value pairs 12:42:57 JR: 1970s-era file system 12:43:19 AM: Maybe name-value pairs plus indices 12:43:46 NM: What is index good for that names can't do 12:43:59 AM: More like a database 12:45:45 Google Gears was an example 12:46:19 s/an example/there/ 12:46:53 ... with SQL-like access 12:47:04 ... but not typed 12:47:55 ... WebSQL was based on this product 12:48:34 Web SQL: http://dev.w3.org/html5/webdatabase/ 12:48:35 ... Hasn't progressed because there is only one (proprietary) implementation 12:49:02 ... But it looks like the indexed API is going ahead 12:49:27 ... More efficient than simple name-value 12:49:38 The note from the Web SQL spec: his specification has reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. Until another implementor is interested in implementing this spec, the description of the SQL dialect has been left as simply a reference to Sqlite, which isn't acceptable for a standard. Should you be an implementor interested in imp 12:49:57 ... contact the editor so that he can write a specification for the dialect, thus allowing this specification to move forward." 12:52:35 JR: You don't need CORS . . . 12:52:39 [scribe lost] 12:53:11 NM: App has javascript from A, tries to get stockquote from B, not possible w/o CORS 12:53:45 ... Same thing applies once we have local storage -- JS from A wants stored information originating from B 12:53:59 DKA has joined #tagmem 12:55:06 TBL: Suppose we had a consistent access-control ontology 12:55:20 ... with people, and sites, and origins 12:55:42 ... and reconstruct something similar to CORS, but more general 12:55:46 http://dev.w3.org/html5/webstorage/#privacy seems problematic to me - full of MAY clauses... 13:01:52 yes. 13:02:27 "User agents may, if so configured by the user, automatically delete stored data after a period of time." or configure by the (eg) bank. 13:03:05 AM: Agreed 13:03:12 NM: How do we follow up on this? 13:04:38 AM: It's possible that the 'may' is opening the door for something like CORS 13:05:41 "User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas." -- that is the user expressing trust in a set of code - that is equivalent to software instalation 13:06:18 DKA: [Eudora example] 13:06:29 TBL: You have a local IMAP cache 13:06:43 ... some clients expose the cache in IMAP format 13:07:25 NM: what about a better GMail searcher, which would need special permissions to get at the GMail cache 13:08:05 TBL: Facebook is using web storage, and LinkedIn offers better functionality if you allow it in 13:08:13 DKA: I want to build that using OAuth 13:08:23 NM: But it won't work offline 13:08:49 DKA: Yes it will, it will keep working on my behalf [between the two, w/o my participation] 13:09:09 TBL: That's going all the way down the road to trusting big services 13:09:27 ... I'd like to be able to run my IMAP client offline 13:10:03 DKA: But now a polluted website can inject a script which can harvest my email 13:10:28 TBL: There's no such thing as a little bit trusting 13:11:53 NM: Distribution is a complex issue 13:12:22 ... This whole thing also breaks down because the storage stuff isn't integrated into our access model 13:12:29 ... Compare this to the way caches work 13:12:37 ... where we _do_ have names 13:13:07 ... The web storage model has no names in that sense, and no RESTfulness 13:13:29 ... So the existing access control mechanisms may well not generalise 13:13:37 s/generalise/generalize/ 13:14:00 DKA: Always assumed this was just an optimization 13:14:21 q+ to talk about domain filtering 13:14:44 JR: These things always start small and market forces drive towards more functionality 13:15:02 ack next 13:15:14 Zakim has joined #tagmem 13:15:22 q? 13:17:54 HST: I had the experience of using earlier versions of some of this 13:18:23 ... and it was all same-origin protected -- every access had a URI-prefix which was SO checked and which constrained subsequent access 13:19:03 Possible recommenders of trust in scrupts: 1) The uiser 2) The writer of anoethr script (which created some data) 3) a third party registry like the addons.mozilla.org or iTunes AppStore 13:19:44 HST: Looking briefly at the WD-webstorage-20091222, that appears to be still true 13:21:44 q? 13:22:20 HST: THe session store vs. local store difference matters 13:22:37 ... Not clear exactly what patterns of access are allowed . . . 13:23:16 YL: This is all similar to what happens wrt information in local cache -- the browsers know where data comes from, even if it comes from cache 13:23:34 Yves discusses provenance tracking at the javascript lnguage level 13:24:23 ... So you could require annotation of data with its origin 13:25:03 q+ 13:25:16 s/local/local HTTP/ 13:25:47 JR: But this will still be vulnerable to CSRF 13:26:07 ack next 13:26:36 In 4 minutes, we will be 30 mins behind schedule .. expect a chair's interrupt. 13:26:55 TBL: A lot of semweb are going in the direction of annotation of all triples with provenence info -- triples are becoming quads 13:26:55 q? 13:27:29 TBL: And feeding into reason maintenance systems so conclusions can be quickly withdrawn if premises are compromised 13:28:37 AM: Possible action: comment to web storage guys: basically all of this is origin-based, but section 6.1 has a 'may' -- is this a door being held open for CORS? 13:28:57 ACTION to Ashok to comment to web storage guys: basically all of this is origin-based, but section 6.1 has a 'may' -- is this a door being held open for CORS? 13:28:57 Sorry, couldn't find user - to 13:29:03 q+ to sk JAR what easier way of doing this was 13:29:13 ACTION Ashok to comment to web storage guys: basically all of this is origin-based, but section 6.1 has a 'may' -- is this a door being held open for CORS? 13:29:13 Created ACTION-438 - Comment to web storage guys: basically all of this is origin-based, but section 6.1 has a 'may' -- is this a door being held open for CORS? [on Ashok Malhotra - due 2010-06-15]. 13:30:10 q+ to ask JAR what easier way of doing this was 13:30:13 NM: Concerned we need a plan of how to feed this into our overall WebApps story 13:30:41 AM: Work towards some bullet points? 13:31:00 TBL: Propose "Storage structure and access control should be considered separately" 13:31:02 q? 13:31:42 ack timbl 13:31:42 timbl, you wanted to sk JAR what easier way of doing this was and to ask JAR what easier way of doing this was 13:31:56 TBL: JR, how do we do this? 13:32:30 JR: How do we avoid confused deputy attacked? Where a deputy gets too much power, and does more than it was intended to be allowed to do 13:32:48 The chair infers that the group would like to continue technical discussion. 13:33:04 ... The way to do this is to pull the authorization as far forward as possible, by recording who/what/when is authorized 13:33:25 ... instead of saying there was a point at which they were authorized to do anything 13:33:33 s/anything/everything/ 13:34:03 TBL: You have to have a way of specifying what is allowed -- is that code? 13:34:07 JR: Could be 13:34:32 TBL: Two ways -- characteristic function, or name, for what they are going to do, in order to authorize up front 13:35:07 JR: You have a description of what they want to do, it's to call some function with some args 13:35:43 ... The pblm with CORS is that it just controls access to particular API, as it were 13:36:19 ... Whereas e.g. with Kerberos the authorization act includes what it is you can _do_ with the authorization 13:36:52 ... Whereas with a login-based mechanism, you get authorization to "be" a particular user, and all kinds of things come from that 13:37:39 [scribe missed a bit] 13:38:56 JR: In Javascript this is easy, the auth. decision is an object, which encapsulated the capability to do the action . . . 13:39:10 jar: This (login is much too high granularity 13:39:56 JR: Adam Barth says this isn't yet viable, because it depends on secure ECMAScript, but there's a lot of ordinary Javascript still around 13:40:19 AM: Who are we aiming this at? 13:40:52 NM: As per WebArch, not the authors of HTTP, but the smart user population looking for guidance as to how to use it 13:41:11 ... So to describe a stable architecture which shows how the specs fit together 13:41:34 ... Which may as a by-product help the authors of the specs that are still under construction 13:41:59 Adam has done some cool work making origin-based authorization decisions work as well as they can in javascript 13:42:18 AM: I have two goals -- since the specs are _not_ finished, I'd like to ask them to explicitly provide for [controlled] cross-site access, and ??? 13:43:49 [note to scribe -- strike AM line above] 13:44:36 AM: I had started with the understanding there were two goals: session storage and persistent storage. Now I see we need to add a third: [controlled] cross-site access. 13:44:55 JR: What's needed is a narrative, not a design 13:46:06 DKA: Possible kinds of actions: We could try to intervene in the progress of the Web Storage spec. What kind of proposal could we point them towards 13:46:31 NM: Shipped already, or not? 13:46:39 AM: Not even in last call 13:46:45 NM: No, I meant the code 13:47:32 TBL: I'd be surprised if it was baked 13:47:46 HST: But Mozilla shipped with something close to this at least a year ago 13:47:59 DKA: I will try to find out 13:49:53 JR: Adam Barth is trying to write an RFC on how to use cookies securely 13:50:19 NM: We could say something from the TAG on client-side storage which didn't get into the deep security pblms 13:52:00 johnk has joined #tagmem 13:52:55 hi, I'm on the call now 13:52:57 Ashok will prepare input to discuss on the telcon on the 17th (if we have one) 13:53:11 http://www.eros-os.org/pipermail/cap-talk/2010-February/013753.html 13:53:36 We will do security after a 15 minute break, back at 10 past the hour 13:53:43 ah, OK. will return then 13:53:49 We will dial zakim then 13:53:54 -John_Kemp 13:53:56 TAG_f2f()3:00AM has ended 13:53:56 Attendees were John_Kemp 13:53:58 ***BREAK*** 13:57:03 TAG_f2f()3:00AM has now started 13:57:12 + +44.163.567.aaaa 14:04:02 johnk_ has joined #tagmem 14:08:25 +John_Kemp 14:08:32 johnk_ has joined #tagmem 14:16:37 johnk_ has joined #tagmem 14:18:07 zakim, who is here? 14:18:07 On the phone I see Vodafone, John_Kemp 14:18:09 Vodafone has jar, timbl, ashok, dka, yves, ht, noah 14:18:10 On IRC I see johnk, Zakim, DKA, jar, ht, timbl, Ashok, RRSAgent, noah, Yves, trackbot 14:20:18 ok, well I'm listening ;) 14:20:26 Topic: Web Applications: Security 14:21:20 NM: Goal is to have a better idea of whether there's serious writing to be done 14:21:34 ... what next steps if not writing 14:21:55 AM: If you want sites to cooperate, is CORS/UMP/OAuth/What the way to do it? 14:22:11 NM: What is your opinion, if you have one --- anyone? 14:22:19 AM: I don't know 14:22:24 s/know/know yet/ 14:22:47 JR: Hard to answer, because I've been in the capability camp for so long 14:23:13 ... So if I were designing an app, I would take whatever mechanism I could find that would let me layer capabilities on top 14:23:32 NM: But the web community is going to make a call. . . 14:23:57 JR: I don't think CORS will scale 14:24:08 NM: What about UMP? 14:24:30 JR: Yes, I think it has the right properties -- from an engineering perspective 14:24:31 +1 to Jonathan 14:24:51 agree that UMP is better from architectural perspective 14:25:18 JR: I see you could need some more structure on top, to match web needs . . . there would be a certain amount of re-invention of the wheel for the next level, for instance wrt UI 14:25:44 AM: I still need to think about it, read the specs again 14:26:15 DKA: I'm more familiar with the CORS approach, I also know OAuth, which I think is sometimes the right response 14:26:25 ... It's a well-used bit of web arch. 14:26:44 ... I think the widgets digital signature stuff could also be useful 14:26:58 ... Similar to CORS, but based on signatures, not origin 14:27:23 NM: How is this an access-control mechanism 14:27:40 http://www.w3.org/TR/widgets-access/ 14:27:47 DKA: Here's the spec: 14:28:22 The doc't is specific to widgets, but it could be extended to docs as well 14:28:31 http://www.w3.org/TR/widgets-access/ is also origin-based 14:28:48 ACTION Appelquist to introduce signature-based approaches to access control 14:28:48 Created ACTION-439 - Introduce signature-based approaches to access control [on Daniel Appelquist - due 2010-06-15]. 14:29:53 YL: I don't think CORS is the ultimate solution to WebApp security -- UMP is much simpler. People understand Same Origin, CORS is hard to make sense of, where UMP is simpler 14:30:07 ... It provides what people mostly need, which is cooperation between two sites 14:30:28 ... Much better way in for devs who are not seriously engaged with security issues 14:30:58 HST: Kerberos? 14:31:23 JR: Like capability, in that you get an unguessable token, but it's still a capability just to be a particular person 14:31:56 ... But it illustrates that the outcome of login can be an object 14:31:57 OAuth is the new Kerberos, roughly-speaking 14:32:09 SAML was the new Kerberos, before OAuth 14:32:46 HST: So I get that's it's not a clean distinction. . . 14:34:03 Possibly pertinent Kerberos RFC http://www.ietf.org/rfc/rfc1510.txt 14:36:45 Wikipedia simplified description of Kerberos protocol: http://simple.wikipedia.org/wiki/Kerberos_%28protocol%29#Simplified_description_of_the_protocol 14:39:02 HST: [Kerberos question and answers; MarkLogic = fine-grained control, but still ambient authority] 14:39:13 did you guys drop from the bridge? 14:39:35 HST: Having said all that, +1 to finding, articulating and selling a capability-based story 14:40:05 NM: Not sure I have the grounding to make an informed judgement 14:40:43 ... The concerns I hear about CORS come from impressive sources, and I think I hear good things about UMP, as far as it goes 14:41:07 ... In particular, I don't see how UMP extends to cookie functionality, which seems to be what people really need 14:41:35 ... WRT capabilities, my early experience was not good, so I will need to be convinced in practice we can make it work 14:42:25 AM: JR pointed out that Javascript does not have encapsulation -- without that, how can you do capabilities 14:42:39 Not quite what I said: capability systems are very cool and can work well, but they tend to be somewhat difficult to implement and roll out. So, I want to see something that the community will accept as practical. 14:42:42 johnk_ has joined #tagmem 14:42:52 JR: By adding features to the language -- that's what SES (Secure ECMAScript) does 14:43:27 Maybe or maybe not something like WebKeys signals a direction. I just don't want to gamble on some unseen capability system working until we've seen early versions getting traction on the Web. 14:43:32 JR: UMP is capabililties at the protocol level, that's not the same as capabilities in the programming environment, we need both 14:44:14 Too many features -> too much access -> loss of encapsulation. Javascript. Remove features -> can't access stuff you shouldn't be able to get -> recovery of encapsulation. Secure Javascript. 14:45:06 JK: Based on experience and reading the specs, I think the origin-based approach we have to security today needs to be fixed, CORS is not going to do it, and UMP looks like it will 14:45:45 ... But I also note that the in-practice approach people have taken to protecting against CSRF and click-jacking amounts to something very close to capabilities in practice 14:45:58 John's framing resonates for me: a key question is whether the permission token is integrated with or separate from the identifier. The latter approach is, more or less capabilities. 14:46:41 JK: Fixing origin-based by hacking pseudo-capabilities on top of other hacks seems doomed, something cleaner from the ground up should be preferred 14:47:20 TBL: Is this a research-grade problem, or is it really ready? The extra stuff you, JR, said was needed? 14:47:55 JR: There is Waterken, which is built on top of UMP using web keys, which is a commercial product from Tyler Close 14:47:57 q+ jar to briefly note that use of UMP does not require use of unguessable secret URIs. you can put the CSRF token in a parameter i.e. elsewhere in the request e.g. in POST parameters. 14:48:13 ... Note that UMP does not imply Web Key 14:48:20 ack jar 14:48:20 jar, you wanted to briefly note that use of UMP does not require use of unguessable secret URIs. you can put the CSRF token in a parameter i.e. elsewhere in the request e.g. in 14:48:24 ... POST parameters. 14:48:25 q+ ht 14:48:31 q+ to ht to mention triangle use case 14:48:39 q+ noah to talk about tokens integrated with or not integrated with the identifier 14:49:08 JR: Using UMP for CSRF protection is isomorphic to what people are doing today, for example using hidden POST parameters 14:49:34 ... containing a nonce 14:49:40 yes exactly 14:50:09 JR: UMP extends this existing story wrt e.g. click-jacking, w/o any javascript, into general javascript usage 14:50:14 ack ht 14:50:14 ht, you wanted to ht to mention triangle use case 14:51:02 http://waterken.sourceforge.net/ 14:52:47 johnk_ has joined #tagmem 14:53:52 ht: 'The triangle property' in Alex's project 14:54:06 Think of SETI at home... hierarchical decomposition 14:54:19 suppose a URI names a part of a decomposition of a probem 14:54:29 Diagram description: Henry shows a central coordination node sending http interactions to a farm of worker nodes. 14:54:38 but the GET has to be done asynchronously, days or weeks 14:54:50 He described it as peer-to-peer, but the diagram is a one-level tree. 14:55:18 triangle problem: I will give URI for answer, as well as the question 14:55:48 so I have an S3 account... I want you to do a computation... and put the answer there (on my nickel) 14:55:58 OAUTH doesn't work here. Too much authority granted 14:56:17 timbl: OAUTH is designed to do that 14:56:21 noah: SAMBL too? 14:56:34 ht: we're just starting to understand the options here 14:56:39 s/SAMBL/SAML/ 14:56:45 s/so I have/ht: so I have/ 14:56:48 SAML = Security assertions markup language 14:57:20 ht: so we want a capability to store the result. time limited. 14:57:50 Not sure, but XACML may be pertinent too (see: http://www.oasis-open.org/committees/xacml/ ) 14:58:02 Wikipedia on XACML http://en.wikipedia.org/wiki/XACML 14:58:06 ht: But S3 doesn't have this ability today... 14:58:28 ht: Capability seems the simplest way to talk about this. 14:59:00 noah: I'd recommend you look at ACL-based approach 14:59:07 s/approach/approaches/ 14:59:28 scribenick: ht 14:59:38 s/triangle problem:/ht: triangle problem:/ 14:59:41 AM: I don't thing XACML is capability-like 15:00:00 ... I think it's about access control 15:00:10 NM: I think it's a bit more fine-grained. . . 15:00:26 s/but the GET/ht: but the GET/ 15:00:38 DKA: What's also relevant is that we have browser and server as actors 15:00:58 ... which makes me look to OAuth, rather than XACML which would set a very high bar 15:01:19 XACML is a language for representing access control policies 15:01:57 SAML is a language for making assertions about a "security principal" 15:01:59 NM: I find the Web Services approach awkward, but it is driven by use cases similar to the one just offered 15:02:07 ... such as long response times 15:02:59 q? 15:03:09 JR: We're not in an either-or situation altogether -- based on time-scale, for example, capabilities are designed for time-bounded, seconds, days or weeks, whereas ACLs are more 'permanent' 15:03:10 q? 15:03:10 q+ 15:03:18 ack timbl 15:03:44 TBL: Capabilities have completely different properties depending on whether they can be copied or faked 15:04:20 JR: If you're cooperating over a secure connection, no third party can get the capability 15:05:19 HST: But you don't necessarily trust the person you send the capability to 15:05:36 ... E.g. in the triangle example 15:06:27 TBL: You may assume everyone is reliably identified, so you can grant a capability only to me 15:06:54 JR: You only have to assign something that can be interpreted 15:07:26 s/assign/sign/ 15:07:59 HT's example is interesting because it's ok if the capability is leaked. doesn't protect anything that matters much 15:09:48 ack next 15:09:50 noah, you wanted to talk about tokens integrated with or not integrated with the identifier 15:10:09 TBL: MiM could get the capability and immediately use it 15:10:26 HST: Not if the real actor's public key was in the capability request 15:10:36 HST: [need to put the example higher up] 15:10:43 JR: Or if the connection is encrypted 15:11:28 NM: JK said something really interesting: comparing a token in a POST header with a capability expressed in a URI 15:11:53 ... but slightly different, in that the coupling between the identifier and the capability is different, not by much, but different 15:12:07 ... which reminded me of my concerns about web key 15:12:34 ... Since a link is a capability, I have to be careful to send my URIs carefully, i.e. using HTTPS 15:13:04 ... But we've also added a _post facto_ requirement for people to protect their caches, logs, .... 15:13:42 ... Maybe there's existing advice which forestalls this, but it runs against part of our story about making the Web work: share links, etc. 15:14:17 ... Makes me nervous to be sure we've spotted all the places that have to be secured to guarantee that these capabilities can't leak 15:14:25 q? 15:14:30 s/these/URI-embedded/ 15:15:01 JR: Just remember that UMP isn't committed to web key 15:15:10 NM: yes, understood 15:15:44 JR: There's always a credential -- it's got to be communicated, and it has to be protected 15:16:18 ... currently, it's distributed among cookies, ssl keys, IP addresses 15:16:30 ... It's _always_ in the response 15:16:37 ... And that's not going to change 15:17:33 NM: Yes, but my comment was that putting the secret in URIs entrains a huge history of what browsers and other tools _do_ with URIs 15:17:55 ... and that history is very different in impact from the parallel history wrt e.g. cookies 15:18:13 JR: It's a question of what Javascript you write. 15:18:52 johnk_ has joined #tagmem 15:19:13 NM: I thought there was a crucial difference between UMP and XMLHttpRequest wrt cookies -- XMLHttpRequest automatically attaches my cookies for site X to any request to site X 15:19:18 ... UMP doesn't 15:21:22 HT: If I do use URI-encoded capabilities, and do what I described in my example, with a GET over HTTPs, but my Apache server logs every URI, the file albeit restricted to root, goes to all my sysadmins. I don't want that. 15:21:45 JAR: Yes, if not used with something else like a login. 15:22:21 scribenick: ht 15:22:59 http://www.w3.org/2001/tag/tag-weekly#WebAppsSec 15:23:02 HST: So NM's point is simply that expectations about for example privacy vary wrt existing bits of Web Arch, e.g. URI vs. header 15:23:11 JR: Right. Nothing to do with UMP? 15:23:14 NM: Right. 15:23:32 NM: JK, what about ACTION-340? 15:23:39 JK: I think that's done 15:23:45 ACTION-340? 15:23:45 ACTION-340 -- John Kemp to summarize recent discussion around XHR and UMP -- due 2010-06-04 -- PENDINGREVIEW 15:23:45 http://www.w3.org/2001/tag/group/track/actions/340 15:23:50 close ACTION-340 15:23:50 ACTION-340 summarize recent discussion around XHR and UMP closed 15:32:16 ACTION-417 Due 2010-07-13 15:32:16 ACTION-417 Frame section 7, security due date now 2010-07-13 15:32:47 ACTION-435? 15:32:47 ACTION-435 -- Jonathan Rees to consult Tyler Close regarding UMP-informed web storage vulnerability analysis -- due 2010-06-15 -- OPEN 15:32:47 http://www.w3.org/2001/tag/group/track/actions/435 15:33:36 ACTION-435 has been bumped to 15 June 15:35:43 ACTION-280? 15:35:43 ACTION-280 -- John Kemp to (with John K) to enumerate some CSRF scenarios discussed in Jun in Cambridge -- due 2010-07-06 -- OPEN 15:35:43 http://www.w3.org/2001/tag/group/track/actions/280 15:35:55 We just moved ACTION-280 from Dan to John, and made date in early July. 15:36:42 ACTION-33 due 2010-07-15 15:36:42 ACTION-33 revise naming challenges story in response to Dec 2008 F2F discussion due date now 2010-07-15 15:36:49 ACTION-344? 15:36:49 ACTION-344 -- Jonathan Rees to alert TAG chair when CORS and/or UMP goes to LC -- due 2010-06-10 -- OPEN 15:36:49 http://www.w3.org/2001/tag/group/track/actions/344 15:37:11 JAR: I want text of action to record why I'm doing this. I think it's so we can do a review of their Last Call regarding security considerations. 15:42:15 -John_Kemp 15:42:50 johnk has left #tagmem 15:51:49 close ACTION-412 15:51:49 ACTION-412 Try the clarification question, blog item, or wiki approach to metadata-in-uris vs CSRF closed 16:02:35 -Vodafone 16:02:36 TAG_f2f()3:00AM has ended 16:02:38 Attendees were +44.163.567.aaaa, jar, timbl, ashok, dka, yves, ht, noah, John_Kemp 17:18:23 Zakim has left #tagmem