Technical Architecture Group Teleconference -- 03 Apr 2012

<timbl> JAR: I know what Adam Barth us up to, SES people are up to

<trackbot> Date: 03 April 2012

<timbl> Noah: Robin and i exchanged email.

<timbl> My previous experience was that web has been less successsful than I had hoped.

<timbl> 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

<timbl> like a mixing oard with ipad dock and the software on the ipad

<timbl> This needs a proprietary hardware connector for example.

<timbl> ... 6 channel streaming recorder, effects pedal, ...etc

<timbl> '

<timbl> so you need low-level access to things like DSPs

<timbl> Robin; That is access to the core audio API.

<timbl> Yves: Actually for audio you can do all the processing in JS< it is a q of latency why you need core audio.

<masinter> aspects of native: (a) performance (b) access to APIs (c) monetization (d) trust

<timbl> Noah: A risk of de=facto stdization around a particular connector

<masinter> maybe (b) and (d) are related? vendors link (b) to (c) because platform vendors take percentage

<masinter> (a) performance = throughput but also latency

<JeniT> timbl: using RDF library, has to be aware of 303s etc

<JeniT> ... when running as a script rather than plugin

<JeniT> ... same RDF library; in library it's omnipotent, otherwise in script mode

<noah> 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 errors

<JeniT> ... in script, timeout

<noah> TBL: Get blocked by cross-site scripting

<noah> 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"

<noah> 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

<noah> JAR: Seems analagous to Noah's point about access to the hardware port

<noah> Noah: Yes, except the port access stuff may be harder to make portable if the ports are proprietary and different

<masinter> air & phonegap are examples of 'native app' development tools which allow writing apps as both webapps and native

<noah> 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.

<masinter> http://phonegap.com/

<noah> TBL: The architecture which is emerging has only the two extremes.

<noah> JAR: Do you, Tim, agree that the middle ground is unlikely to worth working toward

<noah> 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

<timbl> jar:

<timbl> the quesion is, is there any middle ground between teh completely trusted and untruted app.

<timbl> orthognal question, can you deisgn APIs wich work in either situatii?

<timbl> there are two general approcahes on the table, form 50k m view

<timbl> One apprach is origin case, origin(module) defines power fo module, links to CORS design

<timbl> The Adam design is you get power by beiung passed it as a parameter

<timbl> This is a 30 year old ACL vs Capability argument, we should nto get into it now. People are polarized.

<timbl> 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

<timbl> In the origin case, you would the origin of the module have the right to do ac call to that URI.

<noah> RB: The origin is that of the HTML page, not the Javascript. It does not track the origin of the script code.

<timbl> 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

<noah> Robin: this stuff is not namespaced

<timbl> Robin: The js is not namespaces -- anything can put calbacks on anything, no boundarties.

<timbl> jar: The aim is "write once, run anywhere".

<noah> JAR: Javascript's kind of like JavaScript

<noah> NM: Well, Java has a pretty elaborate class loader model that's pertinent to how Java code is loaded and gets privilege

<timbl> jar: java security was a disaster -- basde on call chain -- like th eorigin system

<noah> s/th e origin/the origin/

<timbl> 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

<timbl> jar: there is intense pressure to make js apps wok and access things for whcih you nee privs

<timbl> [Enter Dom]

<timbl> dom: a lot of the topics you have been discussing ay be very relevant to what I will present

<timbl> jar; personally, i find this the way to think about it -- it is a q if privs and to whom they are granted.

<timbl> 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.

<timbl> oin fact there are questipns of top wha inside the app it is granted -- not the whole app, as now.

<Zakim> 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

<Zakim> noah, you wanted to talk about shared libraries

<timbl> robin; many things to say

<timbl> 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

<timbl> dom: The device API meting is open and discussed this

<timbl> 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

<timbl> 2) even if we take teh very simple binafry on/off trusr. ther si some roiom for great area.

<timbl> the example fo fthe XHR where you want to not to give error messages

<timbl> In firefox, you double-clik the tab and it makes it an installed apps.

<timbl> tim: really?

<timbl> robin; Concept of installed 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

<timbl> Most of what i wanted to talk abouyt can go into DOM's session

<timbl> SeS are not a solution to the trust issue

<timbl> jar: you mean security

<timbl> robin;: They intermesh -- ses allows you to bring in 3rd party which operate inside a limited space without acecss to each other

<timbl> all polict based systems whcih don't pluf the xss hole are really threatened by thta hole

<timbl> 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

<noah> 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.

<noah> TBL: So, it's not just trusted and untrusted apps in the browser, includes things like node.js.

<darobin> http://www.phantomjs.org/ -> PhantomJS, run a browser on the command line

<noah> TBL: Also... when you download these pieces, we'll need the concepts of agents running on behalf of completely different entities.

<noah> TBL: We will have to surface remote entities as first class.

<darobin> https://github.com/tmpvar/jsdom -> JSDOM, emulation of a browser environment in NodeJS

<noah> 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.

<noah> 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.

<Zakim> timbl, you wanted to just add srever-side and command-line working and to mention agenst of other companies

<timbl> jar I youhave to specify the grandularity of the grant of authority -- is it tak, object, function, program, etc

<timbl> ashok: how can i as a user give this athority to an app?

<timbl> robin: unsolved problem.

<timbl> .. Policy of a rathole to fall into.

<timbl> jar: what about Powerbox?

<timbl> robin: later

<timbl> robin: My personal tak e is a hard to get through process you can't do by mistake.

<timbl> dom: at the moment you can buy stuff on the web no review

<timbl> Noah: We are out of time.

<noah> Web Applications: Security and Web Applications Permissions

Web Applications: Security and Web Applications Permissions

<noah> ACTION-344?

<trackbot> 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

<trackbot> http://www.w3.org/2001/tag/group/track/actions/344

<timbl> Note the change in order from teh piblished agenda, this broght forward from the 100:00 today

<dom> http://www.w3.org/2012/Talks/dhm-tag/

<timbl> Dom: [ presents a talk of 16 slides]

<timbl> Larry: Isn't monetization also a driver for native apps?

<timbl> dom: Phonegap is adderssingthat, but I dobn't thing it is the biggeste driver

<timbl> dom: We also are looking at layment in the W3c headlights process

<timbl> dom: [edits sldei 2 to add Monetization]

<darobin> FYI I proposed an approach to modularisation for features, but there was no interest: http://w3c-test.org/dap/proposals/request-feature/

<timbl> jar: For privacyw ith camera, hwo about confinement?

<timbl> dom: basically impossible

<timbl> jar: confinement being limiting hte ability of the app to send any data back home

<timbl> dom: Interestign tio explor this approach thogh

<timbl> dom: [slide 6]

<timbl> robin: recommend panopticlick

<darobin> http://panopticlick.eff.org/

<dom> https://panopticlick.eff.org/

<timbl> 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.

<timbl> [discussion of fingerprinting details]

<Ashok> Hmmm... I got exactly the same message from Panopticlick

<darobin> http://www.mozilla.org/en-US/b2g/ -> The B2G Project

<darobin> https://www.tizen.org/ -> Tizen Project

<darobin> http://www.w3.org/community/coremob/ -> Core Mobile Web Platform CG

<masinter> http://tools.ietf.org/html/draft-ietf-geopriv-dhcp-lbyr-uri-option-14

<jrees> RSA Conference 2011 - Making Security Decisions Disappear into the User's Workflow - Alan Karp http://www.youtube.com/watch?v=POA8SLCT5EY&noredirect=1

<masinter> http://www.w3.org/2010/api-privacy-ws/

<jrees> here's Karp's tech report http://www.hpl.hp.com/techreports/2009/HPL-2009-341.pdf

<timbl> _______

<timbl> Robi: this is how web intents basially works.

<timbl> You have a service page hcih defines an action, like Pick.

<timbl> Piucking a set of contacts from the addressbook for say asending an emial

<timbl> the service edfinition declares what it can do, pick a set of contacts.

<timbl> Then the user agrent regises this service, modulo user input (?TBD)

<timbl> (chrome people think it can be registerd without ui)

<timbl> You then have a client page.

<timbl> Suppose you have a game -- you don't give the game full access to the entire addressbook.

<timbl> You just wan to it to be given aceess to a set of people

<timbl> The cleint page says "Start activity... pick contacts" includes a button hich the user must press on

<timbl> this pops up a dialog to chose which srevice

<timbl> then it instantiates the service page on the side [in an iframe?] and you pick yoru contacts

<timbl> and the contacts are returned to the to the original page.

<timbl> jenit: who defines whcih fields are actually transferred

<timbl> 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

<timbl> ______ [break] _____

<timbl> Ashok: ...

<timbl> Dom: right now, policy cosiderations are all ateth browser level -- ability to access a website is granted indefinitely

<timbl> Ashok: You asked about geolocation -- that uses policy?

<timbl> dom: In a browser-dependent way - all depends on whethre user as granted it many times, etc

<timbl> .. this all left to the browser

<timbl> Ashok; not to the user?

<timbl> Dom: For geolocation...

<timbl> Ashok: yo can as a user author a policy?

<timbl> dom: you can revoke access for a given webite.

<timbl> there is no UI for it, there is no policy api in the web briwser

<timbl> In deveice APIs, we really did explore that space quite a lot.

<timbl> They could seethe long term value but ...

<timbl> Some talk about having a generic application-wide ploicy, like CIA wantt o to prevent location aver being availebl

<timbl> dom: [slide 9/16]

<timbl> Robin: The ideal is fro the user to make an informed decision without thinking 0.5 ;-)

<timbl> jar: what info is not sensitibve

<timbl> larry: sometimes a problem is one person giving away ino sensitive another person. like mentiojing their name and email in the same sentence

<timbl> we can't just restrict heis talk of privacy to a user's own informarion

<timbl> 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

<timbl> dom: I am not saying thie is THE solution, i am just pointing out what is out there

<timbl> larry: consent, opt in and opt out .. we should look hard at te assumiton that assent helps.

<timbl> ht: i am persdonally in the "always run virus check" in anything I install

<timbl> as I had a terrbl expereince with a bad download once.

<timbl> ... tjere is nothing on the phone which allows me to look at any web app, look at the javascript, and figure out whether

<timbl> it is a bad one.

<jrees> http://www.veracode.com/ ?Zittrain

<timbl> Noah: Different - viruses you just look for signature of particular hacks, on js in general, you can't just look atthe code

<timbl> tim: Codepath tracing is gettinng pretty soipohisticated, and maybe in the future yo might be able to

<timbl> robin: There is a crowdsourced databse of known bad web apps

<timbl> 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

<timbl> Noah: diff suers might care about diff things -- especially among marioo users

<timbl> some users would regret their deceision a lot, lots wouldn't

<timbl> robin: The android ui is generally regarded as horrible

<timbl> 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.

<darobin> http://i.imgur.com/JWEII.jpg -> screenshot of the Android permissions dialog

<JeniT> larry: we don't have a vocabulary for trust

<JeniT> ... I would like to see use cases; we have stories that we should collect together and analyse them

<JeniT> timbl: we've been doing that within MIT for 10 years

<JeniT> ... anyone who tries to make an algebra of trust is making a big mistake

<JeniT> ... they don't match the real world

<JeniT> ... trust systems have to connect to the real world, and therefore has to be a semweb application

<JeniT> ... I want to be able to say that my coworkers can access something

<JeniT> ... that the DIG blog could be commented on by friends of friends

<JeniT> ... or who had attended a particular conference

<JeniT> ... I don't want to have a Google Circle to drag them into

<JeniT> ... you have to connect trust to reality

<JeniT> ... which is what the semantic web does

<masinter> http://masinter.blogspot.com/2011/08/internet-privacy-telling-friend-may.html

<JeniT> larry: I was complaining about the word 'owner' to talk about meaning, because we don't have a good notion of identity

<JeniT> ... in order to talk about trust, you have to have a model of identity

<JeniT> ... if there's a problem defining the owner of a URI

<JeniT> ... or the namespace of individuals

<JeniT> ... perhaps we create a namespace of identity by projecting owners

<JeniT> ... you provide identity by saying which URIs they control

<timbl> Larry: maybe we could identify principles by the URI [domain names, email ids etc] they control

<JeniT> timbl: that's OpenID

<JeniT> ... it identifies you as the person who has write access to a given page

<JeniT> robin: and BrowserID identifies you through an email address

<JeniT> timbl: and WebID does the same thing

<masinter> i wonder what is the identity of "browser vendors"

<masinter> product safety evaluations

<JeniT> larry: this is like product safety

<JeniT> ... cars that you can drive off a cliff aren't unsafe

<JeniT> ... there's an assumption about asking permission where people understand the permission is better than one where the permission isn't clear

<JeniT> ... perhaps these are like product safety ratings

<JeniT> ... are we looking for PICS extended to apps

<JeniT> ... as we talk about rating and validating

<JeniT> robin: that could be done in the ecosystem, but not at this level

<JeniT> larry: the stuff about what apps gets into the app store

<JeniT> robin: if you have a policy-based system; that's the question we have to ask first

<JeniT> dom: out-of-band curation is one possible approach

<JeniT> ... I think we'll see multiple approaches

<JeniT> ... there isn't a shared understanding within the WGs about what will work for the web

<JeniT> robin: or what the stories are, what the problem space are, what the terminology is

<JeniT> larry: the stuff about origin is also a matter of trust

<JeniT> ... a matter of brand

<JeniT> ... I trust my bank, and things I download from my bank

<JeniT> ... brands give you trust

<JeniT> dom: I agree that origin is related to brand

<JeniT> larry: there's something about PICS we don't want to repeat, as it didn't succeed

<JeniT> ... but we can't avoid it by just saying we're not going there

<JeniT> dom: I don't think any of us know where exactly we're going

<JeniT> ... I think the TAG, as cross-group, cross-technology issues should be helping

<JeniT> ... to identify terminology, to identify experts

<JeniT> larry: I'm trying to map out the space: brand, trust, rating, authority

<JeniT> ... finding others who have mapped out the space, and adopt the framework

<JeniT> noah: we've often said that the TAG should work in this space, but not found someone to do it

<JeniT> robin: I would like to do this work

<JeniT> ... the first step, which might lead to further work...

<JeniT> ... would be to agree on some terminology

<JeniT> ... which is currently chaotic

<JeniT> ... it would be very helpful for cross-group understanding

<JeniT> noah: who else would we have to involve?

<JeniT> robin: from B2G project, from the Trident project

<JeniT> noah: could we do that without starting a Community Group?

<JeniT> robin: maybe a TF?

<JeniT> ... I'd avoid a CG because it should be hard for members to join

<JeniT> ... I'd prefer a TF, separate from www-tag

<JeniT> ashok: a Finding on this would be wonderful

<JeniT> ... terminology, mapping the landscape, use cases

<JeniT> noah: we have to work out the initial scope

<JeniT> ashok: I would go beyond terminology, to use cases and landscape

<JeniT> robin: terminology alone won't cut it

<JeniT> ... first success would be to get the right people talking together

<JeniT> ... include people from Privacy IG

<JeniT> noah: what other deliverables?

<JeniT> jar: the use case list and terminology mesh very nicely

<JeniT> robin: I'm happy to do that, and I can get funding to do it

<JeniT> noah: does anyone object to this?

<JeniT> JeniT: how does the privacy draft fit into this?

<JeniT> robin: I will need to think about whether it should be a product of the TF

<JeniT> noah: from TAG logistics, is it one or two things to track

<JeniT> timbl: we could bank what we have, publish it as a Note

<JeniT> ... get it out there

<JeniT> noah: there's a dated editor's draft available

<JeniT> ... to publish it as a Note, we'd need more sessions

<JeniT> timbl: we should produce something sooner rather than later

<JeniT> noah: we were reviewing as first draft yesterday

<JeniT> robin: I have a bunch of updates to make on it

<JeniT> ... I'll do another draft, and let's see what people think of it then

<JeniT> larry: I'd be happy publishing it to say "this is our initial work on this topic, which we will take forward"

<JeniT> ... my objections were about taking it forward as a longer-term effort

<JeniT> ... in terms of RFC categories, it's not April Fools and it's not Standards Track

<JeniT> ... publishing things early is good as long as the status is clear

<JeniT> noah: I'm only worried that people might take it as being something the TAG believes

<darobin> ACTION: Robin to update Privacy by Design in APIs [recorded in http://www.w3.org/2012/04/03-tagmem-minutes.html#action01]

<trackbot> Created ACTION-684 - Update Privacy by Design in APIs [on Robin Berjon - due 2012-04-10].

<JeniT> ashok: how does this relate to the bigger Finding we talked about?

<JeniT> noah: Robin should scope that larger thing, I think we should leave it to him

<JeniT> ... draft a product page

<JeniT> jar: limited scope for Note as written

<JeniT> ... I don't see the relationship with the other

<noah> ACTION-514?

<trackbot> ACTION-514 -- Robin Berjon to draft a finding on API minimization -- due 2012-05-01 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/514

<JeniT> larry: I think this is more about an architecture around security and permissions

<noah> close ACTION-514

<trackbot> ACTION-514 Draft a finding on API minimization closed

<noah> ACTION-684 Due 2012-05-08

<trackbot> ACTION-684 Update Privacy by Design in APIs due date now 2012-05-08

<darobin> .ACTION: Robin to create a product page proposing the Task Force on Web Security/Privileges/Trust/etc.

<noah> ACTION: Robin to create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. - Due 2012-04-17 [recorded in http://www.w3.org/2012/04/03-tagmem-minutes.html#action02]

<trackbot> Created ACTION-685 - create a product page proposing the Task Force on Web Security/Privileges/Trust/etc. [on Robin Berjon - due 2012-04-17].

<jrees> Task force on X where X = ? some options: [Web] Privilege Grants; Web Trust use cases & terminology

<masinter> http://tools.ietf.org/html/draft-ietf-iri-comparison-01

<masinter> 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

<scribe> ScribeNick: ht

<scribe> Scribe: Henry S. Thompson

<jrees> Larry and I agree that http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref is inconsistent with RFC 3986 view of equivalence

<jrees> and that therefore the strings that are called "URIs" in RDF are not really URIs

<timbl> 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.

<timbl> over lunch

WebApps Storage

http://www.w3.org/2001/tag/2012/04/02-agenda#storage

<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/111

<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/113

NM: Time to get this over the last hurdles

<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/114

http://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf

<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/112

AM: The above is a discussion document asking us to consider whether we should go in this direction

LM: We could also consider combining this with web vs. native apps topic

NM: [points us to draft product page: http://www.w3.org/2001/tag/products/clientsidestorage-2012-03-02.html]

<masinter> I think there's a strong correlation between local storage with backup (for native apps), vs web storage with caching (for web apps)

NM: [takes us through the product page]

<darobin> [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]

NM: Is this roughly in the right direction

<noah> https://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf

AM: My doc addresses the question of how to write apps which would run seamlessly whether connected or disconnected
... Three requirements I came up with:
... 1) What it requires when it's connected;
... 2) Minimum requirement when _not_ connected
... 3) Where it might find those requirements

<noah> I think we need to state the relationship between identification and access when connected and when not

AM: Hints about (3) might be AppCache, IndexedDB, local file store, Web Storage
... Regardless of how the local information is found, should be accessible in a uniform way

NM, TBL: That sounds contradictory

RB: By user or by app?

AM: By app

TBL: MySQL API and filestore API are different, right?

AM: Yes, but once you access a particular resource, the API thereafter is the same

TBL: So a resource is for instance a JSON blob

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

NM: So if the store happens to be a SQL store, access might involve joins

AM: Yes

<masinter> i'm concerned about error recovery, update conflict resolution, etc. when working offline?

NM: So we don't lose the unique value of the particular storage media

AM: Right

TBL: Does anyone understand where this is going/why?

AM: The fact is that there will be lots of different storage media

<jrees> ashok urging shared API for the objects retrieved using all the various APIs?

NM: So once I've got a JSON blob I can do another join
... Not talking about that

AM: Think of this as a calendar app
... So suppose you got the blob which is your calendar
... as you work with it, you update it
... If the app was running connected it would be working with both local and global calendar
... but if running disconnected, you have only the local resource available

<jrees> noah: does this require distributed 2-phase commit

<noah> AM: yes

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

NM: That requires March 2012 a lot of mechanism, to support distributed two-phase commit, and is typically not nearly stateless.

TBL: Backing up, 'access' built out of parts, or blob stored monolithically?

AM: Let's not go to complex access, e.g. joins, simpler to assume monolithic storage.

TBL: iPhoto stores [in a more complex way]

NM: I'm pushing on this because I think he's solving the wrong problem

AM: If you exploit a particular storage scheme's special properties, then you are tied to it
... but I didn't want to go there

<JeniT> HT: I've had this problem: you have a storage problem and an interoperability problem

<JeniT> ... you don't know what provision the platforms have

<JeniT> ... I had to write different shims for the different storage facilities across the different browsers

<JeniT> ... cookies, Google Gears or whatever

<JeniT> ... that's what Ashok is trying to solve

HST: I understand the problem AM is trying to solve, it's the fact that different platforms today support _different_ basic offline storage model

NM: Right, that's just a matter of API defined at W3C design, not a problem the TAG needs to work on

AM: The problem I see is that not all the backends have transactions, which my story needs

JAR: They will

<inserted> RB: localStorage won't

TBL: You can use e.g. git on top of a local filestore. . .

AM: Moving on -- if the commit described above about URI fails, the user loses all their work

NM: Fails, or there's a conflict?

AM: Conflict, right -- that's the bad case
... Can we say anything beyond "The app has to do what it can"

NM: There is 30 years of work on this problem

TBL: Apple Sync Services [sp?] requires you declare your object type, e.g. Calendar Event
... Mostly works, but if you have conflicting values for the same field, there's a generic tabular conflict resolution display to the user
... 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. . .

NM: Lotus Notes has application-specific handlers
... Default is to make two copies of the relevant unit
... Difference between deletion and creation is tricky, sometimes handled by 'tombstones', with timeouts
... so you can tell the difference between "I deleted, you didn't" and "You created, I didn't"
... Multi-person, multi-year task and then you don't get it right -- we shouldn't go there

TBL: Another route is to enforce universal undo, so you can step back one step at a time

NM: You're relying on there always being a human always available to help

<noah> 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

AM: Yes, some DBs to that

s/human available/human/

<noah> 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?

Tutti: discussion of various source control systems' approach to related pblms

<noah> I would like to see a finding that if information is to be identified with a URI for use on the Webis the case. then it should be identified with the same URI when accessed disconnected.

JAR: I agree with NM that there would enable a huge background wrt sync -- is that what we want to work on

AM: Is it important for us to be able to/support other who want to write "seamless apps"

RB: We are seeing a collection of offline stores being deployed, can we get in now to help exploit them responsibility

NM: [reads the above]

<timbl_> 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.

AM: I asked Raman about this, wrt using GMail offline -- does the message have a URI?
... He said pbly not until it gets online

NM: I'm not saying it's obvious how to do this, but it would have real value if we did
... Consider working on an airplane, writing a document _and_ an email which points to the document, by its URI
... So that when I get online, I synchronize and the email ships
... The email should point to the document online
... This is (close to) what Lotus Notes has done for years
... This may be too hard, at least in some cases, but it _is_ an architectural desideratum

AM: How can you have the same URI -- you're not on the Web when you are on the airplane

NM: Yes I am -- the Web is not a set of servers, it's an information space
... I suspect if follows that the apps do the work, not the underlying storage mechanism
... 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

AM: So, is all we can say application-specific architectures will exist, or can we say something overarching?

NM: Well, at least Good Practices, as above, and _maybe_ design patterns and even maybe APIs to support them?

<noah> s/do the work/do any necessary synchronization/

TBL: LOD API work relevant?

AM: Maybe

<Ashok> s/LOD/LDP/

<noah> 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.

TBL: Apps use a triple-based API, which is grounded in a generic store

<noah> 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.

<noah> NM: Of course, we need to be sure that what we recommend is deployable in practice, and that it meets the intended needs.

TBL: Interaction between API and store is "fetch/store the entire store" or "delta"
... That's where sync has to happend

s/happend/happen/

TBL: So this is a generic approach to sync

NM: So, where do we go with this?
... We've seen AM's proposal, my alternative, and TBL's LDP example
... Not sure whether LDP is a third proposal

AM: I think the LDP story goes way beyond NM's approach

NM: So what story are we trying to tell?

<Zakim> ht, you wanted to ask if we have a client

NM: Not as such -- people are building stores, but no-one has asked for our advice

JAR: I prefer RB's "Goal is to try to anticipate pitfalls and raise awareness" better than the existing product page's goal

HST: [above] Is anybody asking for this? Is anybody listening?

NM: Yes, if you mean high-level pitfalls, i.e. we are the T _A_ G

RB: I _have_ these problems today, and don't know where to look for help

NM: As long as we don't try to roll our own

TBL: Pointing to existing solution spaces

JAR: Commissioning ourselves to do a report on the problem

NM: CouchDB guys said they were building on some of the Lotus Notes work, e.g. tombstones

<darobin> http://couchdb.apache.org/

RB: CouchDB is simple, you put JScripts docs in, nothing is deleted, you access with Map-Reduce

<noah> CouchDB Overview: http://couchdb.apache.org/docs/overview.html

AM: What can we say generally?

<dom> [I'm not sure the TAG documenting Web apps sync will reach the right audience (presumably Web developers?)]

<darobin> s/JScripts/JSON/

HST: I think this is a Vietnam, we should walk away

NM: Straw poll:

. . . Nothing: 3+
. . . Work towards a uniform API, maybe including sync, per AM/Product page: 0?
. . . Patterns/pitfalls: 5

NM: If we tried to do PaPi (per RB), volunteers?

RB: I'll review and advise

LM: As before

AM: Yes, I'll try

NM: I'll review
... So, clean up the Product page and get started on the work

<masinter> the product page is meta, not worth spending much time on when we can work on the document

<noah> ACTION-647?

<trackbot> ACTION-647 -- Ashok Malhotra to draft product page on client-side storage focusing on specific goals and success criteria -- due 2012-03-06 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/647

<masinter> are we commisioning a study or just a survey

LM: If we find a survey then this can be simple -- we just distill and point

<masinter> telling people where the cliffs are that they might fall off, we don't have to build the guard rails

HST: I was worried that if JAR's summary, that we need to do the survey ourselves, then this is too big a task

<masinter> the product page is just there to tell people the general area where we're working, don't deep end on it

<darobin> .ACTION: Robin to draft scope and goals for the Patterns/Pitfalls work in local/remote storage synch

<noah> ACTION-572?

<trackbot> ACTION-572 -- Yves Lafon to look at appcache in HTML5 -- due 2012-03-06 -- CLOSED

<trackbot> http://www.w3.org/2001/tag/group/track/actions/572

NM: Adjourned until 1600, then DHM on threats and opportunities on the Mobile Web

<masinter> http://tools.ietf.org/html/draft-ietf-iri-comparison-01 should update 3986

<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/112

<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/114

<masinter> at IRI meeting last week we resolved to look at http://tools.ietf.org/wg/precis/

<jrees> on break, TimBL, Larry, JAR about whether web spec level can be separated from application level and/or social good level (?)

[Resuming at 1608]

<jrees> maybe s/level/scope/?

<masinter> conformance vs. social expectation

<masinter> conformance doesn't require you to do things that the social expectation for normal use of the web might require you to do

<masinter> 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

NM: Mobile issues, then Admin

DHM: Two main points
... Disruptive impact coming from Web being on some many different platform, but that you can build cross-/multi-platform applications
... E.g. using web app on phone so that tilting phone reorients image on a different device
... "Hyper-devices": the Web enables new use of our devices

NM: Blue Spruce at IBM looked at cross-linked browsing experience

AM: WebX ?

<darobin> http://www.readwriteweb.com/archives/ibm_blue_spruce_first_look.php

AM: Not shared desktop, but ???

<dom> http://www.w3.org/QA/2011/11/from_hypertext_to_hyperdevices.html

<jrees> dom, link to blog post please?

NM: Linkage at the level of DOM

<Ashok> s/WebX/WebEx/

<noah> Project Blue Spruce may be of interest: http://www-01.ibm.com/software/ebusiness/jstart/bluespruce/

DHM: Not sure about the architectural impact, but thought worth mentioning
... Other area is WebRTC
... Real-time peer-to-peer communication
... File-sharing as a side-effect
... WebRTC is essentially Skype within the browser
... Audio-Video comms within the browser is the driving app
... Two parts: Access to the camera, mike and audio out; peer-to-peer connection
... There is a requirement for a mediation server, but there is work at eliminating it
... There's a JScript API, plus a UDP-based protocol defined at IETF
... Two phases, establishing the connection and then actually trading data

<darobin> s/JScript/Javascript/

DHM: RTCWeb is name for IETF protocol, WebRTC is the W3C API

NM: Patent problems?

DHM: Pretty confident at IETF this stuff is safe
... But the codec issue is still live, as it must be common between the two peers
... Some vendors don't want MPEG4 to be allowed

LM: How far along is codec and transport

s/transport/transport?/

DHM: Last week at IETF Paris chairs put pressure on getting to consensus

JAR: Doesn't this raise the possibility of peer-to-peer HTTP?

DHM: Yes in principle, but not in practise yet, but that's one of the potential disruptive impacts that's coming

<masinter> http://tools.ietf.org/wg/rtcweb/

TBL: I've always been interested in p2p for HTTP as a tool against censorship

DHM: At the moment the peers have to access essentially the same Web page to initiate the connection

<masinter> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00

<masinter> The Web Real-Time Communication (WebRTC) working group is charged to

<masinter> provide protocol support for direct interactive rich communication

<masinter> using audio, video, and data between two peers' web-browsers. This

<masinter> document describes the non-media data transport aspects of the WebRTC

<masinter> framework. It provides an architectural overview of how the Stream

<masinter> Control Transmission Protocol (SCTP) is used in the WebRTC context as

<masinter> a generic transport service allowing Web Browser to exchange generic

<masinter> data from peer to peer.

<masinter> note that SCTP vs. SPDY was a hot discussion at IETF

TBL: Jonathan ?? at the Berkman Center at Harvard has a project mirror as you link to develop data sharing on the Web

<jrees> Zittrain

NM: We haven't yet proven that this approach to p2p maps to the existing uses of e.g. bittorrent

JAR: I was surprised that these two were tied

TBL: Discovery is a big complex pblm
... E.g. use a distributed hash table of everyone who is looking for a connection

DHM: There is a whole stack here, with security and encryption and so on
... Just SSL isn't good enough, to avoid man-in-the-middle attacks at the connection initiation time
... Because we don't have universal crypto-secure personal identities
... One proposal is to use mutually-trusted shared identity providers, such as Facebook, to reciprocally verify

<masinter> we talked earlier about using "owner(URI)" as an identity token

<dom> http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-01

AM: Isn't it easier to just encrypt the conversation

s/conversation/conversation?/

DHM: But we don't have a deployed PK system on the Web?

<masinter> http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

TBL: PK doesn't need PKI -- it can be much simpler

NM: Ray Ozzie did instant group-creation before he xxx, called Groove

<noah> s/he xxx/his company was bought by Microsoft/

JAR: PKI can be decoupled from the problem, and doesn't need the whole PKI as we understand it/

<noah> NM: Groove uses a peer exchange of public keys to establish identities, then allows collaboration groups to be created across organizations

<jrees> 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"

<masinter> presentation from last week's RTCWEB discussing keys management and rtcweb security

NM: Thanks to DHM!

Administration

RESOLUTION: Minutes of 8, 15, 22 March all approved as a fair record of the respective meetings

<noah> http://www.w3.org/2001/tag/tag-weekly#Admin

NM: Agreed in the past that we would meet 12-14 June
... in Cambridge

<masinter> does TAG have opinions about W3C process http://lists.w3.org/Archives/Public/www-archive/2012Mar/att-0007/AB_List_of_Concerns-20120306.htm ?

NM: Our end-of-summer f2f has yet to be scheduled
... I will have difficulty travelling in September or for TPAC in November
... Options include -- yet again in Cambridge, Septemberish

<JeniT> http://www.w3.org/2012/10/TPAC/

NM: Another alternative would be a weekend before/after TPAC
... althought that is in Europe again
... Our without me

s/Our/Or/

RB: Weekend OK but _not_ next to TPAC

NM: Net-net -- we will wait a while before trying to schedule the next f2f after June
... Adjourned until 0915

<noah> Never mind, we are not adjourned

XML Error Recovery

RB: At XML Prague a lot of discussion about future of XML, XML and JSON, etc.
... A panel on XML / HTML issues, chaired by Norm Walsh
... There was consensus of interest in a processing model for XML that would not halt and catch fire at first well-formedness error

JT: There would be reporting of any error recovery actions to e.g. Firebug and/or the console

RB: The advantage would be that users would not be punished for the errors of others

NM: The scoping to end-user browser scenarios is xxx

JT: Not exclusively
... 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
... Mark Logic has an error-recovery mode for loading into the DB
... As do some editors
... but all of that is idiosyncratic
... So the question was if we could have uniform and predictable error recovery
... across all three use cases

AB: [libxml pattern] -- same document twice gives same result

s/AB:/RB:/

RB: Primary use case is in trying to deploy XML to user-facing apps
... The fact that the halt-and-catch-fire experience blows that, so browsers have started silently correcting

JAR: But we know where silent error recovery leads -- it leads to HTML5 -- the moving target aspect is really bad

NM: We can address that by publishing a TAG finding to insist on no silent error recovery

JAR: Errors have to be ugly, to put pressure on fixing them

TBL: Designing the level of ugliness is important -- the console is too well hidden -- show the warning briefly
... and allowing it to be configured to persist, for instance

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
... This is not going to run at breakneck speed, but will work its way along

AM: Does Mark Logic have a patent in the area?

JT: They use the schema to help, I don't know about a patent

HST: There's prior art . . .

<Zakim> noah, you wanted to comment on Robin's proposal and to discuss why use cases matter and why standardization matters

NM: The stakes go up for automatic data import
... 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. . ,
... So starting with an existing algorithm w/o much inclination to change it makes me nervous

<masinter> quiet error recovery in popular browsers is more harmful than vendor prefix

<masinter> but we have this with MIME type sniffing too, which is a kind of quiet fixup

NM: The pervasiveness of consistent error recovery will change community expectations

<masinter> sniffing application/xhtml+xml => text/html is an automatic fixup

RB: For me user-facing software is the key case
... But browser deployment will leak, no matter what

<Zakim> jrees, you wanted to comment on noah's idea

<Zakim> timbl, you wanted to talk about feeeds

TBL: RDF allows XML buried in RDF, it would be good to allow XML in there [?]
... Feeds with XML in can cause real problems -- RSS readers must be super-tolerant -- but we keep seeing e.g. DOCTYPEs in tweets???

JAR: So you are heading for tolerance

RB: Not tolerance, they are still errors, with well-defined recovery strategies
... The HTML situation is horrible not because of tolerance, but because the recovery rules are so complicated because the recovery heritage is so complex

JAR: This will promote a race to the bottom

RB: Is that a problem, and if so why?

JAR: There will be no selective pressure
... Drift in the correction landscape will eventually lead to meaning change

LM: Sniffing itself has promoted this by the sniffing of application/xhtml+xml => text/html
... If the popular receivers are strict, then producers will check first

RB: Indeed, and sending the same doc to different browsers with different media types makes it worse

LM: The right place to put this is in Apache and IIS, so the data that goes out is fixed

TBL: And sends a message to root!
... Whenever you have a string with two different potential readings, you have a security hole

<jrees> correction is fine but *silent* (i.e. painless) correction is a big security risk

TBL: [complicated example with two recipients which scribe didn't get]

JT: We _are_ committed to non-silent recovery

RB: Exactly what that _means_ is up for discussion and implementation choice

HST: It's precisely those honest additions that make us worried . . .

<timbl> 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.

NM: Isn't this going to make the sniffing of text/plain as application/xml have dire consequences?

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
... The sniffing stuff is someone else's problem

LM: The sniffing doc't was originally in the HTML WG
... It was moved to the IETF ??? group
... Where some members raised doubts

s/???/Web Security/

LM: I'm not involved in the document
... It expired at the IETF
... The WebApps packaging draft makes normative reference to the expired draft
... The HTML5 draft has a normative reference to the expired draft
... One of the issues raised against the document was to never sniff to PDF, the original editor declined to make any change
... No examples have been forthcoming

RB: The opposite case does arise, that is, correctly labelled application/pdf docs being sniffed as something else, particularly short ones

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
... 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
... We should do something, particularly about the XML case

JAR: If the XML ER CG doesn't say anything about sniffing, the TAG will have to. . .

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"

<jrees> NM: Please reread authoritative metadata since it clearly talks about security holes

<jrees> NM: People know the arguments against sniffing, they just think *their* considerations are more important

[scribe notes that discussion continued past the end of scheduled meeting closure]

<timbl> Of course the semicolon-adding jacascript behaviour of js parsers is a possible security hole, bug etc too

RB: I'm really concerned that the sniffing spec is dead

LM: I tried to get that actioned w/o success

<jrees> 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

<darobin> 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 [recorded in http://www.w3.org/2012/04/03-tagmem-minutes.html#action03]

<trackbot> 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].

- DRAFT -

Technical Architecture Group Teleconference

03 Apr 2012

Attendees

Contents

Web Applications: Security and Web Applications Permissions

WebApps Storage

Administration

XML Error Recovery

Summary of Action Items

Scribe.perl diagnostic output