I have read the above article and it shows we are going to develop web applications (as per 6.x section described in the article) for iPhone. In web application programming, browser can only interact with the server using server side programming(synchronous or asynchronous) or can do processing within the browser using client side scripting languages.

In the above case, is there any way that browser can fetch information from GPS receiver in the client?

I would like to attend but is there any student scholarship i can apply to get support for the conference?

1/People get tired of losing their pen or pointing device.
It is more applicable for the term of “mobile”;since, now users can carry less accesorries anyway.
Laptop for instance, few years back people still carry a mouse with their laptop. These days, we see more and more people use less of the mouse and simply just use the laptop short-key and its small touch pad. It is also about going “green”. Now, we will have less junk to worry about as new technology arrives.
“quick and effortless”

2/Many product designs get started or developed simply based on human sense of touch and how human interact with a product. Back to the mouse example, the design of a mouse is always about how it can be more of handle friendly to users.
Also, It is about how sense of comfort and security of human nature. If we can use one of our senses to experience thing, it seems like we get it faster. Hence, using hand as a control is something we are all familiar with.

3/The above comments are all about small devices. What about a big screen? I can see two main issues with the big screen – one is the price and the other one is the control complexity. I remember that the big touch screen was first introduced for an education purpose to replace a black/white board. However, it was not a big hit. This could also be because of the design complexity. Maybe, there are too many commands and control options to choose from. Or,simply people just don’t want to swith to the new technology.

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.

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

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

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.

jeffs

jeffs