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

Re: Comments on BP2

From: Sean Owen <srowen@google.com>
Date: Thu, 13 Mar 2008 17:37:54 -0400
Message-ID: <e920a71c0803131437o4b3586e3t6594af3f81c31a7@mail.gmail.com>
To: "Sullivan, Bryan" <BS3131@att.com>
Cc: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>

On Thu, Mar 13, 2008 at 4:48 PM, Sullivan, Bryan <BS3131@att.com> wrote:
>  We need to be careful not to follow too strict a "mobile-specific" focus
>  or we will end up saying very little indeed. Certainly the Mobile Web
>  shares technology and service paradigms with the Wired Web. But to say
>  that anything which has any significance whatsoever in the Wired Web
>  case is thus out of scope for the MWI, is not helpful.

Good thing that is not what I said. Rather, I say that things which
have a particular significance to the mobile web are in scope, and
those only. Otherwise, what does "Mobile" in MWI mean? We could write
about any old web-related ideas then. We absolutely do have a
mobile-specific focus. I think we agree in principle because you say:


>  I included various topics of interest to the broader web specifically
>  because the nature of the Mobile Web raises their importance to be
>  addressed as best practices, either because they are more important
>  fundamentally in the Mobile Web case, or the techniques which support
>  them are more problematic in the Mobile Web case. Personalization as an
>  objective of increasing service value is one such aspect. These are

Yes, existing issues with renewed or different concerns in mobile are
in scope. "Keeping personal info private" does not strike me as one of
these, but I should explain below...


>  thus more difficult to address in the mobile environment. Automatic
>  personalization, and easy-to-use methods for input of personalizing
>  information when necessary, make this a realizable goal for mobile
>  services.

I don't think I objected to the idea of personalization on mobile... ?


>  methods which can be used and supplement HTTPS for critical
>  personalization phases, e.g. as I have mentioned in the best practices.
>  Many developers simply will not be aware that there may be concerns
>  about personal information trust/security, and further have any clue how
>  to do it other than use HTTPS, which will work fine as I have said for
>  the Wired Web, but not as a general approach for the Mobile Web. Thus
>  there is a higher need for something (personalization), and a less
>  robust environment to provide it. These combine to an issue which is
>  valuable to address as a best practice.

If you mean that it's OK to exchange credentials over HTTPS and then
exchange a session token of some kind from there over HTTP, I don't
agree. That token is a key to a session, and untold other personal
information, and must be kept secure. Otherwise why would we have
HTTPS at all? my 128-bit session cookie's ID would be enough after
login. If the original exchange was important enough to warrant HTTPS,
HTTPS is warranted when exchanging its equivalents. I think suggesting
developers concoct an alternative that they think is secure enough is
asking for trouble.

If the rest of the BP is saying, don't use HTTPS without need, then I
agree. That's a good example -- a zip code is possibly not sensitive
per se.

I suppose my complete thought, which was not expressed, is that I
don't agree with the parts written that suggest using anything but
HTTPS where security is legitimately needed. Then what's left is just
what anyone would recommend for the web.


>  Re 5.3.2, many web applications will use device storage outside the
>  browser cache, and the market is "gearing" up for this. We need to
>  recognize this and prepare best practices that set expectations on the
>  impact to limited device resources.

OK, maybe so, if the web browser truly becomes an application platform
with access to local storage. Then I'd say this isn't even practice
yet, let alone best practice. It may seem I am being picky, but, again
I feel strongly that this document is about codifying current best
practice. It's what people turn to to catch up on what they should do
today.

We can write that applications should warn about how much storage they
use, but, right now I don't know that AJAX apps can even access the
browser cache or local filesystem to even know that (I could stand to
be corrected)? How would anyone do this today?


>  Re 5.4.2, BP1 said simply "don't do it" re Redirect. What I'm saying is
>  that there needs to be *realistic* guidelines on what should be the
>  typical use of redirect in the cases I have mentioned, which are
>  typical. BP1 did not adequately address this, as I pointed out in the
>  Nov 07 F2F.

BP1 didn't quite say this. It said don't use <meta> and limit to one
redirect if you can. I suppose you're saying two here. If that's the
difference, if that's deemed important... OK. I suppose I find it
virtually the same.


>  Re 5.9.4 Provide Alternatives to AJAX, this specifically is assuming
>  that not *all* devices will support AJAX, which is reasonable. The point
>  is that AJAX/scripted applications need to be provided in alternate
>  forms to work on such devices. Perhaps obvious, but then we are SME's
>  and this is not written for us.

But then nothing is said about what that means, so what is the purpose
of writing this? "How to do it" is to "build something else for these
devices?" I think this BP is present to pretend we're not limiting
ourselves to AJAX-capable devices, when we are, and that's fine.


I can only say I recommend against writing a document like this. I
think it is missing some useful, concrete recommendations based on
current best practice, and veering out of scope. I would not support
something like this being published, but if I am in the minority
that's OK.
Received on Thursday, 13 March 2008 21:38:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 March 2008 21:38:37 GMT