See also: IRC log
JAR: I know what Adam Barth is up to, SES people are up to
Noah: Robin and i exchanged email.
Noah:My previous experience was that web apps have been less successful than I had hoped. I got this music catalog though the post, with "ios rocks" in the music catalog -- an amazing list of ting s people are building with native apps. Like a mixing board with ipad dock and the software on the ipad. This needs a proprietary hardware connector for example. 6 channel streaming recorder, effects pedal, etc. so you need low-level access to things like DSPs
Robin: That is access to the core audio API.
Yves: Actually for audio you can do all the processing in JS: it is a question of latency why you need core audio.
<masinter> aspects of native: (a) performance (b) access to APIs (c) monetization (d) trust
<masinter> maybe (b) and (d) are related? vendors link (b) to (c) because platform vendors take percentage
<masinter> (a) performance = throughput but also latency
Noah: A risk of de-facto standardization around a particular connector
TimBL: An RDF client library has to be aware of 303s etc, so that it understands the right relationships between things. You must be able to write code which will work in trusted and untrsuted Apps, write once runanywhere. When running as a script (untrusted) rather than Firefox (say) extension (trusted code) it must be the same RDF library. In Extensio mode, it's omnipotent, otherwise in script mode it is very constrained. But the API must be bascially the same. If you violate the cross-site-scripting attack checks in a browser, at the moment, there is no error code, no error message, so it is really hard to invoke code conditional on and in adaptation the untrusted environement.
TimBL: When I tried this 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. And trusted apps are not a goal."
TimBL: 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
JAR: Seems analogous to Noah's point about access to the hardware port
Noah: Yes, except the port access stuff may be harder to make portable if the ports are proprietary and different
<masinter> air & phonegap (http://phonegap.com/) are examples of 'native app' development tools which allow writing apps as both webapps and native
TimBL: 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. The architecture which is emerging has only the two extremes.
JAR: Do you, Tim, agree that the middle ground is unlikely to worth working toward?
TimBL: 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?
jar: The question is, is there any middle ground between the completely trusted and untrusted app. Orthogonal question, can you design APIs which work in either situation? There are two general approaches on the table, from 50km view. One approach is origin case, origin(module) defines power of module, links to CORS design and Adam Barth's academic work. The other design is you get power by being passed it as a parameter. This is a 30 year old ACL vs Capability argument, we should not get into it now. People are polarized. In Tim's example, using XHR, you are saying 'here is the URL' and later getting a response callback, or your callback just doesn't happen in the bad case. In the origin case, you would use the origin of the module to decide whether to authorize the delivery of the error code to the XHR caller.
Robin: The origin is the one -- the HTML page -- which involved the js, not the actual URI the js was loaded from, which is irrelevant/not tracked
Robin: The js is not namespaced -- anything can put callbacks on anything, no boundaries.
jar: Javascript's kind of like Java -- The aim is "write once, run anywhere".
NM: Well, Java has a pretty elaborate class loader model that's pertinent to how Java code is loaded and gets privilege
jar: java security was a disaster -- based on call chain -- like the origin system
jar: in the capability method, you have a param you can pass which gives you the right to do things and you pass it to the library
... there is intense pressure to make js apps work and access things for which you need privs
Dominique Hazaël-Massieux joins the meeting
dom: a lot of the topics you have been discussing may be very relevant to what I will present
jar: personally, i find this the way to think about it -- it is a question of privs and to whom they are granted. There are more than two priv levels -- in fact there are many levels -- it might have access to the net but not the core audio for example. In fact there are questions of to what 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
Robin: many things to say
Robin: 1) w3c has sent out announcement 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
dom: The device API meting is open and discussed this
robin: When you design APIS which work inside the browser security model, the API looks very different from something done with full trust access. There is investigation of new work area for APIs specifically for completely trusted APIs
Robin: 2) even if we take the very simple binary on/off trust, there is some room for grey area.
Robin: The example for the XHR where you want to not give error messages
Robin: In firefox, you double-click the tab and it makes it an installed app.
tim: really?
Robin: Concept of installed apps. They don't have to have high-level apps, you can give them specific privs -- greater local storage, system notifications, getting error messages could be some
Robin: [Who said this? RB, tutti to check] Most of what I wanted to talk about can go into DOM's session
Robin: [Who said this? RB, tutti to check. JAR thinks Dom said this.] SES are not a solution to the trust issue
jar: you mean security
Robin: They intermesh -- SES allows you to bring in 3rd parties which operate inside a limited space without access to each other
Robin: [Who said this? RB, tutti to check. JAR guesses Dom] All policy based systems which don't plug the XSS hole are really threatened by that hole
jar: SES doesn't give you a notion of what things [principals] have what authority in running code - you have to say, (like in Powerbox etc. and ongoing work) how you [? collect the query - (missed)]
TimBL: 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. So, it's not just trusted and untrusted apps in the browser, includes things like node.js on the command line and server side.
<darobin> http://www.phantomjs.org/ -> PhantomJS, run a browser on the command line
<darobin> https://github.com/tmpvar/jsdom -> JSDOM, emulation of a browser environment in NodeJS
TimBL: Also... when you download software modukles from different people and representing different people, we'll need the concepts of agents running on behalf of completely different entities. We will have to surface remote entities as first class principals withing the system. Like having Adobe have an account of my system with the privilege to update its own apps.
TimBL: 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. I think the origin represents this legal entity in an obviously broken way. Maybe some Un*x systems will go some way toward associating origins with such points in the filesystem trees.
jar: I think you have to specify the granularity of the grant of authority -- is it object, function, program, etc
ashok: how can I as a user give this authority to an app?
robin: unsolved problem.
... Policy of a rathole to fall into. [? RB to
check]
jar: what about Powerbox?
robin: later
... My personal take e [? RB to
check] is a hard-to-get-through process you can't do by mistake.
dom: at the moment you can buy stuff on the web no review
Noah: We are out of time.
<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
Noah: Note the change in order from the published agenda, this brought forward from 10:00 today
<dom> http://www.w3.org/2012/Talks/dhm-tag/
Dom: [ presents a talk of 16 slides]
Larry: Isn't monetization also a driver for native apps?
dom: Phonegap is addressing that, but I don't thing it is the biggest driver
... We also are looking at payment in the W3C headlights process
... [edits slide 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/
jar: For privacy with camera, how about confinement?
dom: basically impossible
jar: confinement being limiting the ability of the app to send any data back home
dom: Interesting to explore this approach though
... [slide 6]
robin: recommend panopticlick (http://panopticlick.eff.org/)
anon1: [identity suppressed for privacy reasons] I see [from Panopticlick]:
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.
[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
_______
Robin: this is how web intents basically works. You have a service page which defines an action, like Pick. Picking a set of contacts from the addressbook for say sending an email. The service definition declares what it can do, pick a set of contacts. Then the user agent registers this service, modulo user input (?TBD (chrome people think it can be registered without UI)) RB to check
Robin: You then have a client page. Suppose you have a game -- you don't give the game full access to the entire addressbook. You just want access to it to be given to a set of people. The client page says "Start activity... pick contacts" and includes a button which the user must press on. This pops up a dialog to chose which service. Then it instantiates the service page on the side [in an iframe?] and you pick your contacts, and the contacts are returned to the original page. RB to check
jenit: Who defines which fields are actually transferred?
robin: The service page just gives a URI identifying the action, and one identifying the "type" which is a random semantic-free parameter used just as a filter
______ [break] _____
Dom: Right now, policy considerations are all at the browser level -- ability to access a website is granted indefinitely
Ashok: You asked about geolocation -- that uses policy?
dom: In a browser-dependent way - it all depends on whether user has granted it many times, etc.
... this is all left to the browser
Ashok: Not to the user?
Dom: For geolocation...
Ashok: Can you as a user author a policy?
dom: you can revoke access for a given website. There is no UI for it, there is no policy API in the web browser. In device APIs, we really did explore that space quite a lot. They could see the long term value but ...
dom: Some talk about having a generic application-wide policy, like CIA want to prevent location ever being available
dom: [slide 9/16]
Robin: The ideal is for the user to make an informed decision without thinking 0.5 ;-)
jar: what info is not sensitive?
larry: sometimes a problem is one person giving away info sensitive another person. Like mentioning their name and email in the same sentence.
larry: [Who said this? LM, tutti to check] We can't just restrict heis [?] talk of privacy to a user's own information
larry: When geopriv talked about privacy policy, they ended up with a API extension which insisted on passing a policy and a timeout with every API call
dom: I am not saying this is the solution, I am just pointing out what is out there
larry: Consent, opt in and opt out .. we should look hard at the assumption that assent helps.
ht: I am personally in the "always run virus check" mode for anything I install, as I had a terrible experience with a bad download once.
ht: there is nothing comparable on my phone which allows me to look at any web app, look at the Javascript, and figure out whether it is a bad one.
<jrees> http://www.veracode.com/ ???
Noah: Different - viruses you just look for signature of particular hacks, on js in general, you can't just look at the code
tim: Codepath tracing is getting pretty sophisticated, and maybe in the future you might be able to
robin: There is a crowd-sourced database of known bad web apps
timbl: Some kind of "Nutrition Facts" for what apps do for you would be a great addition to the add-on store, as it would remove the "after that a free-for-all" problem.
Noah: Different users might care about different things
robin: The android UI is generally regarded as horrible
<darobin> http://i.imgur.com/JWEII.jpg -> screenshot of the Android permissions dialog
tim: Maybe with some rethinking it could be better, particularly if it makes promises about what the app will do rather than talk about the low-level access the app is allowed.
larry: We don't have a vocabulary for trust. I would like to see use cases; we have stories that we should collect together, then analyse them.
tim: We've been doing that within MIT for 10 years. Anyone who tries to make an algebra of trust is making a big mistake. They don't match the real world. Trust systems have to connect to the real world, and therefore has to be a semweb application. I want to be able to say that my coworkers can access something, that the DIG blog could be commented on by friends of friends or who had attended a particular conference. I don't want to have a Google Circle to drag them into. You have to connect trust to reality, which is what the semantic web does.
<masinter> http://masinter.blogspot.com/2011/08/internet-privacy-telling-friend-may.html
larry: I was complaining about the word 'owner' to talk about meaning, because we don't have a good notion of identity. In order to talk about trust, you have to have a model of identity. If there's a problem defining the owner of a URI, or the namespace of individuals, perhaps we create a namespace of identity by projecting owners. You provide identity by saying which URIs they control.
Larry: maybe we could identify principals by the URI [domain names, email ids etc] they control
timbl: That's OpenID. It identifies you as the person who has write access to a given page.
robin: and BrowserID identifies you through an email address
timbl: and WebID does the same thing [URI you control]
<masinter> I wonder what is the identity of "browser vendors": product safety evaluations
Larry: This is like product safety. Cars that you can drive off a cliff aren't unsafe. There's an assumption that asking permission where people understand the permission is better than one where the permission isn't clear. Perhaps these are like product safety ratings. Are we looking for PICS extended to apps, as we talk about rating and validating?
robin: That could be done in the ecosystem, but not at this level
larry: The stuff about what apps gets into the app store
robin: If you have a policy-based system; that's the question we have to ask first
dom: Out-of-band curation is one possible approach. I think we'll see multiple approaches. There isn't a shared understanding within the WGs about what will work for the Web
robin: Or what the stories are, what the problem spaces are, what the terminology is
larry: The stuff about origin is also a matter of trust. A matter of brand. I trust my bank, and things I download from my bank. Brands give you trust
dom: I agree that origin is related to brand
larry: There's something about PICS we don't want to repeat, as it didn't succeed. But we can't avoid it by just saying we're not going there
dom: I don't think any of us know where exactly we're going. I think the TAG, as involved with ,cross-group, cross-technology issues should be helping: To identify terminology, to identify experts
larry: I'm trying to map out the space: brand, trust, rating, authority. Finding others who have mapped out the space, and adopt the framework
noah: We've often said that the TAG should work in this space, but not found someone to do it
robin: I would like to do this work. The first step, which might lead to further work . . . would be to agree on some terminology. Which is currently chaotic. It would be very helpful for cross-group understanding
noah: Who else would we have to involve?
robin: From B2G project, from the Trident project
noah: Could we do that without starting a Community Group?
robin: maybe a TF?. I'd avoid a CG because it can be hard for members to join. I'd prefer a TF, separate from www-tag
ashok: A Finding on this would be wonderful. Terminology, mapping the landscape, use cases
noah: We have to work out the initial scope
ashok: I would go beyond terminology, to use cases and landscape
robin: Terminology alone won't cut it. first success would be to get the right people talking together. include people from Privacy IG
noah: What other deliverables?
jar: The use case list and terminology mesh very nicely
robin: I'm happy to do that, and I can get funding to do it
noah: Does anyone object to this?
JeniT: how does the privacy draft fit into this?
robin: I will need to think about whether it should be a product of the TF
noah: From TAG logistics, is it one or two things to track?
timbl: We could bank what we have, publish it as a Note. get it out there
noah: There's a dated editor's draft available. To publish it as a Note, we'd need more sessions
timbl: We should produce something sooner rather than later
noah: We were reviewing as first draft yesterday
robin: I have a bunch of updates to make on it. I'll do another draft, and let's see what people think of it then
larry: I'd be happy publishing it to say "this is our initial work on this topic, which we will take forward". My objections were about taking it forward as a longer-term effort. In terms of RFC categories, it's not April Fools and it's not Standards Track. Publishing things early is good as long as the status is clear
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/2001/tag/2012/04/03-minutes.html#action01]
<trackbot> Created ACTION-684 - Update Privacy by Design in APIs [on Robin Berjon - due 2012-04-10].
ashok: How does this relate to the bigger Finding we talked about?
noah: Robin should scope that larger thing, I think we should leave it to him. Draft a product page
jar: Limited scope for Note as written. I don't see the relationship with the other
larry: I think this is more about an architecture around security and permissions
<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
<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/2001/tag/2012/04/03-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
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
<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 had been changed significantly to be consistent with a non-document view of the web which it had not started with.
<timbl> over lunch
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
<masinter> http://trac.tools.ietf.org/wg/iri/trac/ticket/112
http://www.w3.org/2001/tag/doc/Seamless%20Applications.pdf
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)
<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: [takes us through the product page]
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
AM: Not talking about that
... 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
NM: does this require distributed 2-phase commit
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 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
HST: I've had this problem: you have a storage problem and an interoperability problem. You don't know what provision the different Web platforms have. I had to write different shims for the different storage facilities across the different browsers: cookies, Google Gears or whatever. 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 models
NM: Right, that's just a matter of API 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
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 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 requires you to 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 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
<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?
<noah> 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.
Tutti: discussion of various source control systems' approach to related problems
JAR: I agree with NM that there is a huge background wrt sync -- is that what we want to work on?
AM: Is it important for us to be able to write "seamless apps", and support others who want to do so
RB: We are seeing a collection of offline stores being deployed, can we get in now to help exploit them responsibility
NM: 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.
AM: I asked Raman about this, wrt using GMail offline -- does the message have a URI?
... He said probably 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 any necessary synchronization, 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?
TBL: LDP API work relevant?
AM: Maybe
NM: 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. I don't think the TAG should spec the exact sync protocol or shared facilities. We should make statements about how URIs are used. Of course, we need to be sure that what we recommend is deployable in practice, and that it meets the intended needs.
TBL: LDP apps use a triple-based API, which is grounded in a generic store
TBL: Interaction between API and store is "fetch/store the entire store" or "delta"
... That's where sync has to happen
... So this would enable 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?
HST: Do we have a client? Is anybody asking for this? Is anybody listening?
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
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/
<noah> CouchDB Overview: http://couchdb.apache.org/docs/overview.html
RB: CouchDB is simple, you put JSON docs in, nothing is deleted, you access with Map-Reduce
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?)]
HST: I think this is a Vietnam, we should walk away
NM: Straw poll:
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 commissioning a study or just a survey
LM: If we find a survey then this can be simple -- we just distil 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 is the case, 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
<HST> This was not done here, but was done subsequently (telcon of 2012-04-12 and is ACTION-693
<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 should be separated from application level and/or social good level (?)
<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
[Resuming at 1608]
NM: Mobile issues, then Admin
DHM: Two main points
... Disruptive impact coming from Web being on some many different platforms, 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
<jrees> dom, link to blog post please?
<dom> http://www.w3.org/QA/2011/11/from_hypertext_to_hyperdevices.html
NM: Blue Spruce at IBM looked at cross-linked browsing experience
<noah> Project Blue Spruce may be of interest: http://www-01.ibm.com/software/ebusiness/jstart/bluespruce/
<darobin> http://www.readwriteweb.com/archives/ibm_blue_spruce_first_look.php
AM: WebEx ?
NM: Bluespruce is not shared desktop, but rather a coordinated browsing experience in which DOM changes are hooked, and broadcast to all participants.
NM: Linkage at the level of DOM
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 Javascript API defined at W3C, plus a UDP-based protocol defined at IETF
... Two phases, establishing the connection and then actually trading data
... RTCWeb is name for IETF protocol, WebRTC is the W3C API
<masinter> http://tools.ietf.org/wg/rtcweb/
<masinter> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00
<masinter> The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document describes the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing Web Browser to exchange generic data from peer to peer.
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?
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
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> note that SCTP vs. SPDY was a hot discussion at IETF
TBL: Jonathan Zittrain at the Berkman Center at Harvard has a project "Mirror as you link" to develop data sharing on the Web
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 problem
... 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
<dom> http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-01
<masinter> we talked earlier about using "owner(URI)" as an identity token
<masinter> http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
<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
AM: Isn't it easier to just encrypt the conversation?
DHM: But we don't have a deployed PK system on the Web
TBL: PK doesn't need PKI -- it can be much simpler
NM: Ray Ozzie did instant group-creation before his company was bought by Microsoft, called Groove
JAR: PKI can be decoupled from the problem, and p2p 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
NM: Thanks to DHM!
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
... although that is in Europe again
... Or without me
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
RB: At XML Prague March 2012 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 seems too limiting. There are other important uses of XML, and the same XML that goes to a browser sometimes needs to be processed in other ways. Some of the recovery that's safe when presenting info to a user is dangerous if the resulting data is to be trusted as untainted in a database.
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
RB: [libxml pattern] -- same document twice gives same result
... 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, but we have this with MIME type sniffing too, which is a kind of quiet fixup
<masinter> sniffing application/xhtml+xml => text/html is an automatic fixup
NM: The pervasiveness of consistent error recovery will change community expectations
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
TBL: RDF allows XML buried in RDF, it would be good to allow XML
ER 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??? TBL to
correct/fill in please
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: Simple security attack example for different parsers doing different things: Tim puts up a page which he knows Larry's browser and Ashok's browser will see differently, asks Larry to OK it to Ashok, and then Ashok transfers money to Tim, as he sees a different message.
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 to your assurances that make us worried . . .
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 document was originally in the HTML WG
... It was moved to the IETF Web Security group
... Where some members raised doubts
... 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"
NM: Please reread authoritative metadata since it clearly talks about security holes
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 Javascript 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/2001/tag/2012/04/03-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].
<darobin> mmm, so long as automatic semicolon insertion is well-defined (and it is) I think it's security-safe
<darobin> whether it's good programming style is another issue, of course
<jrees> no.
<jrees> speciation in xml would be bad
<scribe> 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. [recorded in http://www.w3.org/2001/tag/2012/04/03-minutes.html#action04]
<trackbot> 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].
ACTION-687 due 2012-04-04
<trackbot> 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
<darobin> 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 ;-)
