07:29:05 RRSAgent has joined #tagmem 07:29:05 logging to http://www.w3.org/2012/04/03-tagmem-irc 07:29:07 RRSAgent, make logs public 07:29:07 Zakim has joined #tagmem 07:29:08 JAR: I know what Adam Barth us up to, SES peopl are upt o 07:29:09 Zakim, this will be TAG 07:29:09 I do not see a conference matching that name scheduled within the next hour, trackbot 07:29:10 Meeting: Technical Architecture Group Teleconference 07:29:10 Date: 03 April 2012 07:29:32 q+ to talk about 'origin' 07:29:37 s/peopl are upt o/people are up to/ 07:29:39 Noah: Robin and i exchanged email. 07:30:12 My previous expernec was atht web hasbeen less siccesssful than I had oped. 07:30:46 s/expernec was atht web hasbeen less siccesssful than I had oped/experience was that web has been less successsful than I had hoped/ 07:30:51 I got this music catalog though the post, with "ios rocks" in the music catalog -- an maazing list of ting s people are building with natuve 07:31:11 like a mixing oard with ipad dock and the software on the ipad 07:31:41 This needs a proprietary hardware connector for example. 07:32:32 ... 6 channel streaming recorder, effects pedal, ...etc 07:32:32 ' 07:32:42 so you need low-level access to things like DSPs 07:32:55 Robin; That is access to the core audio API. 07:33:24 Yves: Actually for audio you can do all the processing in JS< it is a q of latency why you need cior audio. 07:33:31 s/cior/core/ 07:33:58 aspects of native: (a) performance (b) access to APIs (c) monetization (d) trust 07:34:06 q? 07:34:49 Noah: A risk of de=facto stdization around a particular connector 07:34:51 maybe (b) and (d) are related? vendors link (b) to (c) because platform vendors take percentage 07:35:09 q? 07:35:09 (a) performance = throughput but also latency 07:35:14 q? 07:36:02 timbl: using RDF library, has to be aware of 303s etc 07:36:13 ... when running as a script rather than plugin 07:36:26 ... same RDF library; in library it's omnipotent, otherwise in script mode 07:36:29 TBL: I was coding the RDF library, which has to be aware of things like 303 redirects. Found that when you're running things as script as opposed to plugin (as plugin it's omnipotent). In script mode, get nasty erros 07:36:34 ... in script, timeout 07:36:35 s/erros/errors/ 07:36:45 TBL: Get blocked by cross-site scripting 07:37:30 TBL: There was no error code or exception. I raised it on the list. The response I got is "it's really important not to give a response, so the app can't phish to find out what's possible" 07:38:13 TBL: Two points: 1) I think it's distressing to have a system that doesn't help you debug; 2) the system has to be capable of running in a trusted mode where you're sure you'll get some kind of response, either success or error 07:38:53 JAR: Seems analagous to Noah's point about access to the hardware port 07:39:19 Noah: Yes, except the port access stuff may be harder to make portable if the ports are proprietary and different 07:39:55 air & phonegap are examples of 'native app' development tools which allow writing apps as both webapps and native 07:40:03 TBL: A lot of people have assumed there will be shades of gray between fully trusted and untrusted apps. Seeming like some people are feeling the middle ground may be too hard to work out. 07:40:23 http://phonegap.com/ 07:40:36 TBL: The architecture which is emerging has only the two extremes. 07:40:53 JAR: Do you, Tim, agree that the middle ground is unlikely to worth working toward 07:41:21 q+ to point out that there is some possibility for APIs in the grey areas as well; point out new work; different design for trusted APIs 07:41:45 TBL: Seems like a research project. I'm interested in the TAG's position on the question: should APIs always give good responses for both trusted and untrusted apps 07:41:57 jar: 07:42:19 the quesion is, is there any middle ground between teh completely trusted and untruted app. 07:42:40 orthognal question, can you deisgn APIs wich work in either situatii? 07:42:54 there are two general approcahes on the table, form 50k m view 07:43:19 One apprach is origin case, origin(module) defines power fo module, links to CORS design 07:43:35 q+ to say that SES does not buy you privilege security 07:43:35 The Adam design is you get power by beiung passed it as a parameter 07:44:01 This is a 30 year old ACL vs Capability argument, we should nto get into it now. People are polarized. 07:44:53 In tim's example, using XHR, you are saying herer is the URl and getting back a response callback, or your callback jut doesn't callback in the bad case 07:45:18 In teh origin cae, yo would the origin of the module have the right to do ac call to that URI. 07:45:26 s/teh/the/ 07:45:30 s/cae/case/ 07:45:36 s/yo/you/ 07:47:05 RB: The origin is that of the HTML page, not the Javascript. It does not track the origin of the script code. 07:47:33 Robin: The origin is the onen -- the HTML age -- which involed teh js, noyt the actual URI the js was load ed from is irrelevant 07:48:03 Robin: this stuff is not namespaced 07:48:09 q+ to talk about shared libraries 07:48:39 Robin: The js is not namespaces -- anything can put calbacks on anything, no boundarties. 07:49:02 jar: The aim is "write once, ru anywhere". 07:49:07 s/ru/run/ 07:49:55 JAR: Javascript's kind of like JavaScript 07:50:13 q- 07:50:32 NM: Well, Java has a pretty elaborate class loader model that's pertinent to how Java code is loaded and gets privilege 07:50:37 q+ to just add srever-side and command-line working 07:51:26 jar: java security was a disaster -- basde on call chain -- like th eorigin system 07:51:41 s/th e origin/the origin/ 07:51:49 jar: in the calability method , you have a param you can pass which gives you the right to do things and you passs it to the ibrary 07:52:35 jar: theer is intense pressure to make js apps wok and access things for whcih you nee privs 07:52:59 s/theer/there/ 07:54:24 [Enter Dom] 07:54:25 q? 07:54:52 dom: a lot of the topics you have been discussing ay be very relevant to what I will present 07:55:19 jar; personally, i find this the way to think about it -- it is a q if privs and to whom they are granted. 07:55:44 there are more than two priv levels -- infact theer are many levels -- it might have access to the net but not the cor audio for example. 07:56:10 q+ to add mention of UI/policy; policy-granularity issues 07:56:11 oin fact there are questipns of top wha inside the app it is granted -- not the whole app, as now. 07:56:35 q+ to mention agenst of other companies 07:56:38 q+ to mention modules 07:56:56 q? 07:57:01 ack me 07:57:01 darobin, you wanted to point out that there is some possibility for APIs in the grey areas as well; point out new work; different design for trusted APIs and to say that SES does 07:57:01 ack next 07:57:04 ... not buy you privilege security and to add mention of UI/policy; policy-granularity issues and to mention modules 07:57:04 noah, you wanted to talk about shared libraries 07:57:12 robin; many things to say 07:57:38 1) w3c has sent out annoncemnet that it is looking into new work for system level apis -- see member only https://lists.w3.org/Archives/Member/w3c-ac-members/2012JanMar/0057.html 07:57:59 q+ 07:58:07 dom: The device API meting is open and discussed this 07:59:12 robin: When you design APIS which wok inside the browser security moel, the API looks very diff from something doen with full trust access. These is investiagtoi of new work area for APIs specifically for ocp,etely trusted APIs 07:59:32 2) even if we take teh very simple binafry on/off trusr. ther si some roiom for great area. 07:59:48 the example fo fthe XHR where you want to not to give error messages 08:00:06 In firefox, you double-clik the tab and it makes it an installed apps. 08:00:08 tim: really? 08:00:57 robin; Concepet of ionstaleld apps. They don't have to have high-level apps, yo can givetehm specific iprivs -- greater local storage, system notification,s getting error mesage scould be some 08:01:18 s/Concepet of ionstaleld/Concept of installed/ 08:01:33 Most of what i wanted to talk abouyt can go into DOM's session 08:01:45 SeS are not a solution to the trust issue 08:01:50 jar: you mean security 08:02:54 robin;: They intermesh -- ses allows you to bring in 3rd party which operate inside a limited space without acecss to each other 08:02:54 q- 08:03:20 all polict based systems whcih don't pluf the xss hole are really threatened by thta hole 08:03:21 q+ 08:04:06 jar: ses doesn't tell ou a notion of what things have what authority intp running code - you have to say, (like in powerbx etc and ongioing work) how you collect the quere 08:04:45 TBL: This isn't just about trusted apps. I use the same code, server side, and on the command line, including for test harnesses. I want all that to run my AJAX code. This needs to be part of normal computing. 08:05:01 TBL: So, it's not just trusted and untrusted apps in the browser, includes things like node.js. 08:05:42 http://www.phantomjs.org/ -> PhantomJS, run a browser on the command line 08:05:48 TBL: Also... when you download these pieces, we'll need the concepts of agents running on behalf of completely different entities. 08:06:11 TBL: We will have to surface remote entities as first class. 08:06:41 https://github.com/tmpvar/jsdom -> JSDOM, emulation of a browser environment in NodeJS 08:06:55 TBL: If I install a bunch of stuff like /application/microsoft, I'm willing to give Microsoft certain rights to e.g. update code in that part of the space. I'd like to know what rights I'm giving them. 08:07:23 TBL: I think the origin represents this legal entity in an obviously broken way. Maybe our Unix(TM) systems will go toward associating origins with points in the code trees. 08:08:36 ack next 08:08:37 timbl, you wanted to just add srever-side and command-line working and to mention agenst of other companies 08:08:41 ack next 08:08:59 jar I youhave to specify the grandularity of the grant of authority -- is it tak, object, function, program, etc 08:09:14 ashok: how can i as a user give this athority to an app? 08:09:20 robin: unsolved problem. 08:09:28 .. Policy of a rathol to fall into. 08:09:36 s/hol/hole/ 08:09:46 jar: what about Powerbox? 08:09:52 robin: later 08:10:15 robin: My personal tak e is a hard to get through process you can't do by mistake. 08:10:33 dom: at the moment you can buy stuff on the web no review 08:10:40 dom has joined #tagmem 08:10:54 Noah: We are out of time. 08:11:52 Web Applications: Security and Web Applications Permissions 08:12:05 topic: Web Applications: Security and Web Applications Permissions 08:12:20 ACTION-344? 08:12:20 ACTION-344 -- Jonathan Rees to alert TAG chair when CORS and/or UMP goes to LC to trigger security review -- due 2012-03-27 -- OPEN 08:12:20 http://www.w3.org/2001/tag/group/track/actions/344 08:12:28 Note the change in order from teh piblished agenda, this broght forward from the 100:00 today 08:12:56 http://www.w3.org/2012/Talks/dhm-tag/ 08:12:57 Dom: [ presents a talk of 16 slides] 08:15:59 Larry: Isn't monetization also a driver for native apps? 08:16:18 dom: Phonegap is adderssingthat, but I dobn't thing it is the biggeste driver 08:17:07 dom: We also are looking at layment in the W3c headlights process 08:17:48 dom: [edits sldei 2 to add Monetization] 08:22:13 FYI I proposed an approach to modularisation for features, but there was no interest: http://w3c-test.org/dap/proposals/request-feature/ 08:22:17 jar: For privacyw ith camera, hwo about confinement? 08:22:32 dom: basically impossible 08:22:58 jar: confinement being limiting hte ability of the app to send any data back home 08:23:47 dom: Interestign tio explor this approach thogh 08:24:12 dom: [slide 6] 08:24:52 robin: recommend panopticlick 08:24:54 http://panopticlick.eff.org/ 08:24:54 https://panopticlick.eff.org/ 08:26:17 I see: Your browser fingerprint appears to be unique among the 2,119,594 tested so far. Currently, we estimate that your browser has a fingerprint that conveys at least 21.02 bits of identifying information. 08:26:58 [discussion of fingerprinting details] 08:28:50 Hmmm... I got exactly the same message from Panopticlick 08:32:16 http://www.mozilla.org/en-US/b2g/ -> The B2G Project 08:32:28 https://www.tizen.org/ -> Tizen Project 08:34:26 http://www.w3.org/community/coremob/ -> Core Mobile Web Platform CG 08:44:07 http://tools.ietf.org/html/draft-ietf-geopriv-dhcp-lbyr-uri-option-14 08:44:35 RSA Conference 2011 - Making Security Decisions Disappear into the User's Workflow - Alan Karp http://www.youtube.com/watch?v=POA8SLCT5EY&noredirect=1 08:45:06 http://www.w3.org/2010/api-privacy-ws/ 08:46:29 here's Karp's tech report http://www.hpl.hp.com/techreports/2009/HPL-2009-341.pdf 08:55:22 _______ 08:55:31 Robi: this is how web intents basially works. 08:55:43 You have a service page hcih defines an action, like Pick. 08:55:59 Piucking a set of contacts from the addressbook for say asending an emial 08:56:20 the service edfinition declares what it can do, pick a set of contacts. 08:56:40 Then the user agrent regises this service, modulo user input (?TBD) 08:57:03 (chrome people think it can be registerd without ui) 08:57:18 You then have a client page. 08:57:36 Suppose you have a game -- you don't give the game full access to the entire addressbook. 08:58:00 You just wan to it to be given aceess to a set of people 08:58:52 The cleint page says "Start activity... pick contacts" includes a button hich the user must press on 08:59:01 this pops up a dialog to chose which srevice 08:59:46 then it instantiates the service page on the side [in an iframe?] and you pick yoru contacts 09:00:05 and the contacts are returned to the to the original page. 09:01:38 Ashok has joined #tagmem 09:02:08 jenit: who defines whcih fields are actually called 09:02:22 s/called/transferred/ 09:09:59 robin: The service page just gives a URI iddentifying the action, and one identifying the "type" whcih is a random sementic-free paramter used just as a filter 09:17:17 q? 09:46:46 ______ [break] _____ 09:46:55 Ashok: ... 09:47:18 Dom: right now, policy cosiderations are all ateth browser level -- ability to access a website is granted indefinitely 09:47:32 Ashok: You asked about geolocation -- that uses policy? 09:47:49 dom: In a browser-dependent way - all depends on whethre user as granted it many times, etc 09:47:55 .. this all left to the browser 09:48:01 Ashok; not to the user? 09:48:16 Dom: For geolocation... 09:48:24 Ashok: yo can as a user author a policy? 09:48:35 dom: you can revoke access for a given webite. 09:48:54 there is no UI for it, there is no policy api in the web briwser 09:49:10 In deveice APIs, we really did explore that space quite a lot. 09:49:27 They could seethe long term value but ... 09:50:04 Some talk about having a generic application-wide ploicy, like CIA wantt o to prevent location aver being availebl 09:50:24 dom: [slide 9/16] 09:51:35 Robin: The ideal is fro the user to make an informed decision without thinking 0.5 ;-) 09:52:40 jar: what info is not sensitibve 09:53:14 larry: sometimes a problem is one person giving away ino sensitive another person. like mentiojing their name and email in the same sentence 09:53:35 we can't just restrict heis talk of privacy to a user's own informarion 09:55:21 larry: When geopriv talked about privacy policy, they ended up with a API extension which inststed on pasing a policy and a timeout with every API call 09:55:42 dom: I am not saying thie is THE solution, i am just pointing out what is out there 09:56:09 larry: consent, opt in and opt out .. we should look hard at te assumiton that assent helps. 10:00:48 q+ ht 10:01:07 ack ht 10:01:07 ack next 10:02:09 ht: i am persdonally in the "always run virus check" in anything I install 10:02:29 as I had a terrbl expereince with a bad download once. 10:03:37 ... tjere is nothing on the phone which allows me to look at any web app, look at the javascript, and figure out whether 10:03:51 it is a bad one. 10:04:17 http://www.veracode.com/ ??? 10:04:22 Noah: Different - viruses you just look for signature of particular hacks, on js in general, you can't just look atthe code 10:04:43 tim: Codepath tracing is gettinng pretty soipohisticated, and maybe in the future yo might be able to 10:04:45 q+ 10:05:06 robin: There is a crowdsourced databse of known bad web apps 10:07:25 q- 10:09:51 The Nutrition Facts for what apps to for you would be a great additioon to the ad-on store,as it would renove the "after that a free-forall": problem 10:10:13 q+ 10:10:28 Noah: diff suers might care about diff things -- especially among marioo users 10:10:43 some users would regret their deceision a lot, lots wouldn't 10:17:21 robin: The android ui is generally regarded as horrible 10:17:48 toim: maybe with some rethnking it could be better, and if it makes promises about what the app will do rather than talk about th elow-lwvel access the app is allowed. 10:18:35 q? 10:19:08 q- 10:24:19 http://i.imgur.com/JWEII.jpg -> screenshot of the Android permissions dialog 10:28:49 q+ 10:29:16 larry: we don't have a vocabulary for trust 10:29:46 ... I would like to see use cases; we have stories that we should collect together and analyse them 10:30:08 timbl: we've been doing that within MIT for 10 years 10:30:30 ... anyone who tries to make an algebra of trust is making a big mistake 10:30:34 ... they don't match the real world 10:31:02 ... trust systems have to connect to the real world, and therefore has to be a semweb application 10:31:18 ... I want to be able to say that my coworkers can access something 10:31:34 ... that the DIG blog could be commented on by friends of friends 10:31:37 q+ to talk about identity and 'owner' 10:31:44 ... or who had attended a particular conference 10:31:59 ... I don't want to have a Google Circle to drag them into 10:32:09 ... you have to connect trust to reality 10:32:15 ... which is what the semantic web does 10:32:26 http://masinter.blogspot.com/2011/08/internet-privacy-telling-friend-may.html 10:32:57 larry: I was complaining about the word 'owner' to talk about meaning, because we don't have a good notion of identity 10:33:16 ... in order to talk about trust, you have to have a model of identity 10:33:31 ... if there's a problem defining the owner of a URI 10:33:46 ... or the namespace of individuals 10:34:02 ... perhaps we create a namespace of identity by projecting owners 10:34:15 ... you provide identity by saying which URIs they control 10:34:23 Larry: maybe we could identify principles by the URI [domain names, email ids etc] they control 10:34:42 timbl: that's OpenID 10:34:57 ... it identifies you as the person who has write access to a given page 10:35:11 robin: and BrowserID identifies you through an email address 10:35:16 timbl: and WebID does the same thing 10:35:29 q? 10:35:33 q- 10:36:00 i wonder what is the identity of "browser vendors" 10:42:05 q+ 10:42:37 product safety evaluations 10:42:40 q+ 10:43:27 q- 10:43:50 larry: this is like product safety 10:43:59 ... cars that you can drive off a cliff aren't unsafe 10:44:33 ... there's an assumption about asking permission where people understand the permission is better than one where the permission isn't clear 10:44:42 ... perhaps these are like product safety ratings 10:44:58 ... are we looking for PICS extended to apps 10:45:18 ... as we talk about rating and validating 10:45:27 robin: that could be done in the ecosystem, but not at this level 10:45:36 larry: the stuff about what apps gets into the app store 10:45:47 robin: if you have a policy-based system; that's the question we have to ask first 10:45:54 dom: out-of-band curation is one possible approach 10:45:59 ... I think we'll see multiple approaches 10:46:10 ... there isn't a shared understanding within the WGs about what will work for the web 10:46:20 robin: or what the stories are, what the problem space are, what the terminology is 10:46:27 larry: the stuff about origin is also a matter of trust 10:46:30 ... a matter of brand 10:46:47 ... I trust my bank, and things I download from my bank 10:46:55 ... brands give you trust 10:47:05 dom: I agree that origin is related to brand 10:47:18 larry: there's something about PICS we don't want to repeat, as it didn't succeed 10:47:26 ... but we can't avoid it by just saying we're not going there 10:47:41 dom: I don't think any of us know where exactly we're going 10:48:00 ... I think the TAG, as cross-group, cross-technology issues should be helping 10:48:17 ... to identify terminology, to identify experts 10:48:35 larry: I'm trying to map out the space: brand, trust, rating, authority 10:48:46 ... finding others who have mapped out the space, and adopt the framework 10:49:11 noah: we've often said that the TAG should work in this space, but not found someone to do it 10:49:30 robin: I would like to do this work 10:49:39 ... the first step, which might lead to further work... 10:49:46 ... would be to agree on some terminology 10:49:51 ... which is currently chaotic 10:50:12 ... it would be very helpful for cross-group understanding 10:50:21 noah: who else would we have to involve? 10:50:30 robin: from B2G project, from the Trident project 10:50:45 noah: could we do that without starting a Community Group? 10:50:50 robin: maybe a TF? 10:51:13 ... I'd avoid a CG because it can be hard for members to join 10:51:20 ... I'd prefer a TF, separate from www-tag 10:51:47 ashok: a Finding on this would be wonderful 10:52:14 ... terminology, mapping the landscape, use cases 10:52:43 noah: we have to work out the initial scope 10:53:10 ashok: I would go beyond terminology, to use cases and landscape 10:53:15 robin: terminology alone won't cut it 10:53:25 ... first success would be to get the right people talking together 10:53:37 ... include people from Privacy IG 10:53:48 noah: what other deliverables? 10:54:10 jar: the use case list and terminology mesh very nicely 10:54:25 robin: I'm happy to do that, and I can get funding to do it 10:54:42 noah: does anyone object to this? 10:55:46 JeniT: how does the privacy draft fit into this? 10:56:00 robin: I will need to think about whether it should be a product of the TF 10:56:12 noah: from TAG logistics, is it one or two things to track 10:56:42 timbl: we could bank what we have, publish it as a Note 10:56:48 ... get it out there 10:57:02 noah: there's a dated editor's draft available 10:57:16 ... to publish it as a Note, we'd need more sessions 10:58:16 timbl: we should produce something sooner rather than later 10:58:54 noah: we were reviewing as first draft yesterday 10:59:06 robin: I have a bunch of updates to make on it 11:00:24 ... I'll do another draft, and let's see what people think of it then 11:01:47 larry: I'd be happy publishing it to say "this is our initial work on this topic, which we will take forward" 11:02:22 ... my objections were about taking it forward as a longer-term effort 11:02:39 ... in terms of RFC categories, it's not April Fools and it's not Standards Track 11:02:49 ... publishing things early is good as long as the status is clear 11:03:10 noah: I'm only worried that people might take it as being something the TAG believes 11:03:32 ACTION: Robin to update Privacy by Design in APIs 11:03:33 Created ACTION-684 - Update Privacy by Design in APIs [on Robin Berjon - due 2012-04-10]. 11:03:46 ashok: how does this relate to the bigger Finding we talked about? 11:04:01 noah: Robin should scope that larger thing, I think we should leave it to him 11:04:13 ... draft a product page 11:04:34 jar: limited scope for Note as written 11:04:52 ... I don't see the relationship with the other 11:04:59 ACTION-514? 11:04:59 ACTION-514 -- Robin Berjon to draft a finding on API minimization -- due 2012-05-01 -- PENDINGREVIEW 11:04:59 http://www.w3.org/2001/tag/group/track/actions/514 11:05:18 larry: I think this is more about an architecture around security and permissions 11:05:28 close ACTION-514 11:05:28 ACTION-514 Draft a finding on API minimization closed 11:06:03 ACTION-684 Due 2012-05-08 11:06:03 ACTION-684 Update Privacy by Design in APIs due date now 2012-05-08 11:06:47 .ACTION: Robin to create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. 11:08:14 ACTION: Robin to create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. - Due 2012-04-17 11:08:14 Created ACTION-685 - create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. [on Robin Berjon - due 2012-04-17]. 11:08:56 Task force on X where X = ? some options: [Web] Privilege Grants; Web Trust use cases & terminology 12:19:21 timbl has joined #tagmem 12:19:45 http://tools.ietf.org/html/draft-ietf-iri-comparison-01 12:19:47 timbl_ has joined #tagmem 12:20:29 A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. A percent-encoded octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing that octet's numeric value. For example, "%20" is the percent-encoding for the 12:22:29 RRSAgent, minutes? 12:22:29 I'm logging. Sorry, nothing found for 'minutes' 12:22:41 ScribeNick: ht 12:22:49 Scribe: Henry S. Thompson 12:22:51 Ashok has joined #tagmem 12:22:51 Larry and I agree that http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref is inconsistent with RFC 3986 view of equivalence 12:22:53 RRSAgent, pointer? 12:22:53 See http://www.w3.org/2012/04/03-tagmem-irc#T12-22-53 12:23:28 and that therefore the strings that are called "URIs" in RDF are not really URIs 12:23:34 We noted that the HTTP BIS hd been changed significantly to be consistent \with a non-document vew of the web whcih it had started with. 12:23:38 over lunch 12:24:11 Topic: WebApps Storage 12:24:17 http://www.w3.org/2001/tag/2012/04/02-agenda#storage 12:25:37 http://trac.tools.ietf.org/wg/iri/trac/ticket/111 12:25:52 http://trac.tools.ietf.org/wg/iri/trac/ticket/113 12:25:54 NM: Time to get this over the last hurdles 12:26:07 http://trac.tools.ietf.org/wg/iri/trac/ticket/114 12:26:28 http://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf 12:26:58 http://trac.tools.ietf.org/wg/iri/trac/ticket/112 12:27:02 AM: The above is a discussion document asking us to know whether we should go in this direction 12:27:16 s/know/consider/ 12:27:54 LM: We could also consider combining this with web vs. native apps topic 12:28:27 NM: [points us to draft product page: http://www.w3.org/2001/tag/products/clientsidestorage-2012-03-02.html] 12:28:45 I think there's a strong correlation between local storage with backup (for native apps), vs web storage with caching (for web apps) 12:29:03 noah has joined #tagmem 12:29:34 NM: [takes us through the product page] 12:30:26 [larry, I think that native or web is orthogonal to this problem — issues are about identifying resources irrespective of storage location, and the value of client/server synch] 12:30:39 NM: Is this roughly in the right direction 12:30:41 https://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf 12:31:14 AM: My doc addresses the question of how to write apps which would run seamlessly whether connected or disconnected 12:31:28 ... Three requirements I came up with: 12:31:47 q+ 12:31:57 ... 1) What it requires when it's connected; 12:32:09 ack next 12:32:11 ack next 12:32:11 q- 12:32:12 ack next 12:32:14 q? 12:32:16 ... 2) Minimum requirement when _not_ connected 12:32:33 ... 3) Where it might find those requirements 12:32:42 I think we need to state the relationship between identification and access when connected and when not 12:33:17 AM: Hints about (3) might be AppCache, IndexedDB, local file store, Web Storage 12:34:07 AM: Regardless of how the local information is found, should be accessible in a uniform way 12:34:47 NM, TBL: That sounds contradictory 12:34:59 RB: By user or by app? 12:35:02 AM: By app 12:35:44 TBL: MySQL API and filestore API are different, right? 12:36:03 AM: Yes, but once you access a particular resource, the API thereafter is the same 12:36:29 TBL: So a resource is for instance a JSON blob 12:37:25 Tutti: So there are two layers -- a layer of access, which is different for different stores, and a layer of utilisation of a resource once accessed, which is uniform whereever it comes from 12:38:09 NM: So if the store happens to be a SQL store, access might involve joins 12:38:15 AM: Yes 12:38:17 i'm concerned about error recovery, update conflict resolution, etc. when working offline? 12:38:44 NM: So we don't lose the unique value of the particular storage media 12:38:46 AM: Right 12:39:00 TBL: Does anyone understand where this is going/why? 12:39:22 timbl has joined #tagmem 12:39:24 AM: The fact is that there will be lots of different storage media 12:40:12 ashok urging shared API for the objects retrieved using all the various APIs? 12:40:12 NM: So once I've got a JSON blob I can do another join 12:40:18 AM: Not talking about that 12:40:28 q+ to offer a motivation 12:40:42 AM: Think of this as a calendar app 12:40:55 timbl_ has joined #tagmem 12:40:57 AM: So suppose you got the blob which is your calendar 12:41:39 ... as you work with it, you update it 12:42:11 AM: If the app was running connected it would be working with both local and global calendar 12:43:01 ... but if running disconnected, you have only the local resource available 12:43:31 noah: requires distributed 2-phase commit 12:43:36 AM: yes 12:43:46 s/requires/does this require/ 12:43:55 AM: Once you get connected, you start transactions at both levels, back out all local-only changes, recommit them all both locally and globally, then complete the transactions 12:44:26 NM: That requires a lot of mechanism, to support distributed two-phase commit 12:45:47 s/commit/commit, and is typically not nearly stateless./ 12:48:10 TBL: Backing up, 'access' built out of parts, or blob stored monolithically? 12:48:41 AM: Let's not go to complex access, e.g. joins, simpler to assume monolithic storage. 12:49:44 TBL: IPhoto stores [in a more complex way] 12:50:26 NM: I'm pushing on this because I think he's solving the wrong problem 12:50:35 s/IPhoto/iPhoto/ 12:51:19 AM: If you exploit a particular storage scheme's special properties, then you are tied to it 12:51:29 ... but I didn't want to go there 12:52:06 HT: I've had this problem: you have a storage problem and an interoperability problem 12:52:14 ... you don't know what provision the platforms have 12:52:25 ... I had to write different shims for the different storage facilities across the different browsers 12:52:33 ... cookies, Google Gears or whatever 12:52:39 ... that's what Ashok is trying to solve 12:53:09 HST: I understand the problem AM is trying to solve, it's the fact that different platforms today support _different_ basic offline storage model 12:53:34 NM: Right, that's just a matter of API design, not a problem the TAG needs to work on 12:54:00 AM: The problem I see is that not all the backends have transactions, which my story needs 12:54:05 JAR: They will 12:54:18 TBL: You can use e.g. git on top of a local filestore. . . 12:54:37 i/TBL:/RB: localStorage won't/ 12:55:03 AM: Moving on -- if the commit described above fails, the user loses all their work 12:55:22 NM: Fails, or there's a conflict? 12:55:37 AM: Conflict, right -- that's the bad case 12:56:05 AM: Can we say anything beyond "The app has to do what it can" 12:56:18 NM: There is 30 years of work on this problem 12:56:45 TBL: Apple Sync Services [sp?] requires you declare your object type, e.g. Calendar Event 12:57:36 ... Mostly works, but if you have conflicting values for the same field, there's a generic tabular conflict resolution display to the user 12:58:10 TBL: My experience is that this sometimes happens when I can't see any difference in that display, or even when I haven't touched the app on the phone at all. . . 12:58:33 NM: Lotus Notes has application-specific handlers 12:58:55 ... Default is to make two copies of the relevant unit 12:59:55 NM: Difference between deletion and creation is tricky, sometimes handled by 'tombstones', with timeouts 13:00:29 ... so you can tell the difference between "I deleted, you didn't" and "You created, I didn't" 13:01:04 NM: Multi-person, multi-year task and then you don't get it right -- we shouldn't go there 13:01:49 TBL: Another route is to enforce universal undo, so you can step back one step at a time 13:02:15 NM: You're relying on there always being a human always available to help 13:03:07 Right...that's my bottom line. This is the wrong problem for us to be trying to solve AND, even if it were the right problem, the solutions are horrendously difficult, have been worked on for 30 years, and would be in the hands of a design/development group, not the TAG 13:03:07 AM: Yes, some DBs to that 13:03:27 s/human available/human/ 13:03:51 q? 13:03:53 q+ 13:03:57 I would like us to look at one particular problem: when I use an application that runs locally and potentially disconnected, to update information that we otherwise want on the Web, what is good architecture regarding identification, and what latitude should be available for implementation? 13:04:06 q- ht 13:04:48 Tutti: discussion of various source control systems' approach to related pblms 13:04:53 I would like to see a finding that if information is to be identified with a URI for use on the Web, then it should be identified with the same URI when accessed disconnected. 13:05:23 JAR: I agree with NM that there is a huge background wrt sync -- is that what we want to work on? 13:05:47 AM: Is it important for us to be able to/support other who want to write "seamless apps" 13:05:59 q? 13:06:08 q+ to talk about architectural principle 13:06:12 ack jrees 13:06:30 RB: We are seeing a collection of offline stores being deployed, can we get in now to help exploit them responsibility 13:06:51 NM: [reads the above] 13:07:03 s/above/above about URI/ 13:07:09 nm: f information is to be identified with a URI for use on the Web, then it should be identified with the same URI when accessed disconnected. 13:07:36 AM: I asked Raman about this, wrt using GMail offline -- does the message have a URI? 13:07:50 ... He said pbly not until it gets online 13:08:22 NM: I'm not saying it's obvious how to do this, but it would have real value if we did 13:08:55 ... Consider working on an airplane, writing a document _and_ an email which points to the document, by its URI 13:09:12 ... So that when I get online, I synchronize and the email ships 13:09:29 ... The email should point to the document online 13:09:57 NM: This is (close to) what Lotus Notes has done for years 13:10:29 NM: This may be too hard, at least in some cases, but it _is_ an architectural desideratum 13:11:17 AM: How can you have the same URI -- you're not on the Web when you are on the airplane 13:11:37 NM: Yes I am -- the Web is not a set of servers, it's an information space 13:12:49 NM: I suspect if follows that the apps do the work, not the underlying storage mechanism 13:13:33 ... That means e.g. the JScript in GMail knows enough to create URIs in a way consistent with the way those names will be created at sync time 13:14:18 AM: So, is all we can say application-specific architectures will exist, or can we say something overarching? 13:14:52 NM: Well, at least Good Practices, as above, and _maybe_ design patterns and even maybe APIs to support them? 13:15:00 s/do the work/do any necessary synchronization/ 13:15:21 TBL: LOD API work relevant? 13:15:30 AM: Maybe 13:15:50 s/LOD/LDP/ 13:16:16 NM: What I said was, I'm >guessing< that in practice apps would mostly do the syncing, as they do today. There might be some shareable infrastructure the emerges to help the apps, e.g for storing URI-identified rows in index-DB or sql and/or tracking updates since last connect. 13:16:31 TBL: Apps use a triple-based API, which is grounded in a generic store 13:16:40 NM: I >don't< think the TAG should spec the exact sync protocol or shared facilities. We should make statements about how URIs are used. 13:17:06 NM: Of course, we need to be sure that what we recommend is deployable in practice, and that it meets the intended needs. 13:17:18 TBL: Interaction between API and store is "fetch/store the entire store" or "delta" 13:17:24 ... That's where sync has to happend 13:17:30 s/happend/happen/ 13:17:47 TBL: So this is a generic approach to sync 13:18:03 s/is a/would enable a/ 13:18:44 q? 13:18:47 q- 13:20:10 NM: So, where do we go with this? 13:20:45 NM: We've seen AM's proposal, my alternative, and TBL's LDP example 13:21:08 ... Not sure whether LDP is a third proposal 13:21:30 AM: I think the LDP story goes way beyond NM's approach 13:21:43 q+ to ask if we have a client 13:22:00 q? 13:22:05 NM: So what story are we trying to tell? 13:22:05 ack next 13:22:06 ht, you wanted to ask if we have a client 13:22:43 NM: Not as such -- people are building stores, but no-one has asked for our advice 13:23:12 q? 13:23:20 q+ to comment on Robin's proposal 13:23:26 JAR: I prefer RB's "Goal is to try to anticipate pitfalls and raise awareness" better than the existing product page's goal 13:23:56 HST: [above] Is anybody asking for this? Is anybody listening? 13:24:27 NM: Yes, if you mean high-level pitfalls, i.e. we are the T _A_ G 13:25:00 RB: I _have_ these problems today, and don't know where to look for help 13:25:18 NM: As long as we don't try to roll our own 13:25:26 TBL: Pointing to existing solution spaces 13:26:00 JAR: Commissioning ourselves to do a report on the problem 13:26:24 NM: CloudDB guys said they were building on some of the Lotus Notes work, e.g. tombstones 13:26:46 s/CloudDB/CouchDB/g 13:26:47 http://couchdb.apache.org/ 13:26:52 q? 13:27:03 q+ to comment on noah's idea 13:28:28 RB: CouchDB is simple, you put JScripts docs in, nothing is deleted, you access with Map-Reduce 13:28:44 CouchDB Overview: http://couchdb.apache.org/docs/overview.html 13:28:54 AM: What can we say generally? 13:28:55 [I'm not sure the TAG documenting Web apps sync will reach the right audience (presumably Web developers?)] 13:29:11 s/JScripts/JSON/ 13:29:33 HST: I think this is a Vietnam, we should walk away 13:30:20 NM: Straw poll: 13:30:36 . . . Nothing: 3+ 13:31:57 . . . Work towards a uniform API, maybe including sync, per AM/Product page: 0? 13:32:08 . . . Patterns/pitfalls: 5 13:33:28 NM: If we tried to do PaPi (per RB), volunteers? 13:33:36 RB: I'll review and advise 13:33:42 LM: As before 13:33:50 AM: Yes, I'll try 13:33:56 NM: I'll review 13:34:33 NM: So, clean up the Product page and get started on the work 13:34:53 the product page is meta, not worth spending much time on when we can work on the document 13:35:19 ACTION-647? 13:35:19 ACTION-647 -- Ashok Malhotra to draft product page on client-side storage focusing on specific goals and success criteria -- due 2012-03-06 -- OPEN 13:35:19 http://www.w3.org/2001/tag/group/track/actions/647 13:35:33 are we commisioning a study or just a survey 13:36:33 LM: If we find a survey then this can be simple -- we just distill and point 13:36:51 telling people where the cliffs are that they might fall off, we don't have to build the guard rails 13:37:09 HST: I was worried that if JAR's summary, that we need to do the survey ourselves, then this is too big a task 13:37:29 s/, then/is the case, then/ 13:37:33 the product page is just there to tell people the general area where we're working, don't deep end on it 13:37:44 .ACTION: Robin to draft scope and goals for the Patterns/Pitfalls work in local/remote storage synch 13:39:22 ACTION-572? 13:39:23 ACTION-572 -- Yves Lafon to look at appcache in HTML5 -- due 2012-03-06 -- CLOSED 13:39:23 http://www.w3.org/2001/tag/group/track/actions/572 13:42:16 NM: Adjourned until 1600, then DHM on threats and opportunities on the Mobile Web 13:53:37 masinter` has joined #tagmem 13:56:08 http://tools.ietf.org/html/draft-ietf-iri-comparison-01 should update 3986 14:05:07 http://trac.tools.ietf.org/wg/iri/trac/ticket/112 14:05:21 http://trac.tools.ietf.org/wg/iri/trac/ticket/114 14:07:35 at IRI meeting last week we resolved to look at http://tools.ietf.org/wg/precis/ 14:07:42 on break, TimBL, Larry, JAR about whether web spec level can be separated from application level and/or social good level (?) 14:07:46 [Resuming at 1608] 14:07:54 s/can be/should be/ 14:08:35 maybe s/level/scope/? 14:08:38 conformance vs. social expectation 14:08:55 conformance doesn't require you to do things that the social expectation for normal use of the web might require you to do 14:09:32 and if you want to create applications that rely on conforming properties, you might not be able to rely on the social conventions being followed 14:09:43 NM: Mobile issues, then Admin 14:10:11 DHM: Two main points 14:11:35 DHM: Disruptive impact coming from Web being on some many different platform, but that you can build cross-/multi-platform applications 14:12:12 ... E.g. using web app on phone so that tilting phone reorients image on a different device 14:12:32 masinter` has joined #tagmem 14:12:32 ... "Hyper-devices": the Web enables new use of our devices 14:12:42 masinter has joined #tagmem 14:13:14 NM: Blue Spruce at IBM looked at cross-linked browsing experience 14:13:21 AM: WebX ? 14:13:28 http://www.readwriteweb.com/archives/ibm_blue_spruce_first_look.php 14:13:35 AM: Not shared desktop, but ??? 14:13:43 http://www.w3.org/QA/2011/11/from_hypertext_to_hyperdevices.html 14:13:45 s/AM: Not/NM: Not/ 14:13:53 dom, link to blog post please? 14:13:59 NM: Linkage at the level of DOM 14:14:12 s/WebX/WebEx/ 14:14:32 Project Blue Spruce may be of interest: http://www-01.ibm.com/software/ebusiness/jstart/bluespruce/ 14:14:35 DHM: Not sure about the architectural impact, but thought worth mentioning 14:14:46 DHM: Other area is WebRTC 14:15:06 ... Real-time peer-to-peer communication 14:15:16 ... File-sharing as a side-effect 14:15:49 DHM: WebRTC is essentially Skype within the browser 14:16:06 ... Audio-Video comms within the browser is the driving app 14:16:42 ... Two parts: Access to the camera, mike and audio out; peer-to-peer connection 14:16:58 ... There is a requirement for a mediation server, but there is work at eliminating it 14:17:32 DHM: There's a JScript API, plus a UDP-based protocol defined at IETF 14:18:13 ... Two phases, establishing the connection and then actually trading data 14:18:28 s/JScript/Javascript/ 14:18:49 s/API/API defined at W3C/ 14:19:12 DHM: RTCWeb is name for IETF protocol, WebRTC is the W3C API 14:19:59 NM: Patent problems? 14:20:20 DHM: Pretty confident at IETF this stuff is safe 14:21:09 ... But the codec issue is still live, as it must be common between the two peers 14:21:33 DHM: Some vendors don't want MPEG4 to be allowed 14:21:53 LM: How far along is codec and transport 14:22:06 s/transport/transport?/ 14:22:32 DHM: Last week at IETF Paris chairs put pressure on getting to consensus 14:23:01 JAR: Doesn't this raise the possibility of peer-to-peer HTTP? 14:23:43 masinter has joined #tagmem 14:23:49 DHM: Yes in principle, but not in practise yet, but that's one of the potential disruptive impacts that's coming 14:24:12 http://tools.ietf.org/wg/rtcweb/ 14:24:23 TBL: I've always been interested in p2p for HTTP as a tool against censorship 14:25:09 DHM: At the moment the peers have to access essentially the same Web page to initiate the connection 14:25:30 http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00 14:25:48 The Web Real-Time Communication (WebRTC) working group is charged to 14:25:48 provide protocol support for direct interactive rich communication 14:25:48 using audio, video, and data between two peers' web-browsers. This 14:25:51 document describes the non-media data transport aspects of the WebRTC 14:25:55 framework. It provides an architectural overview of how the Stream 14:25:58 Control Transmission Protocol (SCTP) is used in the WebRTC context as 14:26:01 a generic transport service allowing Web Browser to exchange generic 14:26:04 data from peer to peer. 14:26:33 note that SCTP vs. SPDY was a hot discussion at IETF 14:26:48 TBL: Jonathan ?? at the Berkman Center at Harvard has a project mirror as you link to develop data sharing on the Web 14:27:03 Zittrain 14:27:39 s/??/Zittrain/ 14:29:23 NM: We haven't yet proven that this approach to p2p maps to the existing uses of e.g. bittorrent 14:29:49 JAR: I was surprised that these two were tied 14:30:28 TBL: Discovery is a big complex pblm 14:30:44 ... E.g. use a distributed hash table of everyone who is looking for a connection 14:31:14 DHM: There is a whole stack here, with security and encryption and so on 14:32:46 ... Just SSL isn't good enough, to avoid man-in-the-middle attacks at the connection initiation time 14:33:12 ... Because we don't have universal crypto-secure personal identities 14:33:51 ... One proposal is to use mutually-trusted shared identity providers, such as Facebook, to reciprocally verify 14:34:20 we talked earlier about using "owner(URI)" as an identity token 14:34:44 http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-01 14:35:05 AM: Isn't it easier to just encrypt the conversation 14:35:24 s/conversation/conversation?/ 14:35:38 DHM: But we don't have a deployed PK system on the Web? 14:35:43 s/?// 14:36:20 http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf 14:36:45 TBL: PK doesn't need PKI -- it can be much simpler 14:37:15 NM: Ray Ozzie did instant group-creation before he xxx, called Groove 14:38:06 s/he xxx/his company was bought by Microsoft/ 14:38:20 JAR: PKI can be decoupled from the problem, and doesn't need the whole PKI as we understand it/ 14:38:41 NM: Groove uses a peer exchange of public keys to establish identities, then allows collaboration groups to be created across organizations 14:38:52 The link that LM entered is to a presentation "Media Security: A chat about RTP, SRTP, Security Descriptions, DTLS-SRTP, EKT, the past and the future" 14:38:52 presentation from last week's RTCWEB discussing keys management and rtcweb security 14:41:53 NM: Thanks to DHM! 14:42:47 Topic: Administration 14:45:09 RESOLUTION: Minutes of 8, 15, 22 March all approved as a fair record of the respective meetings 14:45:27 http://www.w3.org/2001/tag/tag-weekly#Admin 14:45:33 NM: Agreed in the past that we would meet 12-14 June 14:45:38 ... in Cambridge 14:45:55 does TAG have opinions about W3C process http://lists.w3.org/Archives/Public/www-archive/2012Mar/att-0007/AB_List_of_Concerns-20120306.htm ? 14:46:12 NM: Our end-of-summer f2f has yet to be scheduled 14:47:00 ... I will have difficulty travelling in September or for TPAC in November 14:47:29 NM: Options include -- yet again in Cambridge, Septemberish 14:47:44 http://www.w3.org/2012/10/TPAC/ 14:48:10 NM: Another alternative would be a weekend before/after TPAC 14:48:29 ... althought that is in Europe again 14:48:41 NM: Our without me 14:49:04 s/Our/Or/ 14:49:48 RB: Weekend OK but _not_ next to TPAC 15:02:54 NM: Net-net -- we will wait a while before trying to schedule the next f2f after June 15:03:16 NM: Adjourned until 0915 15:08:10 Never mind, we are not adjourned 15:09:11 Topic: XML Error Recovery 15:09:47 RB: At XML Prague a lot of discussion about future of XML, XML and JSON, etc. 15:10:04 s/a lot/March 2012 a lot/ 15:10:20 RB: A panel on XML / HTML issues, chaired by Norm Walsh 15:11:06 ... There was consensus of interest in a processing model for XML that would not halt and catch fire at first well-formedness error 15:11:52 JT: There would be reporting of any error recovery actions to e.g. Firebug and/or the console 15:12:11 RB: The advantage would be that users would not be punished for the errors of others 15:12:29 NM: The scoping to end-user browser scenarios is xxx 15:12:34 JT: Not exclusively 15:13:16 JT: Other discussions identified other use cases: editors "of necessity" go through states where the documents are not well-formed, but a tree-view is still useful 15:13:34 ... Mark Logic has an error-recovery mode for loading into the DB 15:13:39 ... As do some editors 15:13:48 ... but all of that is idiosyncratic 15:14:07 JT: So the question was if we could have uniform and predictable error recovery 15:14:14 ... across all three use cases 15:15:04 AB: [libxml pattern] -- same document twice gives same result 15:15:11 s/AB:/RB:/ 15:15:36 RB: Primary use case is in trying to deploy XML to user-facing apps 15:16:20 ... The fact that the halt-and-catch-fire experience blows that, so browsers have started silently correcting 15:16:52 JAR: But we know where silent error recovery leads -- it leads to HTML5 -- the moving target aspect is really bad 15:17:29 NM: We can address that by publishing a TAG finding to insist on no silent error recovery 15:17:43 JAR: Errors have to be ugly, to put pressure on fixing them 15:18:37 TBL: Designing the level of ugliness is important -- the console is too well hidden -- show the warning briefly 15:18:49 ... and allowing it to be configured to persist, for instance 15:19:32 q+ to discuss why use cases matter and why standardization matters 15:19:36 RB: So that discussion led to a W3C Community Group, with Anne van Kesteren editing his earlier XML 5 draft, but the work product will _not_ be called XML 5 15:20:06 RB: This is not going to run at breakneck speed, but will work its way along 15:20:22 AM: Does Mark Logic have a patent in the area? 15:20:39 JT: They use the schema to help, I don't know about a patent 15:21:11 HST: There's prior art . . . 15:21:20 ack next 15:21:21 ack noah 15:21:22 noah, you wanted to comment on Robin's proposal and to discuss why use cases matter and why standardization matters 15:21:40 NM: The stakes go up for automatic data import 15:22:22 ... There are gambles you are willing to take when heading for a web page that are inappropriate for importing mission-critical data which may not be used for some time. . , 15:22:27 s/,/./ 15:23:00 NM: So starting with an existing algorithm w/o much inclination to change it makes me nervous 15:23:12 quiet error recovery in popular browsers is more harmful than vendor prefix 15:23:44 but we have this with MIME type sniffing too, which is a kind of quiet fixup 15:23:56 NM: The pervasiveness of consistent error recovery will change community expectations 15:24:07 sniffing application/xhtml+xml => text/html is an automatic fixup 15:24:10 RB: For me user-facing software is the key case 15:24:12 q+ to talk about feeeds 15:24:30 RB: But browser deployment will leak, no matter what 15:24:34 q- 15:24:42 q- rees 15:24:47 ack next 15:24:49 q- jrees 15:24:49 jrees, you wanted to comment on noah's idea 15:24:51 ack next 15:24:51 timbl, you wanted to talk about feeeds 15:26:17 TBL: RDF allows XML buried in RDF, it would be good to allow XML in there [?] 15:27:07 TBL: Feeds with XML in can cause real problems -- RSS readers must be super-tolerant -- but we keep seeing e.g. DOCTYPEs in tweets??? 15:28:18 JAR: So you are heading for tolerance 15:28:43 RB: Not tolerance, they are still errors, with well-defined recovery strategies 15:29:27 RB: The HTML situation is horrible not because of tolerance, but because the recovery rules are so complicated because the recovery heritage is so complex 15:29:44 JAR: This will promote a race to the bottom 15:29:52 RB: Is that a problem, and if so why? 15:30:12 JAR: There will be no selective pressure 15:30:39 JAR: Drift in the correction landscape will eventually lead to meaning change 15:31:22 LM: Sniffing itself has promoted this by the sniffing of application/xhtml+xml => text/html 15:31:43 LM: If the popular receivers are strict, then producers will check first 15:32:50 RB: Indeed, and sending the same doc to different browsers with different media types makes it worse 15:33:14 q+ 15:33:19 LM: The right place to put this is in Apache and IIS, so the data that goes out is fixed 15:33:34 TBL: And sends a message to root! 15:33:38 ack next 15:34:02 TBL: Whenever you have a string with two different potential readings, you have a security hole 15:34:26 correction is fine but *silent* (i.e. painless) correction is a big security risk 15:35:13 TBL: [complicated example with two recipients which scribe didn't get] 15:37:07 JT: We _are_ committed to non-silent recovery 15:37:55 RB: Exactly what that _means_ is up for discussion and implementation choice 15:38:10 HST: It's precisely those honest additions that make us worried . . . 15:38:18 simple security attack example for diff parsers sdoing different things: was: tim puts up a page which he knows larry's browser and ashok's broser wll see differently, asks larry to ok it to ashok, and then ashok transfers money to tim, as he sees a different message. 15:40:11 NM: Isn't this going to make the sniffing of text/plain as application/xml have dire consequences? 15:41:18 RB: That isn't in scope for the XML ER CG in my opinion, because what causes the UA to treat something as XML is prior 15:41:40 RB: The sniffing stuff is someone else's problem 15:41:53 LM: The sniffing doc't was originally in the HTML WG 15:42:04 ... It was moved to the IETF ??? group 15:42:23 ... Where some members raised doubts 15:42:32 s/???/Web Security/ 15:43:04 LM: I'm not involved in the document 15:43:24 LM: It expired at the IETF 15:43:54 LM: The WebApps packaging draft makes normative reference to the expired draft 15:44:21 LM: The HTML5 draft has a normative reference to the expired draft 15:45:30 LM: One of the issues raised against the document was to never sniff to PDF, the original editor declined to make any change 15:45:46 LM: No examples have been forthcoming 15:46:33 RB: The opposite case does arise, that is, correctly labelled application/pdf docs being sniffed as something else, particularly short ones 15:48:19 LM: My suggestion wrt sniffing was that any document whose media type was determined by sniffing to be different that its published type, then it should get a different/unique origin 15:49:36 LM: We have an abandoned document that a) is normatively referenced; b) creates a problem wrt XML and error recovery; c) contradicts the Authoritative Metadata finding 15:49:48 LM: We should do something, particularly about the XML case 15:50:59 JAR: If the XML ER CG doesn't say anything about sniffing, the TAG will have to. . . 15:52:21 NM: Sniffing XML as non-XML is clearly not relevant to the XML ER CG, but they _can_ say "This algorithm is not robust / appropriate / safe when applied to non-XML sniffed as XML, don't do that" 15:58:39 NM: Please reread authoritative metadata since it clearly talks about security holes 15:58:56 NM: People know the arguments against sniffing, they just think *their* considerations are more important 16:04:42 [scribe notes that discussion continued past the end of scheduled meeting closure] 16:04:53 Of course the semicolon-adding jacascript behaviour of js parsers is a possible security hole, bug etc too 16:05:28 RB: I'm really concerned that the sniffing spec is dead 16:05:44 LM: I tried to get that actioned w/o success 16:06:04 yes, applying the pressure early in the development chain is best, but if a problem gets past all intermediaries, then the final consumer needs to suffer a little, so that there is *some* selective pressure 16:07:03 ACTION: Robin to try to find who is in charge of the current browser content sniffing clustermess, and see if there is a way of moving out of the quagmire - due 2012-05-01 16:07:03 Created ACTION-686 - try to find who is in charge of the current browser content sniffing clustermess, and see if there is a way of moving out of the quagmire [on Robin Berjon - due 2012-05-01]. 16:07:43 RRSAgent, draft minutes 16:07:43 I have made the request to generate http://www.w3.org/2012/04/03-tagmem-minutes.html ht 16:07:53 RRSAgent, make logs world-visible 16:08:23 mmm, so long as automatic semicolon insertion is well-defined (and it is) I think it's security-safe 16:08:51 whether it's good programming style is another issue, of course 16:09:23 no. 16:09:35 speciation in xml would be bad 16:10:36 ACTION: Noah to look for opportunities to discuss putting forward something to the AB about the Process and the failed reference from RECs to expired RFCs as a side-effect of scope creep etc. 16:10:36 Created ACTION-687 - Look for opportunities to discuss putting forward something to the AB about the Process and the failed reference from RECs to expired RFCs as a side-effect of scope creep etc. [on Noah Mendelsohn - due 2012-04-10]. 16:11:00 ACTION-687 due 2012-04-04 16:11:00 ACTION-687 Look for opportunities to discuss putting forward something to the AB about the Process and the failed reference from RECs to expired RFCs as a side-effect of scope creep etc. due date now 2012-04-04 16:11:07 Jim Fuller has done some excellent work on generation of XML language validators based on XSLT/XQuery genetic algorithms, so I think speciation in XML may not be so bad ;-) 17:17:47 noah has joined #tagmem 17:37:48 timbl has joined #tagmem 18:04:12 Zakim has left #tagmem