In June 1977 Apple Computer shipped their first mass-market computer: the Apple II.
Unlike the Apple I, the Apple II was fully assembled and ready to use
with any display monitor. The version with 4K of memory cost $1298. It
had color, graphics, sound, expansion slots, game paddles, and a
built-in BASIC programming language.
What it didn’t have was a disk drive. Programs and data had to be
saved and loaded from cassette tape recorders, which were slow and
unreliable. The problem was that disks – even floppy disks – needed both
expensive hardware controllers and complex software.
Steve Wozniak solved the first problem. He
designed an incredibly clever floppy disk controller using only 8
integrated circuits, by doing in programmed logic what other controllers
did with hardware. With some
rudimentary software written by Woz and Randy Wigginton, it was
demonstrated at the Consumer Electronics Show in January 1978.
But where were they going to get the higher-level software to
organize and access programs and data on the disk? Apple only had about
15 employees, and none of them had both the skills and the time to work
on it.
The magician who pulled that rabbit out of the hat was Paul Laughton,
a contract programmer for Shepardson Microsystems, which was located in
the same Cupertino office park as Apple.
On April 10, 1978 Bob Shepardson and Steve Jobs signed a $13,000
one-page contract for a file manager, a BASIC interface, and utilities.
It specified that “Delivery will be May 15?, which was incredibly
aggressive. But, amazingly, “Apple II DOS version 3.1? was released in
June 1978.
The cloud storage scene has heated up recently, with a long-awaited
entry by Google and a revamped SkyDrive from Microsoft. Dropbox has gone
unchallenged by the major players for a long time, but that’s changed –
both Google and Microsoft are now challenging Dropbox on its own turf,
and all three services have their own compelling features. One thing’s
for sure – Dropbox is no longer the one-size-fits-all solution.
These three aren’t the only cloud storage services – the cloud
storage arena is full of services with different features and
priorities, including privacy-protecting encryption and the ability to
synchronize any folder on your system.
Dropbox
introduced cloud storage to the masses, with its simple approach to
cloud storage and synchronization – a single magic folder that follows
you everywhere. Dropbox deserves credit for being a pioneer in this
space and the new Google Drive and SkyDrive both build on the foundation
that Dropbox laid.
Dropbox doesn’t have strong integration with any ecosystems – which
can be a good thing, as it is an ecosystem-agnostic approach that isn’t
tied to Google, Microsoft, Apple, or any other company’s platform.
Dropbox today is a compelling and mature offering supporting a wide
variety of platforms. Dropbox offers less free storage than the other
services (unless you get involved in their referral scheme) and its
prices are significantly higher than those of competing services – for
example, an extra 100GB is four times more expensive with Dropbox compared to Google Drive.
Price for Additional Storage: 50 GB for $10/month, 100 GB for $20/month.
File Size Limit: Unlimited.
Standout Features: the Public folder is an easy way to share files.
Other services allow you to share files, but it isn’t quite as easy.
You can sync files from other computers running Dropbox over the local
network, speeding up transfers and taking a load off your Internet
connection.
Google Drive is the evolution of Google Docs,
which already allowed you to upload any file – Google Drive bumps the
storage space up from 1 GB to 5 GB, offers desktop sync clients, and
provides a new web interface and APIs for web app developers.
Google Drive is a serious entry from Google, not just an afterthought like the upload-any-file option was in Google Docs.
Its integration with third-party web apps – you can install apps and
associate them with file types in Google Drive – shows Google’s vision
of Google Drive being a web-based hard drive that eventually replaces
the need for desktop sync clients entirely.
Like Google with Google Drive, Microsoft’s new SkyDrive product imitates the magic folder pioneered by Dropbox.
Microsoft offers the most free storage space at 7 GB – although this is down from the original 25 GB. Microsoft also offers good prices for additional storage.
Supported Platforms: Windows, Mac, Windows Phone, iOS, Web.
Free Storage: 7 GB.
Price for Additional Storage: 20 GB for $10/year, 50 GB for $25/year, 100 GB for $50/year
File Size Limit: 2 GB
Standout Features: Ability to fetch unsynced files from outside the synced folders on connected PCs, if they’ve been left on.
Other Services
SugarSync is a popular
alternative to Dropbox. It offers a free 5 GB of storage and it lets you
choose the folders you want to synchronize – a feature missing in the
above services, although you can use some tricks
to synchronize other folders. SugarSync also has clients for mobile
platforms that don’t get a lot of love, including Symbian, Windows
Mobile, and Blackberry (Dropbox also has a Blackberry client).
Amazon also offers their own cloud storage service, known as Amazon Cloud Drive.
There’s one big problem, though – there’s no official desktop sync
client. Expect Amazon to launch their own desktop sync program if
they’re serious about competing in this space. If you really want to use Amazon Cloud Drive, you can use a third-party application to access it from your desktop.
Box is popular, but its 25 MB file
size limit is extremely low. It also offers no desktop sync client
(except for businesses). While Box may be a good fit for the enterprise,
it can’t stand toe-to-toe with the other services here for consumer
cloud storage and syncing.
If you’re worried about the privacy of your data, you can use an encrypted service, such as SpiderOak or Wuala, instead. Or, if you prefer one of these services, use an app like BoxCryptor to encrypt files and store them on any cloud storage service.
While Apple and Google are busy getting bad press for their privacy
issues, labor practices and general big-evil-company wrongdoings,
Microsoft has done some brand regeneration, making it look like the
hippest tech company on the block these days. As Apple and Google
captured a younger, cooler demographic, the Windows maker, with its
stodgy business oriented PC-compatible operating system and notoriously
annoying browser, became synonymous with lameness. Remember all those
highly effective Mac versus PC commercials?
That PC dork (writer-performer John Hodgman) represented all things
Microsoft: Slow, uptight, badly dressed. But as Apple and Google have
grown up, they've lost their hip sheen. And, Microsoft's taking
advantage. In this era of awesomely bad, it doesn't look so lame anymore
-- especially in comparison to the other guys.
We noticed this new-found hipness when we came across the endearing Browser You Love(d) to Hate
campaign. With some admirable self-awareness, Microsoft used its own
bad reputation to argue that its hated Internet Explorer browser is on
the verge of a comeback. Layering on the hipster-irony, Microsoft
compares itself to once-passe things like PBR and mustaches, suggesting
it's just another brand that's so bad, it's cool again. It also doesn't
hurt that the overall look of the site matches that aesthetic. The Atlantic's own mustachio-ed tech man, Alexis Madrigal gave it his approval, callingthis accompanying ad "definitely the funniest commercial Microsoft's ever put out." We agreed, finding the whole thing convincing enough to give our abandoned IE9 a try again. (We still prefer Chrome, by the way.)
But this image comeback isn't limited to IE. Over the last few days we've seen Hotmail ads running on Boing Boing and Jezebel,
two blogs that are hip for different reasons. Boing Boing catering to
the hippest of Internet lovers and Jezebel reaches a more mainstream but
still cool millennial audience. And in general, the overall
Microsoft-related press has been kind of good. Windows 8 surprised and excited
the tech blogger world, something a Windows browser hasn't done since
Windows 95. The company has some other exciting things going on inside
its labs. The other day, It did some Internet good with its Digital Crimes Unit. And, has even designed itself a decent looking logo. Apple's (maybe) new logo, on the other hand, with its rainbow mish-mash, feels dated.
Which brings us to the other aspect of Microsoft's renaissance: good
timing. The once-hipper than Microsoft foes, Google and Apple haven't
looked so good these days. Google, the once beloved search company, has
users uneasy with its Google+ integration, privacy issues and anti-trust concerns. Even Googlers aren't too sure
of Google's mission, these days. Appl still produces insane-popular
gadgets, but no longer wows reviewers like it once did. The new iPad is
still the best tablet out there, but it's not a must-have. Plus, it too
has gotten itself into its own privacy messes. It also had the misfortune of acting as the face of the last few months of Foxconn scandal.
Though the Foxconn protesters that threatened mass suicide back in
January made Microsoft's XBox, thanks to Mike Daisey and Apple's
financial successes, Apple not Microsoft absorbed most of the bad PR.
Part of this has to do with maturity, we suppose. An early bloomer,
Microsoft's already went through its tech company growing pains. It used
to be the evil one, remember? The one accused of monopolistic practices, of buying up the competition, of stifling innovation. But
it's no longer the bully. Google and Apple's misdeeds have
overshadowed the once dominant tech company, and while the other big
players make public messes out of themselves, Microsoft looks to be
cleaning up its image. And, we have to say, it looks good.
Workers assemble and perform quality control checks on MacBook Pro display enclosures at an Apple supplier facility in Shanghai.
(Credit:
Apple)
A new report on Apple offers up an interesting detail about the evolution of the
iPhone and gives a fascinating--and unsettling--look at the practice of overseas manufacturing.
The article, an in-depth report
by Charles Duhigg and Keith Bradsher of The New York Times, is based on
interviews with, among others, "more than three dozen current and
former Apple employees and contractors--many of whom requested anonymity
to protect their jobs."
The piece uses Apple and its recent history to look at why the
success of some U.S. firms hasn't led to more U.S. jobs--and to examine
issues regarding the relationship between corporate America and
Americans (as well as people overseas). One of the questions it asks is:
Why isn't more manufacturing taking place in the U.S.? And Apple's
answer--and the answer one might get from many U.S. companies--appears
to be that it's simply no longer possible to compete by relying on
domestic factories and the ecosystem that surrounds them.
The iPhone detail crops up relatively early in the story, in an
anecdote about then-Apple CEO Steve Jobs. And it leads directly into
questions about offshore labor practices:
In 2007, a little over a month before the iPhone was
scheduled to appear in stores, Mr. Jobs beckoned a handful of
lieutenants into an office. For weeks, he had been carrying a prototype
of the device in his pocket.
Mr. Jobs angrily held up his iPhone, angling it so everyone could see
the dozens of tiny scratches marring its plastic screen, according to
someone who attended the meeting. He then pulled his keys from his
jeans.
People will carry this phone in their pocket, he said. People also carry
their keys in their pocket. "I won't sell a product that gets
scratched," he said tensely. The only solution was using unscratchable
glass instead. "I want a glass screen, and I want it perfect in six
weeks."
A tall order. And another anecdote suggests that Jobs' staff went
overseas to fill it--along with other requirements for the top-secret
phone project (code-named, the Times says, "Purple 2"):
One former executive described how the company relied
upon a Chinese factory to revamp iPhone manufacturing just weeks before
the device was due on shelves. Apple had redesigned the iPhone's screen
at the last minute, forcing an assembly line overhaul. New screens began
arriving at the plant near midnight.
A foreman immediately
roused 8,000 workers inside the company's dormitories, according to the
executive. Each employee was given a biscuit and a cup of tea, guided to
a workstation and within half an hour started a 12-hour shift fitting
glass screens into beveled frames. Within 96 hours, the plant was
producing more than 10,000 iPhones a day.
"The speed and flexibility is breathtaking," the executive said. "There's no American plant that can match that."
That last quote there, like several others in the story, leaves one
feeling almost impressed by the no-holds-barred capabilities of these
manufacturing plants--impressed and queasy at the same time. Here's
another quote, from Jennifer Rigoni, Apple's worldwide supply demand
manager until 2010: "They could hire 3,000 people overnight," she says,
speaking of Foxconn City, Foxconn Technology's complex of factories in China. "What U.S. plant can find 3,000 people overnight and convince them to live in dorms?"
The article says that cheap and willing labor was indeed a factor in
Apple's decision, in the early 2000s, to follow most other electronics
companies in moving manufacturing overseas. But, it says, supply chain
management, production speed, and flexibility were bigger incentives.
"The entire supply chain is in China now," the article quotes a
former high-ranking Apple executive as saying. "You need a thousand
rubber gaskets? That's the factory next door. You need a million screws?
That factory is a block away. You need that screw made a little bit
different? It will take three hours."
It also makes the point that other factors come into play. Apple
analysts, the Times piece reports, had estimated that in the U.S., it
would take the company as long as nine months to find the 8,700
industrial engineers it would need to oversee workers assembling the
iPhone. In China it wound up taking 15 days.
The article and its sources paint a vivid picture of how much easier
it is for companies to get things made overseas (which is why so many
U.S. firms go that route--Apple is by no means alone in this). But the
underlying humanitarian issues nag at the reader.
Perhaps there's hope--at least for overseas workers--in last week's news that Apple has joined the Fair Labor Association, and that it will be providing more transparency when it comes to the making of its products.
As for manufacturing returning to the U.S.? The Times piece cites an unnamed guest at President Obama's 2011 dinner with Silicon Valley bigwigs.
Obama had asked Steve Jobs what it would take to produce the iPhone in
the states, why that work couldn't return. The Times' source quotes Jobs
as having said, in no uncertain terms, "Those jobs aren't coming back."
Apple, by the way, would not provide a comment to the Times about
the article. And Foxconn disputed the story about employees being
awakened at midnight to work on the iPhone, saying strict regulations
about working hours would have made such a thing impossible.
One of the best things about Steve Jobs’ return to Apple
— which will live on and benefit society long after Jobs’ death — is
how he basically spent the last 14 years teaching thousands of Apple
employees to have incredibly high standards and to build amazing
products.
Perhaps more importantly, through Apple’s products,
Steve also taught hundreds of millions of consumers to expect and demand
amazing things.
For now, many of those Apple colleagues —
especially the ones who worked most closely with Steve — still work
there. But over time, more will leave to start their own companies or
launch new projects. And some of those companies will make some really
cool things completely outside the consumer electronics industry,
reflecting both the work of their founders and also a little bit of
Steve Jobs.
Yes, it’s not the first
thermostat on the market that uses software to “learn” how to heat and
cool your house properly, just as the iPod wasn’t the first MP3 player
on the market. But it looks great, seems to have a user interface that
is well ahead of the competition, reflects modern software and
networking capabilities, and has an aspirational brand that I have never
seen in a thermostat before.
Did I mention it looks great? See this video on TechCrunch
where Fadell explains the attention to detail they put into the Nest,
designing the outer metal ring to act as a sort-of mirror, helping the
thermostat take on and blend into the colors of the wall behind it. This
isn’t just a fancy and functional thermostat, it’s a beautiful one. Go
to the “thermostats” page on the Home Depot website –
I’ve sorted the results to put the most expensive ones at the top of
the page — and see a bunch of white plastic boxes with black-and-green
LCD displays. And now you see why the Nest thermostat is exciting people
today.
More
than anything, this reminds me of the slide of 2006-era smartphones —
Motorola Q, BlackBerry Pearl, Palm Treo, Nokia E-something-something –
that Steve Jobs displayed before he introduced the iPhone for the first
time. Night and day.
Anyway, the Nest is, of course, just one example. It might not even work — it could be a flop. Who knows. That’s not the point.
The
idea is that, going forward, integrated hardware, software, and
Internet services — the model that Apple has really gotten good at — are
going to take over more industries than just computers and pocket
gadgets. Everything from your phone (already done, if you have an
iPhone) to your car (in progress) to your thermostat (see above) to
far-flung sectors of industry and commerce. If it hasn’t been
re-imagined yet, it will be eventually.
And while Apple can’t and won’t make all of that stuff
itself — part of what makes Apple so successful is its carefully
limited domain and obsessive focus — people who worked there and learned
from Steve Jobs can. And they increasingly will. And it could be great
for all of us.
In the beginning, there was the web and you accessed it though the
browser and all was good. Stuff didn’t download until you clicked on
something; you expected cookies to be tracking you and you always knew
if HTTPS was being used. In general, the casual observer had a pretty
good idea of what was going on between the client and the server.
Not
so in the mobile app world of today. These days, there’s this great big
fat abstraction layer on top of everything that keeps you pretty well
disconnected from what’s actually going on. Thing is, it’s a trivial
task to see what’s going on underneath, you just fire up an HTTP proxy
like Fiddler, sit back and watch the show.
Let
me introduce you to the seedy underbelly of the iPhone, a world where
not all is as it seems and certainly not all is as it should be.
There’s no such thing as too much information – or is there?
Here’s
a good place to start: conventional wisdom says that network efficiency
is always a good thing. Content downloads faster, content renders more
quickly and site owners minimise their bandwidth footprint. But even
more importantly in the mobile world, consumers are frequently limited
to fairly meagre download limits, at least by today’s broadband
standards. Bottom line: bandwidth optimisation in mobile apps is very important, far more so than in your browser-based web apps of today.
Let me give you an example of where this all starts to go wrong with mobile apps. Take the Triple M app, designed to give you a bunch of info about one of Australia’s premier radio stations and play it over 3G for you. Here’s how it looks:
Where it all starts to go wrong is when you look at the requests being made just to load the app, you’re up to 1.3MB alone:
Why?
Well, part of the problem is that you’ve got no gzip compression.
Actually, that’s not entirely true, some of the small stuff is
compressed, just none of the big stuff. Go figure.
But there’s
also a lot of redundancy. For example, on the app above you can see the
first article titled “Manly Sea Eagles’ 2013 Coach…” and this is
returned in request #2 as is the body of the story. So far, so good. But
jump down to request #19 – that massive 1.2MB one – and you get the
whole thing again. Valuable bandwidth right out the window there.
Now
of course this app is designed to stream audio so it’s never going to
be light on bandwidth (as my wife discovered when she hit her cap “just
by listening to the radio”), and of course some of the upfront load is
also to allow the app to respond instantaneously when you drill down to
stories. But the patterns above are just unnecessary; why send redundant
data in an uncompressed format?
Here’s a dirty Foxtel secret;
what do you reckon it costs you in bandwidth to load the app you see
below? A few KB? Maybe a hundred KB to pull down a nice gzipped JSON
feed of all the channels? Maybe nothing because it will pull data on
demand when you actually do something?
Guess again, you’ll be needing a couple of meg just to start the app:
Part
of the problem is shown under the Content-Type heading above; it’s
nearly all PNG files. Actually, it’s 134 PNG files. Why? I mean what on
earth could justify nearly 2 meg of PNGs just to open the app? Take a
look at this fella:
This is just one of the actual images at original size. And why is this humungous PNG required? To generate this screen:
Hmmm, not really a use case for a 425x243, 86KB PNG. Why? Probably because as we’ve seen before,
developers like to take something that’s already in existence and
repurpose it outside its intended context, and just as in that
aforementioned link, this can start causing all sorts of problems.
Unfortunately it makes for an unpleasant user experience as you sit
there waiting for things to load while it does unpleasant things to your
(possibly meagre) data allocation.
But we’re only just warming up. Let’s take a look at the very excellent, visually stunning EVO magazine on the iPad. The initial screen is just a list of editions like so:
Let’s
talk in real terms for a moment; the iPad resolution is 1024x768 or
what we used to think of as “high-res” not that long ago. The image
above has been resized down to about 60% of original but on the iPad,
each of those little magazine covers was originally 180x135 which even
saved as a high quality PNG, can be brought down well under 50KB apiece.
However:
Thirteen and a half meg?! Where an earth did all that go?! Here’s a clue:
Go on, click it, I’ll wait.
Yep, 1.6MB.
4,267 pixels wide, 3,200 pixels high.
Why?
I have no idea, perhaps the art department just sent over the originals
intended for print and it was “easy” to dump that into the app. All you
can do in the app without purchasing the magazine (for which you expect
a big bandwidth hit), is just look at those thumbnails. So there you
go, 13.5MB chewed out of your 3G plan before you even do anything just
because images are being loaded with 560 times more pixels than they
need.
The secret stalker within
Apps you install
directly onto the OS have always been a bit of a black box. I mean it’s
not the same “view source” world that we've become so accustomed to with
the web over the last decade and a half where it’s pretty easy to see
what’s going on under the covers (at least under the browser covers).
With the volume and affordability of iOS apps out there, we’re now well
and truly back in the world of rich clients which performs all sorts of
things out of your immediate view, and some of them are rather
interesting.
Let’s take cooking as an example; the ABC Foodi app is a beautiful piece of work. I mean it really is visually delightful and a great example of what can be done on the iPad:
But
it’s spying on you and phoning home at every opportunity. For example,
you can’t just open the app and start browsing around in the privacy of
your own home, oh no, this activity is immediately reported (I’m
deliberately obfuscating part of the device ID):
Ok, that’s a mostly innocuous, but it looks like my location – or at least my city
– is also in there so obviously my movements are traceable. Sure, far
greater location fidelity can usually be derived from the IP address
anyway (and they may well be doing this on the back end), but it’s
interesting to see this explicitly captured.
Let’s try something else, say, favouriting a dish:
Not the asparagus!!! Looks like you can’t even create a favourite
without your every move being tracked. But it’s actually even more than
that; I just located a nice chocolate cake and emailed it to myself
using the “share” feature. Here’s what happened next:
The app tracks your every moveand sends it back to base in small batches. In this case, that base is at flurry.com, and who are these guys? Well it’s quite clear from their website:
Flurry powers acquisition, engagement and monetization for the new
mobile app economy, using powerful data and applying game-changing
insight.
Here’s something I’ve seen before: POST requests to data.flurry.com. It’s perfectly obvious when you use the realestate.com.au iPad app:
Uh, except it isn’t really obvious, it’s another sneaky backdoor to
help power acquisitions and monetise the new app economy with
game-changing insight. Here’s what it’s doing and clearly it has nothing
to do with finding real estate:
Hang on – does that partially obfuscated device ID look a bit
familiar?! Yes it does, so Flurry now knows both what I’m cooking and
which kitchen I’d like to be cooking it in. And in case you missed it,
the first request when the Foxtel app was loaded earlier on was also to
data.flurry.com. Oh, and how about those travel plans with TripIt – the cheerful blue sky looks innocuous enough:
But under the covers:
Suddenly monetisation with powerful data starts to make more sense.
But this is no different to a tracking cookie on a website, right?
Well, yes and no. Firstly, tracking cookies can be disabled. If you
don’t like ‘em, turn ‘em off. Not so the iOS app as everything is hidden
under the covers. Actually, it’s in much the same way as a classic app
that gets installed on any OS although in the desktop world, we’ve
become accustomed to being asked if we’re happy to share our activities “for product improvement purposes”.
These privacy issues simply come down to this: what does the user
expect? Do they expect to be tracked when browsing a cook book installed
on their local device? And do they expect this activity to be
cross-referenceable with the use of other apparently unrelated apps? I
highly doubt it, and therein lays the problem.
Security? We don’t need no stinkin’ security!
Many people are touting mobile apps as the new security frontier, and rightly so IMHO. When I wrote about Westfield
last month I observed how easy it was for the security of services used
by apps to be all but ignored as they don’t have the same direct public
exposure as the apps themselves. A browse through my iPhone collection
supports the theory that mobile app security is taking a back seat to
their browser-based peers.
Let’s take the Facebook app. Now to be honest, this one surprised me a
little. Back in Jan of this year, Facebook allowed opt-in SSL or in or in the words of The Register,
this is also known as “Turn it on yourself...bitch”. Harsh, but fair –
this valuable security feature was going to be overlooked by many, many
people. “SS what?”
Unfortunately, the very security that is offered to browser-based
Facebook users is not accessible on the iPhone client. You know, the
device which is most likely to be carried around to wireless hotspots
where insecure communications are most vulnerable. Here’s what we’re
left with:
This is especially surprising as that little bit of packet-sniffing magic that is Firesheep was no doubt the impetus for even having the choice of enable SSL. But here we are, one year on and apparently Facebook is none the wiser.
Let’s change pace a little and take a look inside the Australian Frequent Flyer app.
This is “Australia's leading Frequent Flyer Community” and clearly a
community of such standing would take security very, very seriously.
Let’s login:
As with the Qantas example above, you have absolutely no idea
how these credentials are being transported across the wire. Well,
unless you have Fiddler then it’s perfectly clear they’re just being
posted to this HTTP address: http://www.australianfrequentflyer.com.au/mobiquo-withsponsor/mobiquo.php
And of course it’s all very simple to see the post body which in this case, is little chunk of XML:
Bugger, clearly this is going to tack some sort of hacker mastermind
to figure out what these credentials are! Except it doesn’t, it just
takes a bit of Googling. There are two parameters and they’re both Base64
encoded. How do we know this? Well, firstly it tells us in one of the
XML nodes and secondly, it’s a pretty common practice to encode data in
this fashion before shipping it around the place (refer the link in this
paragraph for the ins and outs of why this is useful).
So we have a value of “YWJjMTIz” and because Base64 is designed to allow for simple encoding and decoding (unlike a hash which is a one way process), you can simply convert this back to plain text using any old Base64 decoder. Here’s an online one right here and it tells us this value is “abc123”. Well how about that!
The next value is “NzA1ZWIyOThiNjQ4YWM1MGZiNmUxN2YzNjY0Yjc4ZTI=”
which is obviously going to be the password. Once we Base64 decode this,
we have something a little different:
“705eb298b648ac50fb6e17f3664b78e2?”. Wow, that’s an impressive password!
Except that as we well know, people choosing impressive passwords is a
very rare occurrence indeed so in all likelihood this is a hash. Now
there are all sorts of nifty brute forcing tools out there but when it
comes to finding the plain text of a hash, nothing beats Google. And
what does the first result Google gives us? Take a look:
I told you that was a useless password
dammit! You see the thing is, there’s a smorgasbord of hashes and their
plain text equivalents just sitting out there waiting to be searched
which is why it’s always important to apply a cryptographically random salt to the plain text before hashing. A straight hash of most user-created passwords – which we know are generally crap – can very frequently be resolved to plain text in about 5 seconds via Google.
The bottom line is that this is almost no better than plain
text credentials and it’s definitely no alternative to transport layer
security. I’ve had numerous conversations with developers before trying
to explain the difference between encoding, hashing and encryption and
if I were to take a guess, someone behind this thinks they’re
“encrypted” the password. Not quite.
But is this really any different to logging onto the Australian Frequent Flyer website
which also (sadly) has no HTTPS? Yes, what’s different is that firstly,
on the website it’s clear to see that no HTTPS has been employed, or at
least not properly employed (the login form isn’t loaded over HTTPS). I
can then make a judgement call on the trust and credibility of the
site; I can’t do that with the app. But secondly, this is a mobile app – a mobile travel
app – you know, the kind of thing that’s going to be used while roaming
around wireless hotspots vulnerable to eavesdropping. It’s more
important than ever to protect sensitive communications and the app
totally misses the mark on that one.
While we’re talking travel apps, let’s take another look at Qantas. I’ve written about these guys before, in fact they made my Who’s who of bad password practices list earlier in the year. Although they made a small attempt at implementing security by posting to SSL, as I’ve said before, SSL is not about encryption and loading login forms over HTTP is a big no-no. But at least they made some attempt.
So why does the iPhone app just abandon all hope and do everything
without any transport layer encryption at all? Even worse, it just
whacks all the credentials in a query string. So it’s a GET request.
Over HTTP. Here’s how it goes down:
This is a fairly typical login screen. So far, so good, although of
course there’s no way to know how the credentials are handled. At least,
that is, until you take a look at the underlying request that’s made.
Here’s those query string parameters:
Go ahead, give it a run. What I find most odd about this situation is that clearly a conscious decision was made to apply some
degree of transport encryption to the browser app, why not the mobile
app? Why must the mobile client remain the poor cousin when it comes to
basic security measures? It’s not it’s going to be used inside any
highly vulnerable public wifi hotspots like, oh I don’t know, an airport
lounge, right?
Apps continue to get security wrong. Not just iOS apps mind you,
there are plenty of problems on Android and once anyone buys a Windows
Mobile 7 device we’ll see plenty of problems on those too. It’s just too
easy to get wrong and when you do get it wrong, it’s further out of
sight than your traditional web app. Fortunately the good folks at OWASP are doing some great work around a set of Top 10 mobile security risks so there’s certainly acknowledge of the issues and work being done to help developers get mobile security right.
Summary
What I discovered about is the result of casually observing some of
only a few dozen apps I have installed on my iOS devices. There are
about half a million more out there and if I were a betting man, my
money would be the issues above only being the tip of the iceberg.
You can kind of get how these issues happen; every man and his dog
appears to be building mobile apps these days and a low bar to entry is
always going to introduce some quality issues. But Facebook? And Qantas?
What are their excuses for making security take a back seat?
Developers can get away with more sloppy or sneaky practices in mobile apps as the execution is usually further out of view.
You can smack the user with a massive asynchronous download as their
attention is on other content; but it kills their data plan.
You can track their moves across entirely autonomous apps; but it erodes their privacy.
And most importantly to me, you can jeopardise their security without
their noticing; but the potential ramifications are severe.
Outside of its remarkable sales, the real star of the iPhone 4S show
has been Siri, Apple’s new voice recognition software. The intuitive
voice recognition software is the closest to A.I. we’ve seen on a
smartphone to date.
Over the weekend I noted
that Siri has some resemblance to the IBM supercomputer, Watson, and
speculated that someday Watson would be in our pockets while the
supercomputers of the future might look a lot more like the Artificial
Intelligence we’ve read about in science fiction novels today, such as
the mysterious Wintermute from William Gibson’s Neuromancer.
Over at Wired, John Stokes explains how Siri and the Apple cloud could lead to the advent of a real Artificial Intelligence:
In
the traditional world of canned, chatterbot-style “AI,” users had to
wait for a software update to get access to new input/output pairs. But
since Siri is a cloud application, Apple’s engineers can continuously
keep adding these hard-coded input/output pairs to it. Every time an
Apple engineer thinks of a clever response for Siri to give to a
particular bit of input, that engineer can insert the new pair into
Siri’s repertoire instantaneously, so that the very next instant every
one of the service’s millions of users will have access to it. Apple
engineers can also take a look at the kinds of queries that are popular
with Siri users at any given moment, and add canned responses based on
what’s trending.
In this way, we can expect Siri’s repertoire of clever
comebacks to grow in real-time through the collective effort of hundreds
of Apple employees and tens or hundreds of millions of users, until it
reaches the point where an adult user will be able to carry out a
multipart exchange with the bot that, for all intents and purposes,
looks like an intelligent conversation.
Meanwhile, the technology undergirding the software and iPhone
hardware will continue to improve. Now, this may not be the AI we had in
mind, but it also probably won’t be the final word in Artificial
Intelligence either. Other companies, such as IBM, are working to
develop other ‘cognitive computers‘ as well.
And while the Singularity may indeed be far, far away, it’s still exciting to see how some forms of A.I. may emerge at least in part through cloud-sourcing.
The Apple “Let’s Talk iPhone” event has
concluded. Tim Cook and a slew of Apple execs have taken it in turns to
tell us about the latest and greatest Apple goodies, and rather
underwhelmingly there’s no iPhone 5 and just significant takeaways: a
cheaper and faster iPhone 4S, and an interesting software package called
Siri. You can read all about the iPhone 4S on our sister sites Geek and PC Mag — here we’re going to talk about Siri.
If
we look past the rather Indian (and feminine) name, Siri is a portable
(and pocketable) virtual personal assistant. She has a
speech-recognition module which works out what you’re saying, and then a
natural language parser combs through your words to work out what
you’re trying to do. Finally, an artificial intelligence gathers the
possible responses and works out which one is most likely to be
accurate, given the context, your geographical location, iOS’s current
state, and so on.
Siri
is, in essence, a computer that you can interrogate for answers, kind
of like a search engine that runs locally on your phone. If you’ve seen IBM’s Watson play Jeopardy,
Siri is basically a cut-down version. She isn’t intelligent per se, but
if she has access to enough data, she can certainly appear intelligent.
Siri’s data sources are open APIs, like Wikipedia or Wolfram Alpha, and
in theory there’s no limit to the number of sources that can be added
(though it does require significant developer time to add a new data
set). For now you can ask Siri about the weather or the definition of a
word, but in the future, if Apple links Siri up to United Airlines,
you’ll be able to book a plane ticket, just by talking. Because Siri
runs locally, she can also send SMSes or set reminders, or anything else
that Apple (or app developers) allow her to do.
Artificial
intelligence isn’t cheap in terms of processing power, though: Siri is
expected to only run on the iPhone 4S, which sports a new and
significantly faster processor than its predecessors, the A5. Siri
probably makes extensive use of Apple’s new cloud computer cluster, too,
much in the same way that Amazon Silk splits web browsing between the cloud and the local device.
Noise
That’s
enough about what Siri is and how it works. Let’s talk about whether
anyone will actually use Siri, which is fundamentally a glorified voice
control search engine. Voice commands have existed in some semblance
since at least as far back as the Nokia 3310, which was released in
2000. Almost every phone since then has had the ability to voice dial,
or in the case of modern smartphones, voice activate apps and features.
When
was the last time you saw someone talk to their phone? Driving and
other hands-otherwise-occupied activities don’t count. When was the last
time you walked down the street and heard someone loudly dictate “call
mom” into their phone? Can you really see yourself saying “Siri, I want a
kebab” in public?
It might lose its social stigma if everyone
talks to their phone, but isn’t it already annoying enough that people
swan down streets with hands-free headsets, blabbing away? It’s not like
voice recognition is at the stage where you can whisper or mumble a
command into your phone, either: you’re going to have to say, nice and
clearly, “how do I get to the bank?” in public. Now imagine that you’ve
just walked past the guy who’s talking to Siri — is he asking you for
directions, or Siri? Now imagine what it would be like if everyone
around you is having a one-sided phone conversation or talking to Siri.
Finally,
there’re practical implications to consider, which Apple usually
ignores in its press events. For example, will Siri only recognize my
voice? What if I leave my phone in the living room and my girlfriend
shouts out “honey, we should go to that Italian restaurant” — will Siri
then make a reservation? On a more nefarious note, will my wife be able
to say “Siri, show me my husband’s hidden email.” When walking down a
street, will Siri overhear other conversations and react accordingly?
Siri
will be fantastic in the car, that’s for certain. She will also be very
accommodating when you’re on your own — imagine shouting across the
room “Siri, do I need to wear a jacket today?” or “Siri, download the
latest episode of Glee.” Siri will be unusable in public, though, while
on the move — and that’s the one time where you really don’t want to be
looking down at that darn on-screen keyboard.