The World Wide Web Consortium (aka W3C) is currently developing a Mobile Web Applications Best Practices document, and we are soliciting input from people who are not a part of the usual W3C conversation about such matters to provide comments and input. The document is primarily directed at creators, maintainers and operators of Web applications aimed at mobile Web users.
Your input would be very valuable, both to the W3C group working on these issues and to the community at large. We are trying to gather input from a wider group than usual, and this post will serve as a central repository for comments from folks who are not a part of the mailing lists or Working Groups at W3C. The Mobile Web Initiative at W3C will produce a much better standards and practices document if you help us out.
Thank you for your help in this effort to solicit input, and please feel free to point others who work in the field to these materials so that they too can comment here.
jeffs
I don’t quite understand. What’s happening to MWBP 1.0 document here? http://www.w3.org/TR/mwabp/
It does not seem finished. And now there is a 2.0?
I think it’s a better idea just to attempt to keep the current draft current.
The mobile Web community is out there somewhere, though I don’t they are on http://lists.w3.org/Archives/Public/public-bpwg-comments/
I think a lot can be gleamed by:
http://code.flickr.com/blog/2008/10/27/lessons-learned-while-building-an-iphone-site/
(Efficiently getting Ajax fragments)
and perhaps
http://patterns.littlespringsdesign.com/index.php/Main_Page
just to be clear, this is about the Mobile Web *Applications* Best Practices document
Happy to help, how do we?
Hello, jeffreybeasley…
The best way to help would be to follow the link that says “Mobile Web Applications Best Practices document”, read the current “Incomplete draft”, and post your comments here. I will guarantee you that your comments will be attended to and discussed by the Mobile Web Best Practices Working Group… we very much want input from people outside W3C.
I very much appreciate your offer of assistance. Please feel free to tell your colleagues and friends who work in this area about this post and document… more eyes looking at the document and commenting mean a better document will be produced by the process.
jeffs
I serve on the MAG steering committee and our group has done a considerable amount of work on creating an E commerce Document as well as other Mobile specific best practice Documents.
I believe the MAG has worked with W3C in the past.
Has the mobile group considered working with the MAG?
Cooperation with your group would be A Very Good Thing. I’ve emailed one of our Chairs (Dan Appelquist) to start the process of getting connections going.
jeffs
Kai: Thank you very much for the “lessons learned” and “Mobile UI design patterns” links. Very useful.
jeffs
I have a couple of comments on the document.
First off, in general, I like the format. I do documents with similar purposes sometimes, and I definitely like the “why should I care” section followed by the “here’s how to do the thing” section. Technical precision is important, but so is readability and accessibility of content. This is a good start.
1. I definitely agree that Section 3.1.1 could use some examples. I’m not an expert Web coder, but I do mobile apps sometimes. Having clear examples of what is meant by some specific technique, in source code form, would be a time-saver. For example, a couple of simple lines about “here’s how to make a cookie in a clean and reliable way that’s been tested on all common browsers” would be very reassuring when I’m writing something new.
2. Section 3.2.1 (HTTPS): I’ve designed some banking applications for phones and DRM for computers. Reliable, uninterrupted secure data transport is critical to this mission. If I have any doubt that my SSL transaction is unbreakable, I will avoid the system. And, eventually, some hacker will realize that it’s weak and will cause a horrific public relations disaster when a bunch of people lose a bunch of money. Even in the best case, digital security is imperfect. Don’t take chances by allowing a man in the middle. Hashing algorithms are good, but they’re not perfect.
3. Section 3.2.2: It’s really important to teach people about insecure data feeds and the concept of the “threat boundary.” Never implicitly trust data that’s crossed a threat boundary, even if you created the data on the other end. This is even more true in mobile, with the possibility of transcoders. A rogue transcoder could easily create a bogus data element that contains dangerous code.
This reminds me of a joke I heard about “Little Johnny” whose last name was “DROP TABLE STUDENTS”. Funny until you realize that people can and do use such subversive embedded SQL to wreak havoc on databases. In our systems, I insist that the programmers write code that strips all single apostrophes from data elements before sending them to the database, just in case. With mobile transcoders and various other security holes, that’s an even larger risk. Imagine, just for one example, a case where I set up a forwarding WiFi system on a laptop in an airport and capture/modify selected Web transactions to devices which randomly decide to connect to me. Could be big trouble. I want apps designed so that, in principle, such hacking is as hard as possible.
4. Section 3.3: You should add to this an item called “Confirm Important Actions”. It’s important to go out of your way as an app to request confirmation of an important transaction, such as a stock purchase or sale, or transfer of funds from one account to another. The more clear the implications of this can be, the better. For example, include not just the to/from account numbers but the to/from account owner names, so I know I didn’t inadvertently transfer the money to someone I don’t know.
5. Section 3.4.8.2: 8×8 boundaries are important for JPEG because its compression operates on 8×8 pixel metablocks. There is a certain amount of efficiency loss when using images that are not exactly a multiple of 8 pixels in height or width, with the worst case being a sprite that’s 9×9 pixels, because that would encode as 4 separate metablocks.
6. Section 3.4.12.1: power conservation upon backgrounding is very important. We just did a game show with handheld computers, and we had to do some special coding to ramp down CPU usage when the machine was inactive even when we were in the foreground. When we were backgrounded, we also had to write special code to shut off certain things like graphics driver updates. A host of examples will be important here, and the hardware manufacturers should probably be consulted for their input. Some of the techniques that can be used are not obvious.
7. Section 3.5.1.2: I like the discussion of the several UI models. Very nicely described.
8. Section 3.6.5: I prefer to offer one interface and design it really well. Doing multiple interfaces is very costly, and tends to introduce bugs because it increases the testing effort dramatically (especially when you’re revising the code frequently). So I understand why this is useful, but I try very hard not to do it if I can, for business reasons.
9. Section 3.7: I like SVG, but it’s immature. Perhaps by specifying that people use it or try to use it, you can prod browser makers to implement it consistently. We use SVG for the reporting in our educational product, and we had some issues between Windows and MacOS machine. I can only imagine how much more fragile SVG will be on less capable platforms. But it’s so useful that I think it’s worth fighting for.
Jeff, as requested, here is my feedback about the HTTPS issue.
As everyone knows, HTTPS is meant to imply end2end secure communication between an HTTP server and an HTTP client.
Transcoders (whose representatives are part of BPWG) would like to transcode as much as possible (it’s part of their business model). In order to transcode more, they need to break HTTPS. They will try to justify this with arguments such as:
- after all the user is OK with us breaking HTTPS
- the content owner may be OK with seeing HTTPS broken too
- there can be malicious plugins or browser which reveal sensitive information even after it has travelled through a secure connection, so we are not making the situation any worse after all, and
- … a bunch of similar amenities
All of these arguments are not acceptable of course. HTTPS is the foundation of eCommerce. Companies have entire business models based on the assumption that they can enjoy secure e2e communication with their customers. Because of this, anything that legitimizes breaking HTTPS is harmful to eCommerce in general and should be stopped from happening. The idea that W3C endorses this practice in any way is proposteroous.
I hope you see my viewpoint (and the viewpoint of countless other web and mobile-web stakeholders) and can bring our voice to BPWG, so that HTTPS-hacking is not acknowledged as a practice by W3C.
thank you
Luca Passani
In networking, there are some basic principles, one being that HTTPS is secure end-to-end, and that should remain always true, always. HTTPS is like an axiom — and building on top of HTTPS should always mean (it is accepted that it is) an end-to-end encrypted channel. If the W3C breaks that, it MUST NOT be called HTTPS. If W3C breaks HTTPS that is a major problem, and it is the WAP (Security) Gap all over again.
It is disappointing to see this security gap coming up again. I thought that as a mobile/wireless community and industry we had grown pass security gaps.
HTTPS should not be broken. HTTPS content shall not be transcodable. (Transcoding shall not take place anyhow, if the author of the content doesn’t wish it anyways; again, back to the importance of principles.)
If W3C continues pushing for the “transcoding of encrypted content” by introducing a gap, no need to reinvent the gap and to with WTLS. Then let the content owner decide protocol his/her content is consumed over.
ceo
I found an article that addresses these issues pretty clearly, and without flames. see this URI.
Jeff, apologies for not responding sooner. I looked at the document, as you had asked me to, focusing only on the HTTPS parts.
I too belong to the group that believes that SSL must not be broken. If there are sites out there that don’t mind their protected pages to be transcoded then they should explicitly say so using some form of an opt-in mechanism. All other sites must be left alone.
Further comments below:
> Alternatively, the simplest way to identify the user is to prompt for
> login credentials on first access and store a Hashed identity token
> in a cookie for future accesses.
If the above method is used then all site requests will include the hashed identity token, implying that all such requests need to go over SSL. Furthermore, such cookies must have the secure flag set, so that they are never sent across an unencrypted connection.
> Personally identifiable information (e.g. user identity or information
> usable as a key to user identity) should only be accepted or sent
> securely. Less sensitive information that cannot be associated with
> an individual (e.g. a ZIP code by itself is not personally identifiable)
> does not need to use HTTPS provided the correlating information is
> secure.
The partial-HTTPS model falls short of protecting the information the document wants protected. The threat model used in the document does not take the value of session IDs into account. Every application uses sessions, where session IDs are used as one-time authentication tokens. Session tokens are exchanged in every transaction and need to be protected using SSL. If they are not, whoever can intercept communication can also retrieve users’ session IDs and assume their sessions, thus gaining access to the private information.
> To avoid the overhead of using HTTPS for all transactions, a related
> pseudo-identity or secure hash of the actual identity can be
> exchanged in non-secure transactions.
Secure tokens are useful to replace the exchange of sensitive information (e.g. credit cards), but not for identities. A pseudo-identity–same thing as a session token, by the way–still needs to be protected because it is similar in power to credentials.