12:36:54 RRSAgent has joined #bpwg 12:36:54 logging to http://www.w3.org/2008/09/26-bpwg-irc 12:36:56 RRSAgent, make logs public 12:36:56 Zakim has joined #bpwg 12:36:58 Zakim, this will be BPWG 12:36:58 ok, trackbot; I see MWI_BPWG()8:30AM scheduled to start 6 minutes ago 12:36:59 Meeting: Mobile Web Best Practices Working Group Teleconference 12:36:59 Date: 26 September 2008 12:37:36 zakim, what is the code? 12:37:36 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 has joined #bpwg 12:38:02 rrsagent, draft minutes 12:38:02 I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo 12:38:14 MWI_BPWG()8:30AM has now started 12:38:21 +aconnors 12:38:37 Hia 12:38:53 Meeting: MWABP Editors Meeting 12:39:17 Chair: Adam 12:39:32 Present: DKA, Adam, Jo 12:55:16 [discussion of scope of BP2] 12:56:45 Scibe: Dan 12:56:51 ScribeNick: DKA 12:57:04 jo has joined #bpwg 12:58:59 rrsagent, draft minutes 12:58:59 I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo 13:04:57 Topic: Bryan's comments 13:16:31 +Bryan_Sullivan 13:16:37 Jo: Suggest removing first paragraph f 4.2.1.2 (regarding SSO providers) as there is not enough current practice. 13:17:17 Bryan has joined #bpwg 13:18:09 Adam: In discussion with group we weren't sure if we could recommend a secure hash as a form of security. 13:18:55 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 Jo: We should bounce this to the web security context working group. 13:22:11 Bryan: What's the concern about recommending we use a secure hash for URL parameters? 13:22:53 Jo: Just want to make sure we get the feedback from the WSCWG. 13:23:53 ACTION: Bryan to write a note to WSCWG asking for comment on using secure hashes for securing URL parameters. 13:23:53 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 http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080521 13:26:19 Bryan: there are different mechanisms for security - beyond use of SSL. 13:27:24 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 Bryan: We need to give them the reliable technique pointers and let them decide the context. 13:28:30 DKA: "Sentitive" information is different in different regions... SO we can't give accurate guidance... 13:29:01 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 ISSUE-275: Bryan is writing to the WSC WG to request their input on acceptable alternatives to using https 13:30:55 ISSUE-275 4.2.1 Protect Personal Information notes added 13:31:33 ISSUE-276? 13:31:33 ISSUE-276 -- 3.1.1 Retain Personalization Information -- RAISED 13:31:33 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/276 13:33:59 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 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: We could also talk about using HTML5 / Gears data persistence if it does exist. 13:37:12 Jo: Discussion of limitations of using cookies is useful. 13:38:08 Jo: We need to distinguish intra-session persistence of data and inter-session persistence of data. 13:38:45 Adam: Yes - if we're talking about inter-session then javascript variables, url paramaters and forms are not applicable. 13:39:15 Bryan: I could be in a session for quite some time... 13:41:39 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 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 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 has joined #bpwg 13:43:41 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 Bryan: And persistent storage techniques. 13:46:01 DKA: We can roll that all up in discussion of client side persistent storage. 13:46:22 Adam: "Client side persistent storage, for example HTML persistence and other vendor initiatives as available." 13:47:04 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 Jo: [document] very often says "user visits site" and what we really mean is "invocation of the application." 13:50:48 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 zakim, who is here 13:51:23 jo, you need to end that query with '?' 13:51:33 zakim, who is here? 13:51:33 On the phone I see aconnors, Bryan_Sullivan 13:51:34 On IRC I see jo, Bryan, Zakim, RRSAgent, DKA, matt, dom, trackbot 13:52:48 scribe: Jo 13:53:13 bryan: visits site means in the course of a session 13:53:32 adam: need to pin down the inter and intra session notions 13:54:00 [discussion of which techniques are most applicable to which use cases] 13:54:10 scribe: dka 13:55:42 Jo: Point is: do not make people enter data more than once, ever. 13:57:00 Bryan: it's useful to state limitations. 13:59:03 Jo: can we say something about server side session frameworks? 13:59:15 Adam: to my mind that's not in scope - 14:00:27 DKA: We'd have to include recommendations for perl, php, iis, apache, etc... 14:00:32 Jo: OK. 14:01:02 ACTION: Adam to re-write 3.1.1 along the lines discussed today. 14:01:02 Created ACTION-853 - Re-write 3.1.1 along the lines discussed today. [on Adam Connors - due 2008-10-03]. 14:01:47 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 ISSUE-276 3.1.1 Retain Personalization Information notes added 14:03:07 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 not to mention the foetid swaps 14:07:26 ISSUE-277? 14:07:26 ISSUE-277 -- 3.3.1 Inform user about automatic network access and provide control -- RAISED 14:07:26 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/277 14:09:17 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 Adam: I can't imagine where this information is imparted in a [web] application. 14:12:49 DKA: Shouldn't we leave this to the platform? 14:13:04 Bryan: Visual cues are only useful if you're looking at the device. 14:13:41 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: Shouldn't this be kicked back to another body such as OMTP? 14:14:49 Bryan: the W3C webapps group is working on a manifest related to the widget package - there's a description field there. 14:16:38 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 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 Bryan: that's OK. 14:19:33 DKA: "Great." 14:20:46 Adam: We need to be mindful of negative effect of usability. 14:22:18 Jo: text can be amended to say "provide this information in a non-intrusive way." 14:24:19 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 Jo: Also, in a lot of places in the document it would be better to use the imperative and active voice. 14:27:13 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 ISSUE-277 3.3.1 Inform user about automatic network access and provide control notes added 14:27:35 Open ISSUE-277 14:27:41 ISSUE-278? 14:27:41 ISSUE-278 -- 3.3.2 Inform user about use of PIM information -- RAISED 14:27:41 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/278 14:28:32 Adam: Same issue but on the PIM information. 14:29:04 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 Bryan: issue of "what should you disclose" 14:35:45 scribe: Jo 14:36:31 adam: what you just said clarifies the context - reading the BP on its own was less clear 14:37:33 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 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 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 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 bryan: doesn't mean we can't give guidance just because we don't know the cultural or legal context 14:41:58 bryan: tell the user what you are going to use and how you are going to use it 14:42:46 jo: not sure how this is different from saying "treat it like the previous issue" 14:42:48 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 ISSUE-278: Adam is going to merge the two old bullets into the new section 14:43:13 ISSUE-278 3.3.2 Inform user about use of PIM information notes added 14:43:30 ISSUE-278: OPEN 14:43:30 ISSUE-278 3.3.2 Inform user about use of PIM information notes added 14:54:58 ISSUE-279? 14:54:59 ISSUE-279 -- 4.3.3 Provide Disclosures that are Timely and Accessible -- RAISED 14:54:59 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/279 14:56:45 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 Scribe: Dan 14:56:58 ScribeNick: DKA 14:57:13 Bryan: This talks about your options... 14:58:41 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 Jo: What's the existing problem we're trying to solve? 14:59:09 Bryan: People don't know they're supposed to do it and also they don't know how to do it. 15:00:30 Jo: It could be turned around into a "what not to do" - say "don't do it this way..." 15:01:45 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 ISSUE-279 4.3.3 Provide Disclosures that are Timely and Accessible notes added 15:02:48 ISSUE-280? 15:02:48 ISSUE-280 -- 3.3 User awareness and control -- RAISED 15:02:48 http://www.w3.org/2005/MWI/BPWG/Group/track/issues/280 15:04:52 Jo: This does fall under "provide control over network access." 15:05:37 Adam: Comments on specific bullets. 15:07:42 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 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 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 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 ISSUE-280 3.3 User awareness and control notes added 15:11:56 Bryan: wrt our input to the webapps, and the way we can deal with those comments through bp2. 15:12:01 ISSUE-280: Adam is going to add the bullets here to the BP on user control noted earlier 15:12:01 ISSUE-280 3.3 User awareness and control notes added 15:13:15 Bryan: [introducing http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html] 15:16:29 Adam: "If you're making an XHR request from a widget container, make sure the requestheaders are set correctly?" 15:16:45 Bryan: This is also valid for a Web App running in the browser. 15:17:42 Adam: The security model of using XHR from a browser is that the request can't go to another domain... 15:17:59 Bryan: The server could still gain some value by knowing the type of application that's interacting with it. 15:19:06 DKA: Is this a practice currently used in Web App developers? 15:19:50 Jo: I think that if you're an application provider you can find other ways to do this besides adding headers. 15:20:03 Jo: I think this is one way to design a web application. 15:20:45 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 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: Don't most browsers send */*? 15:23:06 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 ACTION: Bryan to raise his email http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html as an issue 15:29:18 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 Adam: I will address the actions, put together a new draft and we can discuss next week. 15:33:29 Topic: Discussion of appendix on device information 15:34:14 Bryan: I sent an email on Sept 4th on this: http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0007.html 15:34:26 http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/att-0007/00-part 15:35:27 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 Bryan: it would be useful to list capabilities that are implied but not supported by existing DDRs. 15:37:50 DKA: It makes sense to do both. 15:38:19 Jo: We'll do it when we're done. Need to add a placeholder for now. 15:39:10 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 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 rrsagent, draft minutes 15:39:43 I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo 15:40:41 [end of meeting] 15:40:53 rrsagent, draft minutes 15:40:53 I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo 15:41:51 -Bryan_Sullivan 15:43:06 -aconnors 15:43:07 MWI_BPWG()8:30AM has ended 15:43:08 Attendees were aconnors, Bryan_Sullivan 15:44:47 present+ bryan 15:44:54 rrsagent, draft minutes 15:44:54 I have made the request to generate http://www.w3.org/2008/09/26-bpwg-minutes.html jo 16:09:08 Zakim has left #bpwg