W3C home > Mailing lists > Public > public-bpwg@w3.org > September 2008

[Minutes] Minutes from the MWABP Editorial Meeting 2008-09-26

From: Jo Rabin <jrabin@mtld.mobi>
Date: Fri, 26 Sep 2008 16:48:15 +0100
Message-ID: <48DD043F.9090706@mtld.mobi>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC