UK Wants to MITM SSL Connections to Facebook/Gmail

The UK Government wants ISP’s to record secure transmission of messages with services like Facebook and Gmail, which are currently using SSL. I’d be curious to know how the UK government actually plans to pull this off. To pull that off they’d need to get browsers to include their root certificate so they can MITM Gmail and Facebook. I can’t see that happening.

Of course anyone really wanting to do something criminal will just employ a VPN to tunnel past these ISP’s, or encrypt messages using GPG. Therefore, I don’t see what the point is.

About Those Red Tomatoes

From the LA Times:

But the new study, published this week in Science, found that the mutation that leads to the uniform appearance of most store-bought tomatoes has an unintended consequence: It disrupts the production of a protein responsible for the fruit’s production of sugar.

So can we go back to ugly looking but good tasting fruit (yes, tomatoes are fruit)? I’d strongly prefer taste to color.

Leap Smear

On how Google deals with leap seconds:

The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred.

Good idea. The second itself is meaningless. Spreading it out is much better/easier than accommodating for it in the rest of your stack.

Hard Drives Still Expensive After Flooding

From Ars:

The impact of that disaster has passed, and supply levels are back to near where they were before last October’s disaster. But while the flood waters have long since receded, drive prices haven’t fallen nearly as much—as InfoWorld’s Woody Leonhard reports, retail hard drive prices are still about 75 percent higher than they were before the flood and show no signs of coming down. And the manufacturers are posting healthy profits as a result.

Nobody is shocked by this right?

Unfortunately for them, this will be short lived. The major HDD manufacturers don’t really have great penetration in the SSD market, which is growing at an amazing rate due to dropping prices and people wanting faster boot times.

Hiking pricing, unwillingness to adapt product lineup to meet demand. I think we know where this business strategy leads.

Long Weekend

Today is a long weekend for every country on earth. Enjoy the extra long weekend!

Ok, it’s not a true 3 day weekend, but there will be a leap second inserted Saturday night at midnight, giving this weekend an extra second compared to all the other weekends. So enjoy the extra time off from work.

Perception Of Performance

Google is pervasive about associating Chrome with being fast. It’s was their primary pitch when they first announced it. Back when Firefox went 1.0, it wasn’t so much about speed but “not sucking” as all the geeks liked to say. Given IE 6 was the competition, that was likely the best marketing on earth. Sure it was faster, but sucking fast wasn’t nearly as good as not sucking. Not sucking encompassed the missing features, broken rendering, crashing, constant parade of security problems. It summarized the product surprisingly well for not being an official slogan by any means.

Google now launched Chrome for iOS. On the desktop Chrome and Safari both use WebKit, Chrome applies it’s own touches to make things faster. Notably they have their own JS engine. Safari also has it’s own JS engine. This is the secret sauce of performance. In the iOS world however Apple being the totalitarian dictator decided that iOS will provide WebKit and JS. If your app has any web browser functionality it will utilize these API’s and not implement it’s own engine. Verbatim:

2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript

Google Chrome for iOS however is Google integration into a reskinned experience of Safari. It’s the same browser. Just a new UI bolted on with some Google features integrated in. It’s not a separate browser. It’s a UI.

That however doesn’t stop Google’s marketing machine (I’d argue Apple marketing’s top rival) from putting “fast” as the second word:

Browse fast with Chrome, now available on your iPhone, iPod touch and iPad. Sign in to sync your personalized Chrome experience from your computer, and bring it with you anywhere you go.

It goes on to clarify:

  • Search and navigate fast, directly from the same box. Choose from results that appear as you type.

So Google isn’t truly misleading. It’s just very strategic wording.

The truth of the matter however is that Google Chrome on iOS is substantially slower than Safari. Safari uses Nitro to accelerate JavaScript, which powers most of the complicated websites that will slow down a browser on any modern device. Apple however restricts Nitro to Safari, and doesn’t let third party apps like Google Chrome use it. This is still the case as of iOS 5, and I believe is the case in iOS 6, though I haven’t personally verified that.

How much slower is Google Chrome on iOS in comparison to Safari? Well Here’s a SunSpider test I did on my iPad 3:

Safari

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 1817.9ms +/- 0.2%
--------------------------------------------

3d: 214.7ms +/- 1.1%
cube: 72.3ms +/- 0.7%
morph: 57.9ms +/- 0.9%
raytrace: 84.5ms +/- 2.2%

access: 224.9ms +/- 0.6%
binary-trees: 44.4ms +/- 1.7%
fannkuch: 96.2ms +/- 0.6%
nbody: 56.0ms +/- 0.0%
nsieve: 28.3ms +/- 2.7%

bitops: 141.0ms +/- 0.4%
3bit-bits-in-byte: 23.4ms +/- 1.6%
bits-in-byte: 29.5ms +/- 1.3%
bitwise-and: 37.8ms +/- 1.5%
nsieve-bits: 50.3ms +/- 0.7%

controlflow: 15.7ms +/- 2.2%
recursive: 15.7ms +/- 2.2%

crypto: 123.3ms +/- 0.6%
aes: 70.5ms +/- 0.5%
md5: 29.4ms +/- 1.3%
sha1: 23.4ms +/- 1.6%

date: 274.4ms +/- 0.7%
format-tofte: 139.8ms +/- 1.1%
format-xparb: 134.6ms +/- 0.7%

math: 175.1ms +/- 0.3%
cordic: 61.5ms +/- 0.8%
partial-sums: 74.4ms +/- 0.7%
spectral-norm: 39.2ms +/- 0.8%

regexp: 70.8ms +/- 0.6%
dna: 70.8ms +/- 0.6%

string: 578.0ms +/- 0.5%
base64: 78.3ms +/- 1.9%
fasta: 68.1ms +/- 0.9%
tagcloud: 109.5ms +/- 1.2%
unpack-code: 207.5ms +/- 1.2%
validate-input: 114.6ms +/- 0.7%

Google Chrome

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 7221.0ms +/- 0.1%
--------------------------------------------

3d: 802.7ms +/- 0.2%
cube: 230.9ms +/- 0.6%
morph: 297.3ms +/- 0.5%
raytrace: 274.5ms +/- 0.1%

access: 1112.0ms +/- 0.2%
binary-trees: 98.4ms +/- 1.1%
fannkuch: 609.6ms +/- 0.2%
nbody: 247.9ms +/- 0.2%
nsieve: 156.1ms +/- 0.4%

bitops: 957.2ms +/- 0.2%
3bit-bits-in-byte: 210.4ms +/- 0.6%
bits-in-byte: 232.9ms +/- 0.2%
bitwise-and: 188.5ms +/- 0.4%
nsieve-bits: 325.4ms +/- 0.2%

controlflow: 129.5ms +/- 0.3%
recursive: 129.5ms +/- 0.3%

crypto: 493.3ms +/- 0.2%
aes: 214.3ms +/- 0.4%
md5: 140.2ms +/- 0.3%
sha1: 138.8ms +/- 0.5%

date: 381.1ms +/- 0.3%
format-tofte: 214.2ms +/- 0.2%
format-xparb: 166.9ms +/- 0.5%

math: 770.7ms +/- 0.2%
cordic: 316.6ms +/- 0.2%
partial-sums: 243.2ms +/- 0.3%
spectral-norm: 210.9ms +/- 0.4%

regexp: 1340.2ms +/- 0.2%
dna: 1340.2ms +/- 0.2%

string: 1234.3ms +/- 0.6%
base64: 175.7ms +/- 0.5%
fasta: 205.6ms +/- 0.2%
tagcloud: 284.0ms +/- 2.3%
unpack-code: 370.1ms +/- 0.9%
validate-input: 198.9ms +/- 0.6%

Quite a bit slower.

So really, if you’re using Chrome on iOS, it’s because you absolutely love the design and integration with Google’s services, and are willing to trade off considerable JavaScript performance for those perks.

That however doesn’t stop many people from thinking it’s fast. Just in the past few minutes I’m able to find these Tweets among the thousands streaming across the web. I won’t mention or link to them directly (you could find them however if you wanted):

“Chrome for iOS is FAST, takes the mobile browsing experience to a new level.”

“I like it! It’s fast and can sync with Chrome desktop, which I use all of the time.”

“Liking #chrome on #iOS very slick, fast and clean looking”

“using chrome on my iphone right now.. cant believe how fast it is”

“That chrome for iOS is freaking fast but so basic. No tweet button, no add-on. Man I kinda disappointed. I give ’em 1 ‘fore the update”

“Chrome for iOS? Hell yes!! So fast! #chrome”

“Google Chrome for iOS is fast.”

“Holy hell Chrome is fast on the iPad.”

The most touted feature isn’t actually a feature. It’s technically not even there. The numbers and the technology insist that it’s not (they prove it’s actually slower). But that’s what everyone is ranting and raving about. You could argue Google’s UI is faster, but I’d be highly skeptical that Google’s found Cocoa tricks Apple engineers haven’t. Perhaps a UI transition or two makes you think it’s faster or more responsive, however even that I can’t find any evidence of.

All the hard work the Google engineers did squeezing their services into a compact simple to use UI are ignored in favor of this non-existent feature. And as a developer who can’t ignore such a thing, I will say they did a great job with their UI.

I present to you, the power of marketing!

On Google’s Made In In The U.S.A. Experiment

Google is reportedly building the Nexus Q in the USA. It’s almost assumed these days that electronics are made in China, with a few notable exceptions in Japan or South Korea. However when you think about it, it makes sense. Consumer technology has come full circle.

Open up some electronics made before 1985. With rare exception, they look almost foreign by todays standards. They are spartan in design. Big circuit boards with a few components, some wires to peripheral lights, motors, whatever the device needs to do it’s thing. It’s almost elementary to figure out how it works. Even fixing it is well within reason.

Now open up a modern device like a modern cell phone. It’s generally a single highly concentrated circuit board with a mess of finely placed parts on and around it. Every year they get smaller and more complicated. Until recently.

A curious thing started to happen. Electronics in an attempt to use less power, become cheaper to manufacture, started simplifying their designs. Kind of. They consolidated many of their parts. For example the complex set of layers in a cell phones screen that separated the backlight from LCD panel from the digitizer were made into one slim component. Multiple chips were combined into a system on chip (SoC). Common things like WiFi a Bluetooth which are almost never exclusive were on one chip. Devices became simpler.

Most of these individual components are manufactured through highly automated means. For example those LCD panels are not made by hand, they are made by machines because a high level of precision is needed. No human etches a CPU or any other chip. Even soldering is increasingly machine driven as most use surface mount techniques like ball grid array which would be nearly impossible to do by hand with anywhere near the accuracy or speed needed.

The result is that these components are made increasingly by machines. These components are assembled increasingly by machines. This changes the equation when it comes to deciding where to manufacturer. The biggest advantage to China was very cheap skilled labor. This is changing. First of all China is starting to become more expensive as affluence builds in China. More notably, the need for labor is able to decrease as designs become more machine centric. While the iPhone is very labor intensive today, but don’t expect it to stay that way. It’s increasingly simplifying it’s design despite pushing the limits. Energy costs and shipping costs are also changing.

Google’s bet is that they’ve simplified the human part of manufacturing to the point where the labor costs are becoming minimal. It’s a reasonable bet. If you look closely at the photos in the NY Times piece, you’ll see lots of humans posing, and a few doing actual tasks related to assembling. Of those assembling, there’s no mention on if they are working on prototypes, or if they are in full scale production (which may involve less humans and more automation).

Factory automation will increasingly bring hardware manufacturing back to the US. But don’t expect to see the jobs of the 1980’s coming back with it. These will be highly automated facilities run by engineers and supervised by increasingly limited staff. They may one day operate like data centers.

Price Manipulation On The Web

And in today’s ecommerce news:

Orbitz Worldwide Inc. has found that people who use Apple Inc.’s Mac computers spend as much as 30% more a night on hotels, so the online travel agency is starting to show them different, and sometimes costlier, travel options than Windows visitors see.

The idea being that Mac users, which tend to be of higher income are more willing to spend than their PC counterparts.

It’s important to note that this sort of manipulation is nothing new. Websites regularly optimize content based on the user. If you live in an affluent city like New York, San Francisco, or Los Angeles, as determined by your IP address you may be offered a different (often more expensive) price. Repeat customers (cookies help here) may not see all the price cutting someone coming in from a search engine might. Search referrers might be offered a lower price since they are already looking at competitors.

Then of course is the obvious problem with travel sites. They are based on systems like SABRE which have a long history of bias (and rules against them have since expired in the US as far as I’m aware). Expecting a travel site to reliably offer you the lowest price is like expecting a tiger to leave the helpless gazelle alone. They are for convenience, not the best deal.

This would have been slightly ironic had it been Expedia, who was originally a division of Microsoft.