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.

The Macintosh has always been unique in terms of software, ever since it came out in 1984. From the now almost disappeared ‘Resource Fork’ of MFS/HFS, the pascal slant of Mac OS releases up until the early 1990s, the multiple architectural and design transitions, the Carbon/Cocoa duality of early Mac OS X, ‘Classic’ and ‘Rosetta’, the irrelevant HIG, to the numerous, continuous self-contradicting choices that Apple has kept making throughout its development in the past twelve or so years that Jobs and Co. returned to Cupertino.

Apple has, ever since the mid-1990s had decent support for Java on its platform. For a long time the company has provided its own versions of the JRE/JDK. When Mac OS X came out the reason was simple: Sun wasn’t going to do it, it was already burdened with a number of versions and the post-bubble era was a tough time for the company, so Macintosh support was out of the question. In the early years of Mac OS, say until 2004, Java was a rising star in the OS X community; Apple was doing an relatively good job providing recent-enough versions of the JRE/JDK for its computers and most people were happy. The ‘Java bridge’ and the nascent — for Macheads that is; the technology was much older and extremely well-designed, for its time — Cocoa framework allowed beautiful, usable rich Java applications to be written for OS X, at a time when SWT was somewhat immature and Swing was, well.. Swing.

Then some people at Apple decided that Objective-C was worth a revamp, it started working on Objective-C 2.0, which gave ‘managed code’ a new meaning among Mac developers, and — in the process — dropped the Java bridge; Jobs didn’t want people to code rich Java apps with Cocoa widgets on the Mac anymore, in the same way he didn’t want anyone to keep writing (let alone start writing) applications using the Carbon framework. Cocoa and Objective-C was the way.

The end of quasi-decent Java on the Mac was heading our way at breakneck speeds, but few would expect that Apple would stop providing newer versions of Java for its computers, without someone else picking up the task of doing so. Or would they?
»

I have just had the most thrilling experience of the last few months.

Three years ago I got myself a silver Ikea halogen balanced-arm lamp. It replaced an old wooden desk lamp that worked great, but was not exactly what I wanted (to be able to read a reference book open in a darkened room next to my displays).

So an Ikea lamp it was; partly because it was cheap. Partly because it was easy to get, it looked ok and it was more or less what I wanted.

Last month the light flickered a few times; I didn’t pay much attention — the power company has most definitely forgotten my neighbourhood as the power supply is erratic at best — especially in the summer months when air conditioning units bring the power stations to their knees. Then a few days ago the lamp went off all of a sudden. I flicked the switch once or twice and it came on again. All was well.

This morning the light was off, as it should; but apparently the switch was still at the on position. You can’t easily tell which position is ‘on’ or ‘off’ if the bulb doesn’t turn on as there is no indicator near the switch; it’s a matter of remembering the actual physical position of the flip switch. It would be very hard to explain how the lamp started fuming and after a few seconds a small flame appeared from the switch compartment near the bulb.

Needless to say, a flaming lamp sitting 20cm away from your face is a thrilling experience, especially when excitement usually means null pointers and segfaults. Thankfully I reacted quickly, pulled the plug on the lamp and the small flame disappeared, the lamp still fuming and filling the air with the horrible smell of burnt plastic/rubber.

I think I learnt my lesson: I will never, ever, ever buy an Ikea electrical appliance in the future. I was extremely lucky this time; being around, being awake, reacting calmly.

I generally like Ikea products. But a cheap bookcase, living room table or desk is one thing. It can fall apart after a few years, flake, break or what-have-you. That’s fine. It cannot, however, ignite all of a sudden.

Τον τελευταίο καιρό συζητείται το ‘άνοιγμα’ των κλειστών επαγγελμάτων. Οι ‘φασαρία’ που έχει προκαλέσει η επαναλαμβανόμενη απεργιακή κινητοποίηση των μεταφορεών, ιδιοκτητών φορτηγών δημοσίας χρήσης και λοιπών επαγγελματιών/επιχειρηματιών του κλάδου μπορεί να έχει, στο μυαλό των περισσοτέρων, ταυτίσει το ‘άνοιγμα’ των κλειστών επαγγελμάτων με αυτήν την κοινωνική/οικονομική ομάδα, όμως τα επαγγέλματα είναι πολλά και ποικίλα και οι κοινωνικές ανάγκες που καλύπτουν εξίσου διαφορετικές.

Ένα από αυτά τα επαγγέλματα είναι οι φαρμακοποιοί. Επέλεξα να γράψω για τους φαρμακοποιούς, αφ’ενός επειδή έχω αρκετούς συγγενείς και φίλους που ιστορικά βρίσκονται στον χώρο και θεωρώ πως γνωρίζω, περισσότερο ίσως από τον μέσο όρο, τις ιδιαιτερότητες του κλάδου, αλλά και επειδή — παρ’ότι συμφωνώ απολύτως με την απελευθέρωση των κλειστών επαγγελμάτων και θεωρώ πως η Ελλάδα έχει ήδη αργήσει πολύ — θαρρώ πως η απελευθέρωση των επαγγελμάτων δεν είναι σε καμία περίπτωση μια μονοσήμαντη διαδικασία, πως το κάθε επάγγελμα έχει τις δικές του ιδιαιτερότητες και η όποια κανονιστική ρύθμιση πραγματώνει την απελευθέρωση του οφείλει να τις λάβει υπόψη της (κάτι που σίγουρα εν διαμέσω κρίσης και πανικού δεν πραγματοποιείται στην Ελλάδα του 2010).

Διάβασα στην Καθημερινή το άρθρο ‘Οι τιμές των φαρμάκων‘ του Στέφανου Μάνου. Σε αυτό παραθέτει την συζήτησή του (και τον παραλογισμό) ενός φοιτητή της Φαρμακευτικής, του οποίου η οικογένεια έχει φαρμακείο και πρόκεται να ‘θιχτεί’ από την απελευθέρωση, ως εισαγωγή σε ένα, ως επι το πλείστον αφελές, κείμενο που αντιπαραθέτει ως παράδειγμα προς μίμηση τα περιθώρια κέρδους των φαρμακείων στην Σουηδία. Και παρ’ότι τα παραδείγματα του κ. Μάνου είναι ενδιαφέροντα και εικάζω πως είναι ειλικρινής και πιστεύει αυτά που γράφει, φαίνεται να αγνοεί τι ακριβώς συνεπάγεται το επαγγέλμα των φαρμακοποιών, η αγορά του φαρμάκου, ο τρόπος που δουλεύουν και τι σημαίνει η απελευθέρωσή του.

Τα φαρμακεια σημερα

Με το υπάρχον σύστημα, τα φαρμακεία είναι περιορισμένα ως προς τον τόπο στον οποίο μπορούν να ανοίξουν, βάσει του πληθυσμού του κάθε τόπου αλλά και βάσει της παλαιότητος του φαρμακείου — αυτός πρακτικά είναι ένας τρόπος να εξυπηρετηθούν οι παλαιοί φαρμακοποιοί που σήμερα μπορούν να μεταφέρουν το φαρμακείο τους πρακτικά όπου θέλουν ανά πάσα στιγμή μετά από κάποια χρόνια λειτουργίας. Με αυτόν τον τρόπο πριν ‘πουλήσουν’ την άδειά τους (με σημαντικό κέρδος) μεταφέρουν το φαρμακείο σε ένα πολύ καλό σημείο και το πουλούν ακριβότερα. Αυτή η νομοθετική ρύθμιση καθιστά το φαρμακείο ‘κλειστό’ επάγγελμα, δηλαδή επιβάλλει την ‘αγορά’ μιας υπάρχουσας άδειας από έναν νέο φαρμακοποιό που επιθυμεί να ανοίξει φαρμακείο, καθώς νέες άδειες δεν εκδίδονται (παρά μόνον υπό προϋποθέσεις: βλ. γεωγραφικοί, πληθυσμιακοί περιορισμοί κλπ). Φυσικά κάτι τέτοιο είναι άδικο και καθιστά την απόκτηση άδειας δύσκολη υπόθεση για όσους δεν έχουν τα μεγάλα ποσά που εδώ και χρόνια απαιτούνται για την αγορά τους.
»

Bing, Microsoft’s portal/search/mapping service has announced that they will start providing OpenStreetMap (OSM) data, as an optional layer, in Bing Maps. OSM data will be downloaded from Microsoft’s fast Azure CDN, as opposed to OSM’s ‘slow’ servers.

Now, there’s nothing wrong with Microsoft using OpenStreetMap data. That’s why it’s Open. But then again, I am surprised how Microsoft can be so obtuse as to not give something back to OpenStreetMap, be it in technical services, financial support or just mapping data — as a token of appreciation for their work. Yahoo did, since 2006, when they allowed OSM to use their (somewhat dated) aerial photography to enrich the database. Many organisations, including Google and Multimap, have in one way or another supported OSM, in parallel with their own commercial mapping activity. Countless smaller organisations and individuals, including us, contribute to OSM whenever possible (I first wrote about OSM here, in late 2007).

On the other hand, Microsoft, one of the world’s largest corporations and — arguably — a leading ambassador of mediocrity — both technically and in terms of marketing — suffices to an announcement that they’ll make use of OSM data in their product, without giving back anything. Clearly because they don’t have to. Also because they, most probably, fail to understand what ‘community’ means. Most certainly because they don’t realise how good any support to OSM, be it technical, financial or just in terms of data, like Yahoo did some years ago, would do to their tarnished public image and their dwindling mindshare among the people that matter, both within the industry and beyond. Quite sad as their support would probably mean a lot to both OSM and Microsoft in its effort to redefine itself in the post-PC era.