Mere hours after pressing ‘Publish’ on the previous mini-article concerning walled gardens, an article on TechCrunch, this morning, clarified the situation we have more or less been suspecting for a while now: that Apple, after deprecating UDIDs (one of the things they truly did well in iOS from the beginning), they will start rejecting apps after the backlash caused by lawsuits, noise and a few rogue developers that seemed keen to take advantage of their users and use their private information in ways they didn’t agree (and which are illegal in more ways than one).

The situation with unique device identifiers is an important one. On one hand, user privacy should be the number one concern of platform owners/builders like Apple, Google and Microsoft. It isn’t, for their software can do pretty much whatever it wants with the users’ private information, as we have seen several times these past few years. On the other, developers have many uses for an immutable, unique identifier for devices; from providing metrics for their own use, understanding the patterns of use of their applications, improving ad targeting, enforcing proper use of their applications and communities among others. Of course, it can also be a tool aiding in unsolicited tracking and profiling of users, of a range of personal information violations etc.

When Google came out with Android, they failed to provide any sort of unique device identifier of any significance to their developer community. They did provide several ways for developers to get some seemingly unique identifier, but those were easily modifiable, sometimes were not set at all or set to the same value across all devices sold by an OEM. In addition they would get reset after a factory wipe, etc. Developers resorted to DIY identifiers, scoured and composed from several unique component identifiers available to them by the system, such as the IMEI in phone devices, or the MAC address of the WiFi network interface in others. Then Google released Android 2.3 which included a unique identifier which, while better than the previous ones, was still not 100% robust.

Microsoft has belatedly joined the new-walled-garden era, first with Windows Phone 7 and now with Windows 8. The ‘new’ API and model for applications, Metro, goes one step further by not providing any single unique device identification capability to developers (there are some exceptions, but they are truly exceptional and as of right now undocumented). The only thing close to user/device authentication is ‘Microsoft Account’ (formerly Windows Live, Passport etc. etc.) integration which is probably useless for 99% of the cross-platform applications available out there, that have a need for some sort of unique identification of their users/devices.

It’s the permissions stupid.

The whole situation boils down to botched design in terms of permission control, abuse by advertising, analytics and developers and extremely late regulatory and social reaction to the above, perhaps combined with a pretty simple way to raise barriers to entry to the competition while ‘solving’ the issue of privacy. All platforms have some sort of privacy/permission control, but none have a good one. Android has a pretty comprehensive permission system that assumes that before installing an application each user bothers to read a silly list of permissions (many of which they will probably not understand) and once they accept they will perpetually want to grant all those permissions to said application. There is no fine grained permission control post installation, no possibility to grant or revoke individual permissions to applications before they are launched (something like “I would like to allow App X to use my network connection, but not my location or my address book data”). iOS is also similarly badly designed: there is no explicit permission asked or required for using the network connection, a slew of personal data, several APIs, storage etc., except for location, where iOS does a much better job than Android, probably because of the high-profile exposure that their data-collection ‘functionality’ took a few years ago. At the same time, both platforms actively transmit information gathered by your device, be it nearby BSSIDs (the identifiers of wifi networks, akin to ethernet MAC addresses) or Cell IDs (the unique identifiers of nearby cellular transmitter/antennae) so that they improve their ‘network-based’ geolocation service. Google fares better in this respect, as they allow you to disable this; Apple doesn’t, as far as I know.

Then comes Microsoft, the ailing software behemoth that only recently decided that Balmer’s rhetoric about the iPhone’s failings, the iPad not gaining any significant traction etc. was totally wrong after all, and that they should jump on the tablet bandwagon, not in the way they’ve been trying to do for about a decade, but the way Apple did with their own version of a walled garden, doing away with the desktop paradigm and providing a dumbed down, simpler interface that does away with compatibility, file-systems etc and uses a locked down, app store/marketplace based model to ensure software legitimacy and boost profits. So Windows Phone 7 and Windows 8 provide new sets of APIs and a new ‘application environment’ called Metro. In the Windows 8 version, the æsthetics borrow much more than its name from Windows Phone 7, the company’s revamped operating system for mobile phones that, while a decent effort, doesn’t seem to be doing that great on the market. Metro on Windows 8, however, is not a finished product by any means, and probably won’t be ‘finished’ (that is of a sufficiently high quality) until Windows 9 is released in a few years from now. Metro on Windows 8 also has permissions, like Android, but does away with unique device identifiers and any sort of meaningful API to get any sort of replacement of one. It also allows the user to revoke a permission (say, for the location), but only after the application has be executed, which kind of defeats the purpose.

My experience with the ‘next-generation’ platforms I have programmed on until now strongly suggests that the companies and people designing them have no idea about the implications of their work. They are experimenting, releasing APIs, platforms and products without thinking them through, or the impact their software has on the users, developers building applications using them or the overall social effect of their design decisions. In the case of Android, many more developers have access to IMEIs, MAC addresses and other, arguably much more sensitive information about devices and their users than they would have, had Google paid some attention and provided a unique, immutable pseudo-random unique device identifier from day one. It is also surprising how bad their permissions system is, given that they at least went through the trouble of designing one in the first place. In the case of Microsoft, the complete lack of such a mechanism, may eventually play its part in hurting the company’s efforts to enter the game (they already are extremely late). And finally, Apple, the market leader that did so many things right in the first place, is risking pissing off everybody from small independent companies that helped build the platform, to its greatest non-platform owning competitors that can see through the excuse of legal heat from regulators and the government, their hypocrisy on protecting the users’ privacy and who may call their action as an excuse to block them out of their platform. At the end of the day, the three big players in this market still get all your information, and their expansion into advertising, mobile payments, e-commerce and every single part of the software ecosystem possible means that they have the greatest incentive to (ab)use it.

In the end, all of the privacy problems that location, unique device identification and access to other personal information may give rise to are easily solvable by a modern, smart permission system that gives the user the power to deny, revoke or grant permissions to individual applications post installation, including system software/applications, thus creating a level playing field where the user would decide what kind of access to provide to whom. That would be a clear demonstration, on the platform owners’ part, that they truly care about users’ privacy and not just creating barriers to entry to the competition and their bottom line.

Yesterday a story about Apple’s unauthorised logging of timestamped location data on iPhones running iOS 4.x versions of the system software was published in several articles in technical and mainstream media worldwide. This is important, not only because of the ubiquity of location-based services available to consumers worldwide and the significance of location in safeguarding the privacy of individuals, but also because of the differences in legislation in different regions, the lack of transparency in the organisations that do gather data and the complete ignorance of those users whose data is being collected both with respect to the fact itself and the uses that they undergo.

When we first introduced AthensBook, in early 2009, we went through the ‘hassle’ of researching (with the assistance of a small legal team that advise us on legal issues) the whole topic of privacy and location in Greece and the European Union. We also observed what manufacturers, be it hardware or system software, do. To our surprise we realised the following:

• Manufacturers implicitly (and, in some cases, explicitly) ask for the users’ permission to use their location for one reason or another. Google, in its Android operating system, for example, asks for the user’s consent when he or she tries to enable Wifi/Cell-ID-based positioning. The message states that the service will anonymously gather data even when no applications make use of location services. This is Google’s way of maintaining and improving its cell triangulation and BSSID databases, important features of most modern smartphones that vastly accelerate the process positioning and, along with A-GPS, provide extremely accurate location data that would be impossible with off-line GPS devices of that size and power profile. There is no guarantee on what the company will do with the data, of course.
• People have no idea that this is happening, in most cases. We’ve had Android users ask us about the data AthensBook gathers from its users and seeming very concerned about their location being ‘sent’ to a remote server. Those same people were totally oblivious of the kind of data Google is gathering from their devices all the time, despite the fact that they agreed to it when they enabled location services on their phone.
• People are most likely to trust large corporations and be wary of smaller startups making use of location data, even if the latter have a published, clear and transparent privacy policy and terms of use.
• Even within the EU there are varying levels of legislative control over how location is classified and what can application service providers can do with it.

There seems to be widespread ignorance among the population about what their devices can do, what the companies that manufacture and sell them do with their data and what applications do. It is easy to agree to a long text titled ‘Terms of Use’ or ‘Privacy Policy’ without reading it, but most of the time people are totally clueless about their rights and whether they have voluntarily gave them up when they agreed to use Google’s or Apple’s latest and greatest gadget.
»

Android 2.3 was announced a few days ago. The previous day, CyanogenMod 6.1, the most popular community mod was released, based on Froyo (2.2). And today, just a short two weeks after the announcement, the source code for the latest version of Android is being released!

The release marks the end of the 2.x era, with Google, most definitely, working hard on the 3.x series aimed for release in the first quarter of 2011 and — hopefully — taking the fight with iOS up a notch. Just an hour ago cyanogen posted this on twitter:

If you need me, I’ll be locked in my room for the next 3 days. #gingerbread

I feel that right now that’s precisely what makes Android sell, and by extension the popularity and characteristics of such projects give many clues on the demographics of those buying Android devices.

In other words, the ‘magic’ of the platform is its rapid evolution and by extension its community (a community that is largely technology oriented), something not to be found in HTC’s or Samsung’s wanna-be iPhone devices (or their mediocre software), Sony Ericsson’s lifestyle apps or Motorola’s ‘macho’ Droid phone and its seriously bad Motoblur. These are commercial parts of a nascent platform that — until now — enthuse few outside the technology community.

Stuff like CyanogenMod are exciting because they evolve extremely fast and at the same time let your imagination run wild with features that half-baked commercial Android ‘flavours’ couldn’t never have. A combination — and even the ‘controlled’, sterile in a way, yet amazingly polished environments like iOS lacks.

And this is, sadly, something that most major Android device manufacturers don’t get, judging by the effort they put in locking their products down, the amount of crapware they bundle with them and the restrictions they place to their customers.

By the way, if you’re using a supported device, like e.g. the HTC Desire, I recommend you get rid of Sense right now, get CyanogenMod, or another mod if so you prefer, and turn the damn thing into a usable gadget. You won’t regret it*.

*If you do, I won’t be held responsible for any damage you may cause to your device.

Still watching the Google Chrome Team Livestream. Google is on a massive release streak that clarifies their strategic outlook for the next two years. In two days we’ve had: Android 2.3 and a short Android 3.0 sneak-peek, the eBook store, (V8) Crankshaft, Chrome Webstore and Chrome OS.

The Store.

With the Chrome Web store, Google is attempting to replicate the AppStore model on the Web. From the point of view of a Web user, I find it useless, or in other words a glorified bookmarking system, coupled with a payment processing system and proprietary functionality that ties everything to Google; most of the things that the Chrome Web store offers are already here, although they are not offered by a single company. Payments, for example, take place all the time through trusted third-party payment processors, including Google. Discovery of new sites/apps happens daily through social bookmarking sites like Digg and Reddit, a number of trusted publications, word of mouth etc. There’s no doubt that a web site/application directory, or a fancier way to ‘bookmark’ web apps might be useful, but that would be a much more noble proposition to what Google talked about today and it would need to be done in a cross-browser way that would be inclusive to other browser developers and the community as a whole.

The apps. The Web. Openness and Google.

The NY Times Chrome application is just a modern website I visited while the presentation was taking place. Amazon’s WindowShop is a Flash client for their store. A flash game could reside behind a third-party game portal. None of those things have anything to do with the ‘Store’.

The Chrome ‘Webstore’ makes things ‘easier’ and more streamlined for Chrome users and developers, but flies in the face of the openness and independence of the Web. It introduces a new dependency, Google Chrome for its proprietary functionality and Google, for its payment processing services and at the same time raises barriers to entry to other browsers that might very well be standards compliant, but lacking the ‘Web store’ functionality. It ties web applications, their users and developers to Google, even if that’s in the form of the additional work that developers will have to do to provide versions of their applications for the Chrome Web store, the ‘Web’ or even other ‘Stores’, if and when they appear.

There’s no need for any new ‘dependencies’, no need for web apps making use of ‘proprietary’ functionality found in any one browser; we’ve had that nightmare with IE for many years late in the 20th century and for several years the web was the domain of IE.

Google’s intention with the Web store, however, is not at all limited to the Web. It might be that the reasons for the Webstore’s existence fail to convince, but the company’s desire clearly goes far beyond that: Google aims to provide a single place for Applications that fits their upcoming Chrome OS strategy, which, by extension, aims to centralise everything in their own data centres.
»

There is an untold general, cross-platform, inter-device rule regarding versioning: Major versions are major because they expose significant improvements and functional upgrades to the user whereas minor versions are typically either minor feature upgrades or bugfix releases.

Many projects, corporations and communities deviate from that loosely defined rule, but none do so more than Google has with Chrome. A browser that adopted the best of breed open source technology available at the time and pair it with newly developed, open source components managed to become the sweetheart of the tech community in less than two years. I started using Chrome when the first Mac and Linux versions came out, and since this spring it’s my main browser.

The other day, Update Manager on Ubuntu prompted me that Chrome 8 beta was available. Arguably, eight ‘major’ versions in two years sounds like a huge feat, but as of late I fail to see the point. Chrome 8 beta has little — if any — user-visible improvements or functional upgrades. It has none of the speed improvements that users experienced before in major-version upgrades. On my 64bit linux workstation, the only obvious difference is that they fixed some major SVG bugs that troubled me while coding the GEO|ADS analytics engine.

It seems that Google aims to exceed Version 9 before IE does, but at this rate the versioning scheme adopted by Google will become cumbersome before the end of 2011:

“Hey, I installed Chrome 26 yesterday. 1% faster Javascript execution, some obscure bug fix and a minimally redesigned arrow on the back button! yay!”