IRC log of tagmem on 2010-06-08

Timestamps are in UTC.

08:00:31 [RRSAgent]
RRSAgent has joined #tagmem
08:00:31 [RRSAgent]
logging to
08:00:32 [trackbot]
RRSAgent, make logs public
08:00:32 [Zakim]
Zakim has joined #tagmem
08:00:34 [trackbot]
Zakim, this will be TAG
08:00:34 [Zakim]
ok, trackbot; I see TAG_f2f()3:00AM scheduled to start 60 minutes ago
08:00:35 [trackbot]
Meeting: Technical Architecture Group Teleconference
08:00:35 [trackbot]
Date: 08 June 2010
08:01:10 [DKA]
Scribe: Dan
08:01:13 [DKA]
ScribeNick: DKA
08:01:42 [Yves]
08:09:21 [DKA]
[agenda discussion]
08:10:04 [Ashok]
Ashok has joined #tagmem
08:10:21 [DKA]
Topic: Content-type Override (sniffing)
08:10:34 [jar]
jar has joined #tagmem
08:11:09 [DKA]
Present+ Henry
08:11:13 [DKA]
08:11:13 [trackbot]
ACTION-370 -- Henry S. Thompson to hST to send a revised-as-amended version of to the HTTP bis list on behalf of the TAG -- due 2010-05-17 -- PENDINGREVIEW
08:11:13 [trackbot]
08:12:13 [DKA]
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 [DKA]
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 [DKA]
ht: I think it's the best compromise.
08:15:54 [noah]
08:16:15 [DKA]
ht: [comparing yves's version to henry's version]
08:16:22 [noah]
We are reviewing the above email, which has suggested ammendments to the TAG
08:16:29 [noah]
s proposed HTTPbis text on sniffing.
08:16:31 [Yves]
08:17:03 [DKA]
ht: this is better than the status quo.
08:17:45 [DKA]
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 [DKA]
noah: [points to "risks of sniffing" proposed text]
08:19:36 [DKA]
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 [DKA]
ht: I feel that 7.3 [Media Type Issue] in Yves's message is a reasonable compromise.
08:22:04 [DKA]
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 [DKA]
noah: I'm not so convinced.
08:22:58 [DKA]
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 [DKA]
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 [DKA]
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 [DKA]
Noah: this word - "identify" - bothers me. I don't think the content-type header identifies.
08:26:03 [DKA]
ht: Suggest another word.
08:26:35 [DKA]
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 [DKA]
[some wordsmithing]
08:27:55 [DKA]
noah: ...correctly convey the intended [type] of the content...
08:28:20 [DKA]
Yves: it's worth clarifying the text.
08:28:37 [DKA]
ht: "does not reflect the intended interpretation of the content"
08:29:00 [noah]
Sounds good to me.
08:29:23 [DKA]
Noah: ok to seek consensus on this?
08:29:59 [DKA]
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 [DKA]
tim: I think the new text is fine.
08:31:46 [DKA]
jar: I wonder what it would be in IETF-jargon?
08:32:26 [DKA]
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]
Ashok has joined #tagmem
08:33:12 [DKA]
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 [DKA]
ht: quotes chapter and verse
08:33:57 [DKA]
noah: anyone unhappy?
08:34:06 [DKA]
noah: i think the right concerns have been laid out...
08:34:45 [DKA]
noah: I propose to put down 370... and look at other actions related to sniffing.
08:35:35 [DKA]
Noah: Larry has written an interesting message in relation to ACTION-425. We could go over it...
08:35:45 [DKA]
08:35:45 [trackbot]
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 [trackbot]
08:36:01 [DKA]
Noah: Shall we do ACTION-387 first?
08:36:26 [DKA]
ht: should we now bring that message up and review it?
08:36:40 [DKA]
08:36:40 [trackbot]
ACTION-387 -- Henry S. Thompson to review JK/NM's stuff on sniffing, authoritative metadata, self-describing web, incl. -- due 2010-06-07 -- PENDINGREVIEW
08:36:40 [trackbot]
08:37:00 [timbl]
timbl has joined #tagmem
08:37:28 [DKA]
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 [DKA]
08:37:38 [trackbot]
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 [trackbot]
08:37:53 [DKA]
08:37:55 [noah]
08:38:18 [noah]
Mail 0063 is a draft from Larry that we will now review.
08:39:04 [noah]
Yves says is the same text, with better format. We'll review that.
08:39:29 [ht]
ht has joined #tagmem
08:39:31 [DKA]
Noah: Brins up Larry's blog entry.
08:41:37 [DKA]
[group reviewing]
08:41:52 [noah]
08:44:45 [DKA]
tim: I really like this article.
08:45:29 [DKA]
... 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 [DKA]
... 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 [DKA]
... we've been telling people to use a URI name but it also depends on the mime type...
08:47:17 [DKA]
... 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 [DKA]
... 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 [DKA]
jar: You're right that it doesn't say that but the RDF/XML media type registration does say that.
08:49:29 [Yves]
08:50:21 [noah]
q+ to discuss 3023
08:51:10 [DKA]
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 [DKA]
tim: There are two designs and an "un-design"
08:52:14 [noah]
08:52:54 [DKA]
... 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 [DKA]
... design 3: "we know what we mean..."
08:54:52 [DKA]
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 [noah]
08:55:24 [DKA]
noah: I see [a potential problem] in the RDF / XML space.
08:55:37 [DKA]
... this is the spec that defines the "+" convention.
08:57:02 [ht]
08:57:17 [DKA]
... 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 [DKA]
ht: You're right - this is the definitive statement - but nobody pays attention to it.
08:58:02 [DKA]
tim: What's the solution?
08:58:05 [Yves]
08:58:17 [DKA]
ht: It's time to look at this again - it's opportune.
08:59:10 [DKA]
Yves: Pointed to fragment identifier section of RDF media type registation...
08:59:18 [DKA]
Noah: This doesn't resolve anything.
08:59:59 [DKA]
ht: the particular question on 3023 BIS is - it does not give any advice.
09:02:30 [DKA]
noah: the problem is that the + stuff is tricky.
09:03:37 [DKA]
... there is a published rfc-3023 - to which is a proposed revision...
09:05:01 [DKA]
noah: I would remove "fragment identification" as something that can be [automatically] identified...
09:05:15 [jar]
09:06:20 [DKA]
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 [DKA]
ht: you're right - the clear implication of as it stands is that if you use the +XML media type you are licensing all the interpretations on 3023bis.
09:09:18 [DKA]
... 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 [DKA]
noah: I think the spirit is very similar.
09:09:38 [DKA]
ht: but the letter is different.
09:11:08 [DKA]
... quotes: if [xpointerfranework] and [xpointerelement] are inappropriate for some XM-based media types it should not follow the naming convention +XML
09:12:23 [DKA]
tim: two options: A) remove stuff about frag id, leave rdf+xml; B) leave frag ID, remove +xml from rdf
09:12:54 [DKA]
ht: I had in mind a 3rd way: unlike the other properties, fragment identifiers can be overridden in a + spec.
09:13:06 [DKA]
ht: that would still require changing the spec.
09:13:42 [DKA]
noah: [seeking clarification on (A)]: "remove stuff about frag id as part of generic processing"
09:13:49 [DKA]
tim: Yes.
09:14:48 [DKA]
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 [DKA]
tim: [names Henry's proposal: "grandfather"]
09:17:20 [DKA]
ht: fragment identifier interpretation happens...
09:19:16 [DKA]
tim:In your FOAF file you can use an XSLT -
09:19:28 [DKA]
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 [DKA]
noah: what are our options?
09:21:27 [DKA]
jar: 4th option: figure out by context what is identified.
09:21:47 [DKA]
yves: pragmatically that's what implementations will do.
09:22:23 [DKA]
yves: [gives an example involving video]
09:22:29 [DKA]
tim: That should be in the spec.
09:23:59 [DKA]
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 [DKA]
... 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 [DKA]
tim: The TAG should change the architecture document to add that text.
09:25:04 [DKA]
noah: I'm OK with that.
09:27:19 [DKA]
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 [DKA]
ht: whatever happened to vertical bar? | server-side fragments?
09:29:12 [DKA]
... 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 [DKA]
jar: [sort of]
09:30:04 [DKA]
... 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 [DKA]
jar: this is the HTTP semantics problem.
09:31:44 [DKA]
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 [DKA]
... whereas an RDF processor goes the other direction.
09:33:29 [DKA]
noah: I'm more worried about people who run generic tools on documents that are lying around ...
09:33:53 [DKA]
tim: ximclude - can I say "xinclude something#foo" ?
09:33:55 [DKA]
ht: yes:
09:34:00 [DKA]
tim: Then this does break.
09:34:45 [DKA]
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 [DKA]
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 [DKA]
[back from break]
10:10:34 [DKA]
Topic: http semantics
10:11:51 [DKA]
jar: [presents slides]
10:12:20 [DKA]
jar: problems that I see in these discussions on "what do URIs mean / name" etc...
10:12:33 [DKA]
... these are the sorts of questions that I'm trying to model or address.
10:12:40 [DKA]
... didn't get as far as I wanted to get.
10:13:19 [DKA]
... not trying to "define meaning."
10:13:33 [DKA]
... trying to dispel fear and uncertainty around providing metadata for resources on the Web.
10:16:46 [DKA]
... 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 [DKA]
... [presents "http semantics landscapes: exchanges" diagram from slides]
10:19:39 [DKA]
... this is not a class diagram.
10:20:05 [DKA]
... it's a template for diagrams involving instances.
10:22:43 [DKA]
... the point is: you can do an ontological account - a scientific account - looking at what really happens in an HTTP exchange.
10:23:26 [DKA]
... [introducing "exchange variability" diagram] if you want to look at patterns -
10:23:29 [noah]
BTW: Agenda has been updated at
10:24:30 [DKA]
... 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 [DKA]
... [e.g. 2 are in PDF and 1 is in HTML]
10:25:20 [DKA]
... there are some properties of the representation which are common and some which differ.
10:25:34 [DKA]
... talking about "properties of exchanges."
10:26:26 [DKA]
... subclasses of exchanges: defined by restriction or by inclusion.
10:27:38 [DKA]
... in this modelling, we have some basic axioms already emerging - e.g. "every exchange has a send request."
10:28:12 [DKA]
... which can be expressed in OWL...
10:29:38 [DKA]
... 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 [noah]
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 [noah]
Link is:
10:31:54 [DKA]
... you could talk about the class of exchanges with this URI - class of exchanges with this URI possesses this invariant.
10:34:11 [DKA]
... so classes of exchanges talking about invariance on a representation, invariance on the exchange, ...
10:34:38 [DKA]
... you can also talk about the relation of these exchanges to the world.
10:35:36 [DKA]
... 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 [DKA]
... [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 [DKA]
Ashok: It would make this more useful [to add rules]...
10:38:25 [DKA]
jar: you need a good foundation first...
10:38:42 [DKA]
... [back to slides - "subclasses of Exchange" slide 2]
10:39:37 [DKA]
... some subclasses: empirical / promise / API / constraint
10:40:44 [DKA]
tim: here we're talking about network protocols and meaning.
10:41:32 [DKA]
... 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 [DKA]
... we need to distinguish between modelling how things are supposed to work and what happens when they don't work.
10:42:16 [DKA]
jar: this gives a start...
10:42:45 [DKA]
10:43:36 [DKA]
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 [DKA]
[brief toilet-role discussion]
10:44:34 [DKA]
10:44:58 [DKA]
jar: [back, thankfully, to the slides]
10:45:33 [DKA]
... you can say : all the exchanges I've observed are members of the following class...
10:46:28 [DKA]
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 [DKA]
jar: is that a definition of interesting or a consequence of interesting?
10:46:51 [DKA]
ht: definition, I guess.
10:47:10 [DKA]
jar: [my point]
10:47:26 [DKA]
s/[my point]//
10:48:40 [DKA]
tim: [gives example of how ethernet cable gives a promise of containing ethernet packets]
10:50:34 [DKA]
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 [DKA]
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 [DKA]
jar: promises might go bad.
10:52:55 [DKA]
... the time at which it happened is a property of an exchange.
10:53:52 [DKA]
... last subclass of exchange: induced.
10:54:44 [DKA]
... if you're a librarian or a scientist, what you're interested in talking about is content, data, measurements, ...
10:55:09 [DKA]
... e.g. a telescope is an example of an "induced" resource.
10:55:58 [DKA]
... [more on induced exchange classes]
10:58:33 [DKA]
... maybe for each kind of thing that you want to allow 200 responses for you state [what happens].
10:58:44 [DKA]
tim: this is why it's important to model the semantic web stuff.
11:00:31 [DKA]
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 [DKA]
ht: what kinds of differences between representations would be allowed for representations of the same resource?
11:02:52 [DKA]
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 [DKA]
yves: the news site is a good example. If you do a get on then you get back something with a timestamp...
11:05:40 [DKA]
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]
DKA: Can you define art?
11:07:01 [ht]
Scots law requires that responses to offers of oral contracts must be "timeous" for the contract to be binding
11:08:54 [DKA]
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 [DKA]
... [digression] a promise is a speech act and it has parts.
11:11:32 [DKA]
.... 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 [DKA]
... their fear is that they won't be understood.
11:12:50 [DKA]
... 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 [DKA]
... 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 [DKA]
tim: so "persistence commons"
11:14:53 [DKA]
... w3c has a draft persistence policy...
11:15:46 [DKA]
yves: they don't want to use the URI because it might change...
11:16:51 [DKA]
ht: there isn't a transparent way to write a URI which is recognisably a reference to a published journal article.
11:17:18 [DKA]
jar: you can say "info:doi/" - [with some caveats]
11:18:14 [DKA]
ht: [+1 to the idea of a validator]
11:18:19 [DKA]
noah: wrap for lunch?
11:28:09 [jar]
jar has joined #tagmem
11:35:40 [Zakim]
Zakim has left #tagmem
12:15:58 [jar]
12:31:05 [DKA]
DKA has joined #tagmem
12:37:05 [ht]
scribenick: ht
12:37:12 [ht]
scribe: Henry S. Thompson
12:37:19 [ht]
RRSAgent, location?
12:37:19 [RRSAgent]
I'm logging. Sorry, nothing found for 'location'
12:37:49 [ht]
Topic: Client-side storage
12:37:51 [ht]
12:38:05 [ht]
[AM speaks to the doc't, not scribed]
12:40:29 [noah]
NM: Is this an API spec?
12:40:41 [noah]
12:40:45 [noah]
AM: Yes
12:41:44 [ht]
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 [ht]
AM: Yes
12:42:44 [ht]
AM: Name-value pairs
12:42:57 [ht]
JR: 1970s-era file system
12:43:19 [ht]
AM: Maybe name-value pairs plus indices
12:43:46 [ht]
NM: What is index good for that names can't do
12:43:59 [ht]
AM: More like a database
12:45:45 [ht]
Google Gears was an example
12:46:19 [ht]
s/an example/there/
12:46:53 [ht]
... with SQL-like access
12:47:04 [ht]
... but not typed
12:47:55 [ht]
... WebSQL was based on this product
12:48:34 [DKA]
Web SQL:
12:48:35 [ht]
... Hasn't progressed because there is only one (proprietary) implementation
12:49:02 [ht]
... But it looks like the indexed API is going ahead
12:49:27 [ht]
... More efficient than simple name-value
12:49:38 [DKA]
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 [DKA]
... contact the editor so that he can write a specification for the dialect, thus allowing this specification to move forward."
12:52:35 [ht]
JR: You don't need CORS . . .
12:52:39 [ht]
[scribe lost]
12:53:11 [ht]
NM: App has javascript from A, tries to get stockquote from B, not possible w/o CORS
12:53:45 [ht]
... Same thing applies once we have local storage -- JS from A wants stored information originating from B
12:53:59 [DKA]
DKA has joined #tagmem
12:55:06 [ht]
TBL: Suppose we had a consistent access-control ontology
12:55:20 [ht]
... with people, and sites, and origins
12:55:42 [ht]
... and reconstruct something similar to CORS, but more general
12:55:46 [DKA] seems problematic to me - full of MAY clauses...
13:01:52 [timbl]
13:02:27 [timbl]
"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 [ht]
AM: Agreed
13:03:12 [ht]
NM: How do we follow up on this?
13:04:38 [ht]
AM: It's possible that the 'may' is opening the door for something like CORS
13:05:41 [timbl]
"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 [ht]
DKA: [Eudora example]
13:06:29 [ht]
TBL: You have a local IMAP cache
13:06:43 [ht]
... some clients expose the cache in IMAP format
13:07:25 [ht]
NM: what about a better GMail searcher, which would need special permissions to get at the GMail cache
13:08:05 [ht]
TBL: Facebook is using web storage, and LinkedIn offers better functionality if you allow it in
13:08:13 [ht]
DKA: I want to build that using OAuth
13:08:23 [ht]
NM: But it won't work offline
13:08:49 [ht]
DKA: Yes it will, it will keep working on my behalf [between the two, w/o my participation]
13:09:09 [ht]
TBL: That's going all the way down the road to trusting big services
13:09:27 [ht]
... I'd like to be able to run my IMAP client offline
13:10:03 [ht]
DKA: But now a polluted website can inject a script which can harvest my email
13:10:28 [ht]
TBL: There's no such thing as a little bit trusting
13:11:53 [ht]
NM: Distribution is a complex issue
13:12:22 [ht]
... This whole thing also breaks down because the storage stuff isn't integrated into our access model
13:12:29 [ht]
... Compare this to the way caches work
13:12:37 [ht]
... where we _do_ have names
13:13:07 [ht]
... The web storage model has no names in that sense, and no RESTfulness
13:13:29 [ht]
... So the existing access control mechanisms may well not generalise
13:13:37 [ht]
13:14:00 [ht]
DKA: Always assumed this was just an optimization
13:14:21 [ht]
q+ to talk about domain filtering
13:14:44 [ht]
JR: These things always start small and market forces drive towards more functionality
13:15:02 [noah]
ack next
13:15:14 [Zakim]
Zakim has joined #tagmem
13:15:22 [timbl]
13:17:54 [ht]
HST: I had the experience of using earlier versions of some of this
13:18:23 [ht]
... 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 [timbl]
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 or iTunes AppStore
13:19:44 [ht]
HST: Looking briefly at the WD-webstorage-20091222, that appears to be still true
13:21:44 [noah]
13:22:20 [ht]
HST: THe session store vs. local store difference matters
13:22:37 [ht]
... Not clear exactly what patterns of access are allowed . . .
13:23:16 [ht]
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 [timbl]
Yves discusses provenance tracking at the javascript lnguage level
13:24:23 [ht]
... So you could require annotation of data with its origin
13:25:03 [timbl]
13:25:16 [ht]
s/local/local HTTP/
13:25:47 [ht]
JR: But this will still be vulnerable to CSRF
13:26:07 [ht]
ack next
13:26:36 [noah]
In 4 minutes, we will be 30 mins behind schedule .. expect a chair's interrupt.
13:26:55 [ht]
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 [noah]
13:27:29 [ht]
TBL: And feeding into reason maintenance systems so conclusions can be quickly withdrawn if premises are compromised
13:28:37 [ht]
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 [ht]
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 [trackbot]
Sorry, couldn't find user - to
13:29:03 [timbl]
q+ to sk JAR what easier way of doing this was
13:29:13 [ht]
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 [trackbot]
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 [timbl]
q+ to ask JAR what easier way of doing this was
13:30:13 [ht]
NM: Concerned we need a plan of how to feed this into our overall WebApps story
13:30:41 [ht]
AM: Work towards some bullet points?
13:31:00 [ht]
TBL: Propose "Storage structure and access control should be considered separately"
13:31:02 [noah]
13:31:42 [ht]
ack timbl
13:31:42 [Zakim]
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 [ht]
TBL: JR, how do we do this?
13:32:30 [ht]
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 [noah]
The chair infers that the group would like to continue technical discussion.
13:33:04 [ht]
... 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 [ht]
... instead of saying there was a point at which they were authorized to do anything
13:33:33 [ht]
13:34:03 [ht]
TBL: You have to have a way of specifying what is allowed -- is that code?
13:34:07 [ht]
JR: Could be
13:34:32 [ht]
TBL: Two ways -- characteristic function, or name, for what they are going to do, in order to authorize up front
13:35:07 [ht]
JR: You have a description of what they want to do, it's to call some function with some args
13:35:43 [ht]
... The pblm with CORS is that it just controls access to particular API, as it were
13:36:19 [ht]
... Whereas e.g. with Kerberos the authorization act includes what it is you can _do_ with the authorization
13:36:52 [ht]
... 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 [ht]
[scribe missed a bit]
13:38:56 [ht]
JR: In Javascript this is easy, the auth. decision is an object, which encapsulated the capability to do the action . . .
13:39:10 [timbl]
jar: This (login is much too high granularity
13:39:56 [ht]
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 [ht]
AM: Who are we aiming this at?
13:40:52 [ht]
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 [ht]
... So to describe a stable architecture which shows how the specs fit together
13:41:34 [ht]
... Which may as a by-product help the authors of the specs that are still under construction
13:41:59 [jar]
Adam has done some cool work making origin-based authorization decisions work as well as they can in javascript
13:42:18 [ht]
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 [ht]
[note to scribe -- strike AM line above]
13:44:36 [ht]
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 [ht]
JR: What's needed is a narrative, not a design
13:46:06 [ht]
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 [ht]
NM: Shipped already, or not?
13:46:39 [ht]
AM: Not even in last call
13:46:45 [ht]
NM: No, I meant the code
13:47:32 [ht]
TBL: I'd be surprised if it was baked
13:47:46 [ht]
HST: But Mozilla shipped with something close to this at least a year ago
13:47:59 [ht]
DKA: I will try to find out
13:49:53 [ht]
JR: Adam Barth is trying to write an RFC on how to use cookies securely
13:50:19 [ht]
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]
johnk has joined #tagmem
13:52:55 [johnk]
hi, I'm on the call now
13:52:57 [noah]
Ashok will prepare input to discuss on the telcon on the 17th (if we have one)
13:53:11 [jar]
13:53:36 [noah]
We will do security after a 15 minute break, back at 10 past the hour
13:53:43 [johnk]
ah, OK. will return then
13:53:49 [noah]
We will dial zakim then
13:53:54 [Zakim]
13:53:56 [Zakim]
TAG_f2f()3:00AM has ended
13:53:56 [Zakim]
Attendees were John_Kemp
13:53:58 [noah]
13:57:03 [Zakim]
TAG_f2f()3:00AM has now started
13:57:12 [Zakim]
+ +44.163.567.aaaa
14:04:02 [johnk_]
johnk_ has joined #tagmem
14:08:25 [Zakim]
14:08:32 [johnk_]
johnk_ has joined #tagmem
14:16:37 [johnk_]
johnk_ has joined #tagmem
14:18:07 [noah]
zakim, who is here?
14:18:07 [Zakim]
On the phone I see Vodafone, John_Kemp
14:18:09 [Zakim]
Vodafone has jar, timbl, ashok, dka, yves, ht, noah
14:18:10 [Zakim]
On IRC I see johnk, Zakim, DKA, jar, ht, timbl, Ashok, RRSAgent, noah, Yves, trackbot
14:20:18 [johnk]
ok, well I'm listening ;)
14:20:26 [ht]
Topic: Web Applications: Security
14:21:20 [ht]
NM: Goal is to have a better idea of whether there's serious writing to be done
14:21:34 [ht]
... what next steps if not writing
14:21:55 [ht]
AM: If you want sites to cooperate, is CORS/UMP/OAuth/What the way to do it?
14:22:11 [ht]
NM: What is your opinion, if you have one --- anyone?
14:22:19 [ht]
AM: I don't know
14:22:24 [ht]
s/know/know yet/
14:22:47 [ht]
JR: Hard to answer, because I've been in the capability camp for so long
14:23:13 [ht]
... 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 [ht]
NM: But the web community is going to make a call. . .
14:23:57 [ht]
JR: I don't think CORS will scale
14:24:08 [ht]
NM: What about UMP?
14:24:30 [ht]
JR: Yes, I think it has the right properties -- from an engineering perspective
14:24:31 [johnk]
+1 to Jonathan
14:24:51 [johnk]
agree that UMP is better from architectural perspective
14:25:18 [ht]
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 [ht]
AM: I still need to think about it, read the specs again
14:26:15 [ht]
DKA: I'm more familiar with the CORS approach, I also know OAuth, which I think is sometimes the right response
14:26:25 [ht]
... It's a well-used bit of web arch.
14:26:44 [ht]
... I think the widgets digital signature stuff could also be useful
14:26:58 [ht]
... Similar to CORS, but based on signatures, not origin
14:27:23 [ht]
NM: How is this an access-control mechanism
14:27:40 [DKA]
14:27:47 [ht]
DKA: Here's the spec:
14:28:22 [ht]
The doc't is specific to widgets, but it could be extended to docs as well
14:28:31 [johnk] is also origin-based
14:28:48 [ht]
ACTION Appelquist to introduce signature-based approaches to access control
14:28:48 [trackbot]
Created ACTION-439 - Introduce signature-based approaches to access control [on Daniel Appelquist - due 2010-06-15].
14:29:53 [ht]
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 [ht]
... It provides what people mostly need, which is cooperation between two sites
14:30:28 [ht]
... Much better way in for devs who are not seriously engaged with security issues
14:30:58 [ht]
HST: Kerberos?
14:31:23 [ht]
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 [ht]
... But it illustrates that the outcome of login can be an object
14:31:57 [johnk]
OAuth is the new Kerberos, roughly-speaking
14:32:09 [johnk]
SAML was the new Kerberos, before OAuth
14:32:46 [ht]
HST: So I get that's it's not a clean distinction. . .
14:34:03 [noah]
Possibly pertinent Kerberos RFC
14:36:45 [noah]
Wikipedia simplified description of Kerberos protocol:
14:39:02 [ht]
HST: [Kerberos question and answers; MarkLogic = fine-grained control, but still ambient authority]
14:39:13 [johnk]
did you guys drop from the bridge?
14:39:35 [ht]
HST: Having said all that, +1 to finding, articulating and selling a capability-based story
14:40:05 [ht]
NM: Not sure I have the grounding to make an informed judgement
14:40:43 [ht]
... 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 [ht]
... In particular, I don't see how UMP extends to cookie functionality, which seems to be what people really need
14:41:35 [ht]
... 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 [ht]
AM: JR pointed out that Javascript does not have encapsulation -- without that, how can you do capabilities
14:42:39 [noah]
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_]
johnk_ has joined #tagmem
14:42:52 [ht]
JR: By adding features to the language -- that's what SES (Secure ECMAScript) does
14:43:27 [noah]
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 [ht]
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 [jar]
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 [ht]
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 [ht]
... 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 [noah]
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 [ht]
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 [ht]
TBL: Is this a research-grade problem, or is it really ready? The extra stuff you, JR, said was needed?
14:47:55 [ht]
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 [jar]
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 [ht]
... Note that UMP does not imply Web Key
14:48:20 [ht]
ack jar
14:48:20 [Zakim]
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 [Zakim]
... POST parameters.
14:48:25 [noah]
q+ ht
14:48:31 [ht]
q+ to ht to mention triangle use case
14:48:39 [noah]
q+ noah to talk about tokens integrated with or not integrated with the identifier
14:49:08 [ht]
JR: Using UMP for CSRF protection is isomorphic to what people are doing today, for example using hidden POST parameters
14:49:34 [ht]
... containing a nonce
14:49:40 [johnk]
yes exactly
14:50:09 [ht]
JR: UMP extends this existing story wrt e.g. click-jacking, w/o any javascript, into general javascript usage
14:50:14 [ht]
ack ht
14:50:14 [Zakim]
ht, you wanted to ht to mention triangle use case
14:51:02 [jar]
14:52:47 [johnk_]
johnk_ has joined #tagmem
14:53:52 [jar]
ht: 'The triangle property' in Alex's project
14:54:06 [jar]
Think of SETI at home... hierarchical decomposition
14:54:19 [jar]
suppose a URI names a part of a decomposition of a probem
14:54:29 [noah]
Diagram description: Henry shows a central coordination node sending http interactions to a farm of worker nodes.
14:54:38 [jar]
but the GET has to be done asynchronously, days or weeks
14:54:50 [noah]
He described it as peer-to-peer, but the diagram is a one-level tree.
14:55:18 [jar]
triangle problem: I will give URI for answer, as well as the question
14:55:48 [jar]
so I have an S3 account... I want you to do a computation... and put the answer there (on my nickel)
14:55:58 [jar]
OAUTH doesn't work here. Too much authority granted
14:56:17 [jar]
timbl: OAUTH is designed to do that
14:56:21 [jar]
noah: SAMBL too?
14:56:34 [jar]
ht: we're just starting to understand the options here
14:56:39 [noah]
14:56:45 [jar]
s/so I have/ht: so I have/
14:56:48 [noah]
SAML = Security assertions markup language
14:57:20 [jar]
ht: so we want a capability to store the result. time limited.
14:57:50 [noah]
Not sure, but XACML may be pertinent too (see: )
14:58:02 [noah]
Wikipedia on XACML
14:58:06 [jar]
ht: But S3 doesn't have this ability today...
14:58:28 [jar]
ht: Capability seems the simplest way to talk about this.
14:59:00 [jar]
noah: I'd recommend you look at ACL-based approach
14:59:07 [jar]
14:59:28 [ht]
scribenick: ht
14:59:38 [jar]
s/triangle problem:/ht: triangle problem:/
14:59:41 [ht]
AM: I don't thing XACML is capability-like
15:00:00 [ht]
... I think it's about access control
15:00:10 [ht]
NM: I think it's a bit more fine-grained. . .
15:00:26 [jar]
s/but the GET/ht: but the GET/
15:00:38 [ht]
DKA: What's also relevant is that we have browser and server as actors
15:00:58 [ht]
... which makes me look to OAuth, rather than XACML which would set a very high bar
15:01:19 [johnk]
XACML is a language for representing access control policies
15:01:57 [johnk]
SAML is a language for making assertions about a "security principal"
15:01:59 [ht]
NM: I find the Web Services approach awkward, but it is driven by use cases similar to the one just offered
15:02:07 [ht]
... such as long response times
15:02:59 [noah]
15:03:09 [ht]
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 [jar]
15:03:10 [timbl]
15:03:18 [noah]
ack timbl
15:03:44 [ht]
TBL: Capabilities have completely different properties depending on whether they can be copied or faked
15:04:20 [ht]
JR: If you're cooperating over a secure connection, no third party can get the capability
15:05:19 [ht]
HST: But you don't necessarily trust the person you send the capability to
15:05:36 [ht]
... E.g. in the triangle example
15:06:27 [ht]
TBL: You may assume everyone is reliably identified, so you can grant a capability only to me
15:06:54 [ht]
JR: You only have to assign something that can be interpreted
15:07:26 [jar]
15:07:59 [jar]
HT's example is interesting because it's ok if the capability is leaked. doesn't protect anything that matters much
15:09:48 [noah]
ack next
15:09:50 [Zakim]
noah, you wanted to talk about tokens integrated with or not integrated with the identifier
15:10:09 [ht]
TBL: MiM could get the capability and immediately use it
15:10:26 [ht]
HST: Not if the real actor's public key was in the capability request
15:10:36 [ht]
HST: [need to put the example higher up]
15:10:43 [ht]
JR: Or if the connection is encrypted
15:11:28 [ht]
NM: JK said something really interesting: comparing a token in a POST header with a capability expressed in a URI
15:11:53 [ht]
... but slightly different, in that the coupling between the identifier and the capability is different, not by much, but different
15:12:07 [ht]
... which reminded me of my concerns about web key
15:12:34 [ht]
... Since a link is a capability, I have to be careful to send my URIs carefully, i.e. using HTTPS
15:13:04 [ht]
... But we've also added a _post facto_ requirement for people to protect their caches, logs, ....
15:13:42 [ht]
... 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 [ht]
... 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 [jar]
15:14:30 [ht]
15:15:01 [ht]
JR: Just remember that UMP isn't committed to web key
15:15:10 [ht]
NM: yes, understood
15:15:44 [ht]
JR: There's always a credential -- it's got to be communicated, and it has to be protected
15:16:18 [ht]
... currently, it's distributed among cookies, ssl keys, IP addresses
15:16:30 [ht]
... It's _always_ in the response
15:16:37 [ht]
... And that's not going to change
15:17:33 [ht]
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 [ht]
... and that history is very different in impact from the parallel history wrt e.g. cookies
15:18:13 [ht]
JR: It's a question of what Javascript you write.
15:18:52 [johnk_]
johnk_ has joined #tagmem
15:19:13 [ht]
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 [ht]
... UMP doesn't
15:21:22 [noah]
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 [noah]
JAR: Yes, if not used with something else like a login.
15:22:21 [ht]
scribenick: ht
15:22:59 [noah]
15:23:02 [ht]
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 [ht]
JR: Right. Nothing to do with UMP?
15:23:14 [ht]
NM: Right.
15:23:32 [ht]
NM: JK, what about ACTION-340?
15:23:39 [ht]
JK: I think that's done
15:23:45 [noah]
15:23:45 [trackbot]
ACTION-340 -- John Kemp to summarize recent discussion around XHR and UMP -- due 2010-06-04 -- PENDINGREVIEW
15:23:45 [trackbot]
15:23:50 [noah]
close ACTION-340
15:23:50 [trackbot]
ACTION-340 summarize recent discussion around XHR and UMP closed
15:32:16 [noah]
ACTION-417 Due 2010-07-13
15:32:16 [trackbot]
ACTION-417 Frame section 7, security due date now 2010-07-13
15:32:47 [noah]
15:32:47 [trackbot]
ACTION-435 -- Jonathan Rees to consult Tyler Close regarding UMP-informed web storage vulnerability analysis -- due 2010-06-15 -- OPEN
15:32:47 [trackbot]
15:33:36 [noah]
ACTION-435 has been bumped to 15 June
15:35:43 [noah]
15:35:43 [trackbot]
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 [trackbot]
15:35:55 [noah]
We just moved ACTION-280 from Dan to John, and made date in early July.
15:36:42 [ht]
ACTION-33 due 2010-07-15
15:36:42 [trackbot]
ACTION-33 revise naming challenges story in response to Dec 2008 F2F discussion due date now 2010-07-15
15:36:49 [noah]
15:36:49 [trackbot]
ACTION-344 -- Jonathan Rees to alert TAG chair when CORS and/or UMP goes to LC -- due 2010-06-10 -- OPEN
15:36:49 [trackbot]
15:37:11 [noah]
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 [Zakim]
15:42:50 [johnk]
johnk has left #tagmem
15:51:49 [noah]
close ACTION-412
15:51:49 [trackbot]
ACTION-412 Try the clarification question, blog item, or wiki approach to metadata-in-uris vs CSRF closed
16:02:35 [Zakim]
16:02:36 [Zakim]
TAG_f2f()3:00AM has ended
16:02:38 [Zakim]
Attendees were +44.163.567.aaaa, jar, timbl, ashok, dka, yves, ht, noah, John_Kemp
17:18:23 [Zakim]
Zakim has left #tagmem