IRC log of bpwg on 2008-09-26

Timestamps are in UTC.

12:36:54 [RRSAgent]
RRSAgent has joined #bpwg
12:36:54 [RRSAgent]
logging to http://www.w3.org/2008/09/26-bpwg-irc
12:36:56 [trackbot]
RRSAgent, make logs public
12:36:56 [Zakim]
Zakim has joined #bpwg
12:36:58 [trackbot]
Zakim, this will be BPWG
12:36:58 [Zakim]
ok, trackbot; I see MWI_BPWG()8:30AM scheduled to start 6 minutes ago
12:36:59 [trackbot]
Meeting: Mobile Web Best Practices Working Group Teleconference
12:36:59 [trackbot]
Date: 26 September 2008
12:37:36 [DKA]
zakim, what is the code?
12:37:36 [Zakim]
the conference code is 2794 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), DKA
12:37:47 [jo]
jo has joined #bpwg
12:38:02 [jo]
rrsagent, draft minutes
12:38:02 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo
12:38:14 [Zakim]
MWI_BPWG()8:30AM has now started
12:38:21 [Zakim]
+aconnors
12:38:37 [DKA]
Hia
12:38:53 [jo]
Meeting: MWABP Editors Meeting
12:39:17 [jo]
Chair: Adam
12:39:32 [jo]
Present: DKA, Adam, Jo
12:55:16 [DKA]
[discussion of scope of BP2]
12:56:45 [DKA]
Scibe: Dan
12:56:51 [DKA]
ScribeNick: DKA
12:57:04 [jo]
jo has joined #bpwg
12:58:59 [jo]
rrsagent, draft minutes
12:58:59 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo
13:04:57 [DKA]
Topic: Bryan's comments
13:16:31 [Zakim]
+Bryan_Sullivan
13:16:37 [DKA]
Jo: Suggest removing first paragraph f 4.2.1.2 (regarding SSO providers) as there is not enough current practice.
13:17:17 [Bryan]
Bryan has joined #bpwg
13:18:09 [DKA]
Adam: In discussion with group we weren't sure if we could recommend a secure hash as a form of security.
13:18:55 [DKA]
Jo: Something else we could do - point about not using https needlessly is a good point. We should call that out as a new BP under "optimization."
13:21:50 [DKA]
Jo: We should bounce this to the web security context working group.
13:22:11 [DKA]
Bryan: What's the concern about recommending we use a secure hash for URL parameters?
13:22:53 [DKA]
Jo: Just want to make sure we get the feedback from the WSCWG.
13:23:53 [DKA]
ACTION: Bryan to write a note to WSCWG asking for comment on using secure hashes for securing URL parameters.
13:23:53 [trackbot]
Created ACTION-852 - Write a note to WSCWG asking for comment on using secure hashes for securing URL parameters. [on Bryan Sullivan - due 2008-10-03].
13:24:36 [jo]
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080521
13:26:19 [DKA]
Bryan: there are different mechanisms for security - beyond use of SSL.
13:27:24 [DKA]
Adam: Makes sense to say "on mobiles, where https is expensive, match the level of security appropriate to the security of the data." We should give people guidance on which kinds of information are more / less secure.
13:27:43 [DKA]
Bryan: We need to give them the reliable technique pointers and let them decide the context.
13:28:30 [DKA]
DKA: "Sentitive" information is different in different regions... SO we can't give accurate guidance...
13:29:01 [DKA]
Adam: If you can't give concrete advice you have to give a menu of options and say "you choose" which isn't always helpful.
13:30:55 [jo]
ISSUE-275: Bryan is writing to the WSC WG to request their input on acceptable alternatives to using https
13:30:55 [trackbot]
ISSUE-275 4.2.1 Protect Personal Information notes added
13:31:33 [jo]
ISSUE-276?
13:31:33 [trackbot]
ISSUE-276 -- 3.1.1 Retain Personalization Information -- RAISED
13:31:33 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/276
13:33:59 [DKA]
Bryan: It seems like this has been narrowed down to only a description of cookies as retaining information. There are other valuable techniques. Also we've told people not to rely on cookies [in BP1]. SO we need to give some other techniques.
13:34:37 [DKA]
Adam: I start with the assumption we're talking about retaining information cross session. So your options are cookies or pushing it back to server-end database.
13:36:25 [DKA]
DKA: We could also talk about using HTML5 / Gears data persistence if it does exist.
13:37:12 [DKA]
Jo: Discussion of limitations of using cookies is useful.
13:38:08 [DKA]
Jo: We need to distinguish intra-session persistence of data and inter-session persistence of data.
13:38:45 [DKA]
Adam: Yes - if we're talking about inter-session then javascript variables, url paramaters and forms are not applicable.
13:39:15 [DKA]
Bryan: I could be in a session for quite some time...
13:41:39 [DKA]
Jo: We need to tease apart some of the usecases a bit more. Different views generated autonomously by the user agent [flipping between pages with no exchange with the server], interaction with the server within a [fuzzy] session, interaction across a number of sessions.
13:42:27 [DKA]
Adam: We need to split out the client-side interactions from the server interactions. There are techniques for retaining state between sessions vs. across sessions.
13:42:59 [DKA]
Bryan: I think it would be useful to talk about techniques used across sessions. Any cookies that has a defined expiration date is a persistent cookie, not a session cookie.
13:43:14 [jo]
jo has joined #bpwg
13:43:41 [DKA]
Adam: In a session, all the examples cited are applicable. Across sessions, I can think of cookies, html cache, and local storage.
13:44:12 [DKA]
Bryan: And persistent storage techniques.
13:46:01 [DKA]
DKA: We can roll that all up in discussion of client side persistent storage.
13:46:22 [DKA]
Adam: "Client side persistent storage, for example HTML persistence and other vendor initiatives as available."
13:47:04 [DKA]
Adam: An app / widget / webapp can sit in the background and retain its state. We need to change "the next time the user visits the site."
13:47:38 [DKA]
Jo: [document] very often says "user visits site" and what we really mean is "invocation of the application."
13:50:48 [DKA]
DKA: Some issues in how mobile device browsers [ eg iPhone browser ] actually don't keep persistence in background and don't keep javascript running when browser (or "window") is put into the background.
13:51:23 [jo]
zakim, who is here
13:51:23 [Zakim]
jo, you need to end that query with '?'
13:51:33 [jo]
zakim, who is here?
13:51:33 [Zakim]
On the phone I see aconnors, Bryan_Sullivan
13:51:34 [Zakim]
On IRC I see jo, Bryan, Zakim, RRSAgent, DKA, matt, dom, trackbot
13:52:48 [jo]
scribe: Jo
13:53:13 [jo]
bryan: visits site means in the course of a session
13:53:32 [jo]
adam: need to pin down the inter and intra session notions
13:54:00 [jo]
[discussion of which techniques are most applicable to which use cases]
13:54:10 [jo]
scribe: dka
13:55:42 [DKA]
Jo: Point is: do not make people enter data more than once, ever.
13:57:00 [DKA]
Bryan: it's useful to state limitations.
13:59:03 [DKA]
Jo: can we say something about server side session frameworks?
13:59:15 [DKA]
Adam: to my mind that's not in scope -
14:00:27 [DKA]
DKA: We'd have to include recommendations for perl, php, iis, apache, etc...
14:00:32 [DKA]
Jo: OK.
14:01:02 [DKA]
ACTION: Adam to re-write 3.1.1 along the lines discussed today.
14:01:02 [trackbot]
Created ACTION-853 - Re-write 3.1.1 along the lines discussed today. [on Adam Connors - due 2008-10-03].
14:01:47 [jo]
ISSUE-276: Adam will re-write the relevant section calling out the different techniques available intra and inter session per ACTION-853
14:01:47 [trackbot]
ISSUE-276 3.1.1 Retain Personalization Information notes added
14:03:07 [DKA]
All praise to Dom for his wonderful tracking tools without which we would be but maggots, groveling in the mud and slime.
14:03:19 [jo]
not to mention the foetid swaps
14:07:26 [jo]
ISSUE-277?
14:07:26 [trackbot]
ISSUE-277 -- 3.3.1 Inform user about automatic network access and provide control -- RAISED
14:07:26 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/277
14:09:17 [DKA]
Adam: in the previous version, there was a BP about provide disclosures [covering access to network]. That went away as a BP and the recommendations were absorbed into other BPs - maybe we lost some use cases in the process.
14:10:52 [DKA]
Adam: I can't imagine where this information is imparted in a [web] application.
14:12:49 [DKA]
DKA: Shouldn't we leave this to the platform?
14:13:04 [DKA]
Bryan: Visual cues are only useful if you're looking at the device.
14:13:41 [DKA]
Bryan: When I'm not looking at the device - when the app is running in the background (e.g. a widget).
14:14:27 [DKA]
DKA: Shouldn't this be kicked back to another body such as OMTP?
14:14:49 [DKA]
Bryan: the W3C webapps group is working on a manifest related to the widget package - there's a description field there.
14:16:38 [DKA]
Jo: I think if we merged the new 3.3.1.2 ("how to do it" for "inform the user about network access...") with the bulleted list from the old BP - add a bullet about "how to control this behavior."
14:17:55 [DKA]
Adam: The thing that's important to me - that these bullets come in the context of "associated help pages, on first visit, on login (etc...)" - that this doesn't have to be done inline in the application. Because it could lead you to do something really bad in terms of usability.
14:18:49 [DKA]
Bryan: that's OK.
14:19:33 [DKA]
DKA: "Great."
14:20:46 [DKA]
Adam: We need to be mindful of negative effect of usability.
14:22:18 [DKA]
Jo: text can be amended to say "provide this information in a non-intrusive way."
14:24:19 [DKA]
Jo: I think under "means should be provided" to disable any automated network activity. That should be elevated to a best practice. Or more needs to be said about that.
14:24:51 [DKA]
Jo: Also, in a lot of places in the document it would be better to use the imperative and active voice.
14:27:13 [jo]
ISSUE-277: Adam is going to elaborate with a discussion of what network access parameters should be disclosed and is going to elaborate on the provide control aspect as a separate BP
14:27:13 [trackbot]
ISSUE-277 3.3.1 Inform user about automatic network access and provide control notes added
14:27:35 [jo]
Open ISSUE-277
14:27:41 [DKA]
ISSUE-278?
14:27:41 [trackbot]
ISSUE-278 -- 3.3.2 Inform user about use of PIM information -- RAISED
14:27:41 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/278
14:28:32 [DKA]
Adam: Same issue but on the PIM information.
14:29:04 [DKA]
Adam: you wouldn't want in-application alerts when you're going to access PIM data when there's most-likely going to be a native alert.
14:29:53 [DKA]
Bryan: issue of "what should you disclose"
14:35:45 [jo]
scribe: Jo
14:36:31 [jo]
adam: what you just said clarifies the context - reading the BP on its own was less clear
14:37:33 [jo]
bryan: users can also be prompted for personal information, or it can also be got through the device. User needs to know what it is being used for irrespective of how the application gains it
14:38:23 [jo]
adam: if it is not about the pim api I am not sure how mobile-relevant this is, I think this is in the realm of policy statements
14:39:57 [jo]
dka: it would be GREAT if all webapps were to have the same form of disclaimer so the user could be given a choice as to whether to allow it or not, but this is going to be different on a per app and per location - e.g. IK code of practice which prescribes exactly how to do it there, but would be different in Japan or Saudio Arabia
14:40:46 [jo]
dka: so I support adam ins aying we should descope this, as unless we have something specific to say it all gets a bit fuzzy
14:41:16 [jo]
bryan: doesn't mean we can't give guidance just because we don't know the cultural or legal context
14:41:58 [jo]
bryan: tell the user what you are going to use and how you are going to use it
14:42:46 [jo]
jo: not sure how this is different from saying "treat it like the previous issue"
14:42:48 [jo]
adam: in summary taking the two old bullets and inserting them into the new section is basically what we need to do
14:43:13 [jo]
ISSUE-278: Adam is going to merge the two old bullets into the new section
14:43:13 [trackbot]
ISSUE-278 3.3.2 Inform user about use of PIM information notes added
14:43:30 [jo]
ISSUE-278: OPEN
14:43:30 [trackbot]
ISSUE-278 3.3.2 Inform user about use of PIM information notes added
14:54:58 [DKA]
ISSUE-279?
14:54:59 [trackbot]
ISSUE-279 -- 4.3.3 Provide Disclosures that are Timely and Accessible -- RAISED
14:54:59 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/279
14:56:45 [DKA]
Adam: This was deleted - it was just saying "disclosures are only useful if they're useful" - also this has been absorbed into previous BPs.
14:56:50 [DKA]
Scribe: Dan
14:56:58 [DKA]
ScribeNick: DKA
14:57:13 [DKA]
Bryan: This talks about your options...
14:58:41 [DKA]
Adam: Maybe we pull it out of 3.3.1 and make it a separate BP and then refer to it from 3.3.1?
14:58:52 [DKA]
Jo: What's the existing problem we're trying to solve?
14:59:09 [DKA]
Bryan: People don't know they're supposed to do it and also they don't know how to do it.
15:00:30 [DKA]
Jo: It could be turned around into a "what not to do" - say "don't do it this way..."
15:01:45 [jo]
ISSUE-279: Adam is going to re introduce a BP pulling out the commonalities between the PIM one and the network access one
15:01:46 [trackbot]
ISSUE-279 4.3.3 Provide Disclosures that are Timely and Accessible notes added
15:02:48 [DKA]
ISSUE-280?
15:02:48 [trackbot]
ISSUE-280 -- 3.3 User awareness and control -- RAISED
15:02:48 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/issues/280
15:04:52 [DKA]
Jo: This does fall under "provide control over network access."
15:05:37 [DKA]
Adam: Comments on specific bullets.
15:07:42 [DKA]
Bryan: Suggesting a modification - insert text "for example, here are some things to do which may be applicable to your application" to make it clear that these are examples.
15:09:02 [DKA]
Adam: if it's appropriate and you want to provide a deep level of control you can do this but if you don't want to provide a deep level of control you should at a a minimum provide the ability to turn it off.
15:09:43 [DKA]
Bryan: Until we have this ability by the platform to allow the user to set policy for different behaviors the app should allow the user to do it.
15:11:18 [DKA]
ISSUE-280: Adam to pull out the control aspects of this and send them in email to the list so we can work on a chunk of text that makes sense.
15:11:18 [trackbot]
ISSUE-280 3.3 User awareness and control notes added
15:11:56 [DKA]
Bryan: wrt our input to the webapps, and the way we can deal with those comments through bp2.
15:12:01 [jo]
ISSUE-280: Adam is going to add the bullets here to the BP on user control noted earlier
15:12:01 [trackbot]
ISSUE-280 3.3 User awareness and control notes added
15:13:15 [DKA]
Bryan: [introducing http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html]
15:16:29 [DKA]
Adam: "If you're making an XHR request from a widget container, make sure the requestheaders are set correctly?"
15:16:45 [DKA]
Bryan: This is also valid for a Web App running in the browser.
15:17:42 [DKA]
Adam: The security model of using XHR from a browser is that the request can't go to another domain...
15:17:59 [DKA]
Bryan: The server could still gain some value by knowing the type of application that's interacting with it.
15:19:06 [DKA]
DKA: Is this a practice currently used in Web App developers?
15:19:50 [DKA]
Jo: I think that if you're an application provider you can find other ways to do this besides adding headers.
15:20:03 [DKA]
Jo: I think this is one way to design a web application.
15:20:45 [DKA]
Bryan: If I make an XHR request and I am requesting ATOM but the browser accept header doesn't list ATOM then the server might not support it.
15:21:26 [DKA]
Jo: Not sure about that. I do think there's something we can say about setting request headers. We should say to set cache-control no-transform - that would be valid and legitimate.
15:22:31 [DKA]
DKA: Don't most browsers send */*?
15:23:06 [DKA]
Bryan: That's not a HTML best practice. The fact that they do it is a punt. In the end the servers ignore it.
15:29:18 [jo]
ACTION: Bryan to raise his email http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html as an issue
15:29:18 [trackbot]
Created ACTION-854 - Raise his email http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html as an issue [on Bryan Sullivan - due 2008-10-03].
15:31:42 [DKA]
Adam: I will address the actions, put together a new draft and we can discuss next week.
15:33:29 [DKA]
Topic: Discussion of appendix on device information
15:34:14 [DKA]
Bryan: I sent an email on Sept 4th on this: http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0007.html
15:34:26 [jo]
http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/att-0007/00-part
15:35:27 [DKA]
Jo: This repeats the info in DDR core vocabulary. To be more useful it should say - these are [additional] properties that are implied by this documents, like popups on PIM access.
15:35:49 [DKA]
Bryan: it would be useful to list capabilities that are implied but not supported by existing DDRs.
15:37:50 [DKA]
DKA: It makes sense to do both.
15:38:19 [DKA]
Jo: We'll do it when we're done. Need to add a placeholder for now.
15:39:10 [DKA]
ACTION: Adam to add an appendix on device info based on Bryan's contribution with a placeholder for additional device capabilities that are implied by the BP2 BPs.
15:39:10 [trackbot]
Created ACTION-855 - Add an appendix on device info based on Bryan's contribution with a placeholder for additional device capabilities that are implied by the BP2 BPs. [on Adam Connors - due 2008-10-03].
15:39:43 [jo]
rrsagent, draft minutes
15:39:43 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo
15:40:41 [jo]
[end of meeting]
15:40:53 [jo]
rrsagent, draft minutes
15:40:53 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo
15:41:51 [Zakim]
-Bryan_Sullivan
15:43:06 [Zakim]
-aconnors
15:43:07 [Zakim]
MWI_BPWG()8:30AM has ended
15:43:08 [Zakim]
Attendees were aconnors, Bryan_Sullivan
15:44:47 [jo]
present+ bryan
15:44:54 [jo]
rrsagent, draft minutes
15:44:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo
16:09:08 [Zakim]
Zakim has left #bpwg