Native apps can't be trusted

The one thing the web has gotten right to some extent (thanks to the beauty of REST/HTTP) at least compared to desktop and native apps, is how it can uniformly show users if they are using a secure connection to a trusted source. The browser does this by clearly and consistently giving various hints (see Fig 1 and Fig 2 below):

Fig 1. Firefox indicating that you are securely connected to GitHub.

Fig 2. Chrome indicating that you are securely connected to GitHub.

There is no reliable, trustworthy and consistent way for non-technical users to do this on desktop and native apps.

This is how you add funds to your Paytm wallet from within the Uber app (see Fig 3 below):

Fig 3. Page to add funds to your Paytm wallet from within the Uber app.

Notice the following in Fig 3:

1. Since I opened this from within the Uber app and this "page" is running "inside" the Uber app, I have no way to verify if what I'm seeing is in fact a page severed by Paytm or a spoofed page that Uber is presenting to me.
2. Even if I were to trust Uber here, there is no way for me to tell if this is happening over a secure connection.
3. Say I'm willing to accept that this is in fact a page served securely by Paytm, I have no way to know if Uber has injected their own code to intercept everything I enter on that page.
4. And now the really ridiculous bits (circled in red in Fig 3 above): The text that reads "Your payment details are secured via 128 Bit encryption by Verisign" and the various logos that are displayed at the bottom of the page are something I have to take at face value. These are also app-specific and not consistent.

Also, note that I (as a non-technical end-user) have no way of knowing if all communication the Uber app is doing with it's servers is over a secure channel. I just have to "trust" that they are doing the right thing. Of course, as a technical user I could intercept the traffic on my phone and see how it's been sent, but that is exactly the point: You have to jump through a lot of hoops to "verify" what is happening.   

The current state of affairs for security on native apps is absolutely ridiculous and it's crazy that we all put up with it.

Full Disclosure: I work at Zeta (at the time of writing this blog post), but the views expressed here are my own and not of my employer.

What native apps get wrong over web apps

1. They need to be installed. This in itself is a big drawback.
2. They need to be separately developed for each target platform. Unlike the desktop app days where Windows was almost ubiquitous, with mobile you have to support 2 platforms.
3. They can get outdated if users don't upgrade. We are doomed to repeat the same mistakes we made with desktop apps.
4. Deployment is blocked on a black box not in your control (aka the app store approval process). Kiss continuous deployment goodbye.
5. They have no trustworthy way to indicate to users that secure channels are being used to communicate secure information (unlike the address bar in web apps that clearly shows if the connection is secure and to the right place). If you think about it, there is a beauty to REST/HTTP that makes this possible.
6. Each app needs to reinvent the wheel and ship infra that could have been shared, e.g., local data store, caching, etc.

The Web Site IS the API

Web APIs Are Just Web Sites:

A short presentation on how you might like to build a simple “Web API”.

I've said this before and the reason it's important for web application developers to understand this is that it changes the way they look at and design web applications. The difference between a Web Service and a Web Application is only in the representation.

The irony of the Web

An interesting comment by Don Park:

Isn't it ironic that much of the Web 2.0 businesses depend on the GET method being non-idempotent? Otherwise, PPC won't generate any revenue.

:)

Making Web Standards Work

More W3C Controversy

We should work on, and implement, the standards that we think are appropriate for Web browsers, and ignore the rest. We should spend our time improving what Web developers and users want, not waste our time improving what is less important or criticizing what isn't going to work in the first place.

+1

Lets talk about REST

Its great to see all this talk about REST. Now if only they could figure out the difference between a resource and its representations (the R in REST) and pry the XML off HTTP and discover media types.

*sigh*

Browser URL Size Limits

Via Rules for Bookmarklets:

Browser	Max chars
Netscape	> 2000
Firefox	> 2000
Opera	> 2000
IE 4	2084
IE 5	2084
IE 6	508
IE 6 SP 2	488
IE 7 beta 2	2084

The evolution of Web Design

• web2.0 logos!


• The Logos of Web 2.0 - A breakdown of the fonts used in some of the above logos.


• The Elements of Typographic Style Applied to the Web - a practical guide to web typography

Yahoo unREST

Saying that they use REST is a misnomer. What they actually use is Browserland HTTP.

Case in point:

By default, Yahoo! Web Services return output in XML format. Some, but not all, of the Yahoo! Web Services can also return Serialized PHP. To get output in Serialized PHP format, use the output=php parameter in the request:

http://api.search.yahoo.com/ ImageSearchService/V1/ imageSearch?appid=YahooDemo &query=Madonna&results=1 &output=php

The RESTful way to do this is with an Accept Request header field.

I did point this out to Rasmus during a Web Services BOF at FOSS.in to which he said that it was easier to call it REST than call it HTTP. I don't buy this. A web developer will be much more familiar with the word HTTP (the thingy you see in the address bar of your browser and in the URI I've quoted above from Yahoo!'s own documentation) than with the word REST (an architectural style for distributed hypermedia systems described in a dissertation by Roy T. Fielding).

Now that that's out of my system, I really like what they are doing with PHP, especially this. I'm using Serialized PHP for representations as well in a web application I'm working on using Inertia with the following media type: application/x-serialized-php.

Browserland HTTP

All this talk about Lo-REST and Hi-REST is so misleading.

There arent two types or levels of REST. There are just Components that support HTTP to various degrees and that is where the problem lies.

For the most part we are trapped in Browserland HTTP:

• Availability of only a subset of the HTTP methods (GET and POST).


• Visibility/Awareness of a subset of the REST Data Elements (resource identifier and representation).


• Cookies!


• Limited or no control of conneg on the client side.


• Broken HTTP Authentication Interface.


• No true client-side state.

The people making the argument that Browserland HTTP is "what’s been proven on the web" and REST is just theory, "speculative", "unproved in practice, and unlikely to be a game-changer" haven't been paying attention.

State of REST

When you get REST and then go back to the drawing board to design your web application/service you realize that we've cornered ourselves in Browserland HTTP and that is the really tragedy of REST: The only protocol that follows the REST architectural style is crippled by its current infrastructure.

Web Service = Web Application

If you get REST, you will get this.

The difference is only in the representation.