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

RE: Comments on BP2

From: Sullivan, Bryan <BS3131@att.com>
Date: Thu, 13 Mar 2008 17:21:25 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD05D940C6@BD01MSXMB015.US.Cingular.Net>
To: "Sean Owen" <srowen@google.com>
Cc: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>

Sean,
Re "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...": the logical conclusion of that is if one considers any
service personal, it must be provided entirely over HTTPS, which is not
practical. Securely hashed cookies and URL parameters are very common
and secure ways of ensuring that personal/personalizing information
established via HTTPS is made available over the rest of a service
session. For efficiency reasons alone, we should make it clear that
these are best practices for mobile web services.

Obviously there are some types of personal services which mandate HTTPS
usage throughout, e.g. m-commerce, banking, investing. But for many
personal services it is sufficient to establish privacy/anonymity by
determining user identity/preferences securely, then securely hash the
personal information/preferences that can then be exchanged over
non-secure connections. Anyone seeing the response to a request (or
replaying an earlier request) may then see info on moss-covered
three-handled family gredunzas and can assume I'm one of those
"moss-freaks", but they won't know who I am. They won't even be able to
discover my preference without going to all the trouble to create a
replay attack, to check out the bizarre content coming back. In summary,
it's not an all-or-nothing situation, and there needs to be a continuum
of methods which developers can choose appropriately and use
efficiently.

Re persistent storage, even in web browsers this is becoming a reality,
and will be by the time developers catch up to BP2. For other web
applications, e.g. offline browsers, news readers, generic web
application widgets, and other applications that can use web
technologies to retrive and present locally managed data, its already a
reality. All of these can fit to the web application "qualifications"
discussed on the list earlier. Disclosing impact to limited resources,
no matter what they are, should be a best practice for web applications.

Re alternatives to AJAX, I agree that we need to say something specific.
That's why I have the editor note "[Placeholder for guidance on
alternate techniques would be helpful here]".

I don't know what you mean "I recommend against writing a document like
this", except re the specific points you have raised. The document as it
stands makes specific recommendations on goals and methods. Certainly it
can and should be made even more specific.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Sean Owen [mailto:srowen@google.com] 
Sent: Thursday, March 13, 2008 2:38 PM
To: Sullivan, Bryan
Cc: Mobile Web Best Practices Working Group WG
Subject: Re: Comments on BP2

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 Friday, 14 March 2008 00:22:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 March 2008 00:22:27 GMT