- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Fri, 26 Sep 2008 16:48:15 +0100
- To: public-bpwg <public-bpwg@w3.org>
These are the monochrome minutes of today's editorial meeting, also
available in technicolor at [1].
[1] http://www.w3.org/2008/09/26-bpwg-minutes.html
Jo
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Mobile Web Best Practices Working Group Teleconference
26 Sep 2008
See also: [2]IRC log
[2] http://www.w3.org/2008/09/26-bpwg-irc
Attendees
Present
DKA, Adam, Jo
Regrets
Chair
Adam
Scribe
Jo, dka, Dan
Contents
* [3]Topics
1. [4]Bryan's comments
2. [5]Discussion of appendix on device information
* [6]Summary of Action Items
_________________________________________________________
<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
[7]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>
[8]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED
-mobile-bp2-20080521
[8]
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> [9]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/276
[9] 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
[10]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>
[11]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/277
[11] 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>
[12]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/278
[12] 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>
[13]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/279
[13] 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>
[14]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/280
[14] 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
[15]http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.htm
l]
[15] 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
[16]http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.htm
l as an issue [recorded in
[17]http://www.w3.org/2008/09/26-bpwg-minutes.html#action03]
[16] http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html
<trackbot> Created ACTION-854 - Raise his email
[18]http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.htm
l as an issue [on Bryan Sullivan - due 2008-10-03].
[18] http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html
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:
[19]http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0007.htm
l
[19] http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0007.html
<jo>
[20]http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/att-0007
/00-part
[20]
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
[21]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]
Summary of Action Items
[NEW] 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
[22]http://www.w3.org/2008/09/26-bpwg-minutes.html#action04]
[NEW] ACTION: Adam to re-write 3.1.1 along the lines discussed
today. [recorded in
[23]http://www.w3.org/2008/09/26-bpwg-minutes.html#action02]
[NEW] ACTION: Bryan to raise his email
[24]http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.htm
l as an issue [recorded in
[25]http://www.w3.org/2008/09/26-bpwg-minutes.html#action03]
[NEW] ACTION: Bryan to write a note to WSCWG asking for comment on
using secure hashes for securing URL parameters. [recorded in
[26]http://www.w3.org/2008/09/26-bpwg-minutes.html#action01]
[24] http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0087.html
[End of minutes]
Received on Friday, 26 September 2008 15:49:00 UTC