Hi, I’m Mark Nottingham. I currently co-chair the IETF HTTP and QUIC Working Groups, and am a member of the Internet Architecture Board . I usually write here about the Web, protocol design, HTTP, and caching. Find out more .

Opera Turbo

HTTP performance is a hot topic these days, so it’s interesting that Opera has announced a “turbo” feature in Opera 10 Beta;

Ever felt a Web site was loading slowly? Do you think it will happen again? Think again: Opera Turbo is a compression technology that provides significant improvements in browsing speeds over limited-bandwidth connections like a crowded Wi-Fi in a cafe or browsing through your mobile phone while commuting.

They go on to give more details in their sales materials as well as a blog entry (both found by a search engine, not linked from the feature description):

That’s why we’ve been working on Opera Turbo, a server-side optimization and compression technology that provides significant improvements in browsing speeds over limited-bandwidth connections by compressing network traffic. This does not only make you surf faster, but also lowers the cost of browsing when you are on a pay per usage plan.

Note the use of “server-side” here. The interesting thing here is that when I turn on Turbo and sniff the network to see what’s going on, all of my connections seem to go to a server like this:

Macintosh:~> nslookup 064.255.180.252 Server: 192.168.1.254 Address: 192.168.1.254#53 ** server can't find 064.255.180.252: NXDOMAIN Macintosh:~> nslookup 64.255.180.252 Server: 192.168.1.254 Address: 192.168.1.254#53 Non-authoritative answer: 252.180.255.64.in-addr.arpa canonical name = 252.0-24.180.255.64.in-addr.arpa. 252.0-24.180.255.64.in-addr.arpa name = global-turbo-1-lvs-usa.opera-mini.net.

In other words, this isn’t a “server-side” technology; it’s a proxy.

From a technical standpoint, this is an interesting approach; intermediation is a great way to introduce new features into the request stream (here, they’re compressing content and stripping headers, by the look of it).

However, I’m in Australia, and they’re sending all of my requests — even for Australian content — through a US proxy, which adds several hundred milliseconds to every request, and depending on my provider, may cost me more (some AU providers make local content free). Considering that the people who this technology’s marketing will appeal to most — e.g., those in the Australian bush, or rural India — won’t be served well by this, it seems like it would be important to point this out.

More damningly, a quick test shows that Turbo’s proxy doesn’t honour the Cache-Control: no-transform directive, and moreover, strips it from responses. no-transform is specified to assure that clients and servers have a way of avoiding problems with transcoding proxies — just like Turbo (emphasis added):

no-transform

Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non- transparent proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link.

Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body.

Therefore, if a message includes the no-transform directive, an intermediate cache or proxy MUST NOT change those headers that are listed in section 13.5.2 as being subject to the no-transform directive. This implies that the cache or proxy MUST NOT change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself.

To put it mildly, this is disappointing, given Opera’s historical focus on standards compliance.

From a privacy standpoint, it gets worse. Calling this a server-side technology is frankly unconscionable. A reasonable person who reads the blurb and follows the in-browser instructions will have no idea that their requests are being routed through Opera, and no disclosure is made about what is done with that data. I’m a little surprised by this, considering that Opera is an EU-based company, and therefore subject to the European Data Protection laws.

It is worth noting that in their blog entry (which again, has to be found separately), they do say

Your privacy is important Even when Turbo is enabled, encrypted traffic does not go through our compression servers. This means that when you are on a SSL site, we bypass these traffic and let you communicate with the SSL site directly. Opera generates statistics of the usage of Opera Turbo, but these are aggregated numbers and no information can be linked to a single user. Opera does not store any users’ private information.

So, their heart is in the right place, but this doesn’t make up for not informing users up-front.