Mobile Web Best Practices Working Group Teleconference -- 26 Sep 2008

<trackbot> Date: 26 September 2008

Hia

<jo> Meeting: MWABP Editors Meeting

[discussion of scope of BP2]

Scibe: Dan

<scribe> ScribeNick: DKA

Bryan's comments

Jo: Suggest removing first paragraph f 4.2.1.2 (regarding SSO providers) as there is not enough current practice.

Adam: In discussion with group we weren't sure if we could recommend a secure hash as a form of security.

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."
... We should bounce this to the web security context working group.

Bryan: What's the concern about recommending we use a secure hash for URL parameters?

Jo: Just want to make sure we get the feedback from the WSCWG.

<scribe> ACTION: Bryan to write a note to WSCWG asking for comment on using secure hashes for securing URL parameters. [recorded in http://www.w3.org/2008/09/26-bpwg-minutes.html#action01]

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

<jo> http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080521

Bryan: there are different mechanisms for security - beyond use of SSL.

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.

Bryan: We need to give them the reliable technique pointers and let them decide the context.

DKA: "Sentitive" information is different in different regions... SO we can't give accurate guidance...

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.

<jo> ISSUE-275: Bryan is writing to the WSC WG to request their input on acceptable alternatives to using https

<trackbot> ISSUE-275 4.2.1 Protect Personal Information notes added

<jo> ISSUE-276?

<trackbot> ISSUE-276 -- 3.1.1 Retain Personalization Information -- RAISED

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/276

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.

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.

DKA: We could also talk about using HTML5 / Gears data persistence if it does exist.

Jo: Discussion of limitations of using cookies is useful.
... We need to distinguish intra-session persistence of data and inter-session persistence of data.

Adam: Yes - if we're talking about inter-session then javascript variables, url paramaters and forms are not applicable.

Bryan: I could be in a session for quite some time...

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.

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.

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.

Adam: In a session, all the examples cited are applicable. Across sessions, I can think of cookies, html cache, and local storage.

Bryan: And persistent storage techniques.

DKA: We can roll that all up in discussion of client side persistent storage.

Adam: "Client side persistent storage, for example HTML persistence and other vendor initiatives as available."
... 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."

Jo: [document] very often says "user visits site" and what we really mean is "invocation of the application."

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.

<jo> scribe: Jo

bryan: visits site means in the course of a session

adam: need to pin down the inter and intra session notions

[discussion of which techniques are most applicable to which use cases]

<scribe> scribe: dka

Jo: Point is: do not make people enter data more than once, ever.

Bryan: it's useful to state limitations.

Jo: can we say something about server side session frameworks?

Adam: to my mind that's not in scope -

DKA: We'd have to include recommendations for perl, php, iis, apache, etc...

Jo: OK.

<scribe> ACTION: Adam to re-write 3.1.1 along the lines discussed today. [recorded in http://www.w3.org/2008/09/26-bpwg-minutes.html#action02]

<trackbot> Created ACTION-853 - Re-write 3.1.1 along the lines discussed today. [on Adam Connors - due 2008-10-03].

<jo> ISSUE-276: Adam will re-write the relevant section calling out the different techniques available intra and inter session per ACTION-853

<trackbot> ISSUE-276 3.1.1 Retain Personalization Information notes added

All praise to Dom for his wonderful tracking tools without which we would be but maggots, groveling in the mud and slime.

<jo> not to mention the foetid swaps

<jo> ISSUE-277?

<trackbot> ISSUE-277 -- 3.3.1 Inform user about automatic network access and provide control -- RAISED

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/277

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.
... I can't imagine where this information is imparted in a [web] application.

DKA: Shouldn't we leave this to the platform?

Bryan: Visual cues are only useful if you're looking at the device.
... When I'm not looking at the device - when the app is running in the background (e.g. a widget).

DKA: Shouldn't this be kicked back to another body such as OMTP?

Bryan: the W3C webapps group is working on a manifest related to the widget package - there's a description field there.

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

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.

Bryan: that's OK.

DKA: "Great."

Adam: We need to be mindful of negative effect of usability.

Jo: text can be amended to say "provide this information in a non-intrusive way."
... 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.
... Also, in a lot of places in the document it would be better to use the imperative and active voice.

<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

<trackbot> ISSUE-277 3.3.1 Inform user about automatic network access and provide control notes added

<jo> Open ISSUE-277

ISSUE-278?

<trackbot> ISSUE-278 -- 3.3.2 Inform user about use of PIM information -- RAISED

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/278

Adam: Same issue but on the PIM information.
... 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.

Bryan: issue of "what should you disclose"

<jo> scribe: Jo

adam: what you just said clarifies the context - reading the BP on its own was less clear

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

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

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
... so I support adam ins aying we should descope this, as unless we have something specific to say it all gets a bit fuzzy

bryan: doesn't mean we can't give guidance just because we don't know the cultural or legal context
... tell the user what you are going to use and how you are going to use it

jo: not sure how this is different from saying "treat it like the previous issue"

adam: in summary taking the two old bullets and inserting them into the new section is basically what we need to do

ISSUE-278: Adam is going to merge the two old bullets into the new section

<trackbot> ISSUE-278 3.3.2 Inform user about use of PIM information notes added

ISSUE-278: OPEN

<trackbot> ISSUE-278 3.3.2 Inform user about use of PIM information notes added

<DKA> ISSUE-279?

<trackbot> ISSUE-279 -- 4.3.3 Provide Disclosures that are Timely and Accessible -- RAISED

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/279

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

<DKA> Scribe: Dan

<DKA> ScribeNick: DKA

Bryan: This talks about your options...

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?

Jo: What's the existing problem we're trying to solve?

Bryan: People don't know they're supposed to do it and also they don't know how to do it.

Jo: It could be turned around into a "what not to do" - say "don't do it this way..."

<jo> ISSUE-279: Adam is going to re introduce a BP pulling out the commonalities between the PIM one and the network access one

<trackbot> ISSUE-279 4.3.3 Provide Disclosures that are Timely and Accessible notes added

ISSUE-280?

<trackbot> ISSUE-280 -- 3.3 User awareness and control -- RAISED

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/280

Jo: This does fall under "provide control over network access."

Adam: Comments on specific bullets.

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.

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.

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.

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.

<trackbot> ISSUE-280 3.3 User awareness and control notes added

Bryan: wrt our input to the webapps, and the way we can deal with those comments through bp2.

<jo> ISSUE-280: Adam is going to add the bullets here to the BP on user control noted earlier

<trackbot> ISSUE-280 3.3 User awareness and control notes added

Bryan: [introducing http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html]

Adam: "If you're making an XHR request from a widget container, make sure the requestheaders are set correctly?"

Bryan: This is also valid for a Web App running in the browser.

Adam: The security model of using XHR from a browser is that the request can't go to another domain...

Bryan: The server could still gain some value by knowing the type of application that's interacting with it.

DKA: Is this a practice currently used in Web App developers?

Jo: I think that if you're an application provider you can find other ways to do this besides adding headers.
... I think this is one way to design a web application.

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.

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.

DKA: Don't most browsers send */*?

Bryan: That's not a HTML best practice. The fact that they do it is a punt. In the end the servers ignore it.

<jo> ACTION: Bryan to raise his email http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html as an issue [recorded in http://www.w3.org/2008/09/26-bpwg-minutes.html#action03]

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

Adam: I will address the actions, put together a new draft and we can discuss next week.

Discussion of appendix on device information

Bryan: I sent an email on Sept 4th on this: http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0007.html

<jo> http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/att-0007/00-part

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.

Bryan: it would be useful to list capabilities that are implied but not supported by existing DDRs.

DKA: It makes sense to do both.

Jo: We'll do it when we're done. Need to add a placeholder for now.

<scribe> 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. [recorded in http://www.w3.org/2008/09/26-bpwg-minutes.html#action04]

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

<jo> [end of meeting]

- DRAFT -

Mobile Web Best Practices Working Group Teleconference

26 Sep 2008

Attendees

Contents

Bryan's comments

Discussion of appendix on device information

Summary of Action Items

Scribe.perl diagnostic output