Steve Jobs: the story of a sociopath

Steve Jobs, Book, by Walter IsaacsonI’ve read other semi-biographies of Jobs and, working with a lot of people in the tech industry, I’d heard many of the stories of how much of a bastard he was. However, this biography left me quite bemused and surprised: I never expected Jobs to be such a disgustingly-shameless-sociopath-brat-cry-baby! even to the last minute, with Jobs having to have control over the cover image of the book.

I don’t think he would have liked much of what is inside this book; which is what makes it great.

It’s amazing that Jobs sought out Isaacson to write this biography. And Isaacson, pre-warning Jobs that he was going to uncover all the dirt, delivers a very inhuman story. In Isaacson other book on Einstein, he also revealed Albert’s many flaws and brought Albert down to our level. With this book, he absolutely devastates the image of Jobs as a great business leader and as human being: from his stinky hippy days, to his denial of his daughter Lisa and smear campaign of the mother, to his tyrannical and plainly mean way he constantly ripped-off and mistreated other people.

I guess Job’s own reflection of his life must have been also distorted by his “reality distortion field”. It’s great that this book came out when it did. If anything, it shows that Steve Jobs was not in the same league as other great inventors and geniuses of the past century. Jobs just rode on the great ideas of those around him. If it was him that made those ideas successful is unclear, so Jobs is just shown as part of the greater collective that was, and remains, Apple computers.

I anything, it’s good that Isaacson shows why no one should take inspiration from the cold, hard, tyrannical a**hole that was Steve Jobs. A great read! And proof you can’t judge a book by its cover.

W3C Workshop on The Future of Off-line Web Applications

The W3C and Vodafone are hosting a Workshop on The Future of Off-line Web Applications on 5 November 2011, in Redwood City, California. According to the workshop website,

The goal of this workshop is to identify a clear path forward for innovation in the Open Web Platform related to offline Web application invocation and use.

As I’ve done for previous events, I’ve prepared a paper entitled ”Misconceptions about W3C Widgets” (PDF, I know… I’ll publish it here in HTMLs when I get some time).

As I am on the program committee, it means I get to review papers. I’ve actually read all the papers that have come in thus far, and it looks like it’s going to be fun workshop. The other program committee members have been a bit slack, however. I’ve only seem papers from about 2 or 3 of them. I hope Microsoft, Google, and Mozilla submit something.

What usually happens after these workshops is that a new Working Group is established. This will probably either mean:

    • The death of W3C Widgets: Google and Moz will make a powerplay and dump in their own JSON based widget format on the w3c (Moz’s offer, Google’s offer).
    • Or,  the rebirth of W3C Widgets: Google and Moz will come to their senses and finally embrace the W3C widget format (unlikely, but here’s to hoping:)).

Web Actuators API

Having gone through the pain of trying to bust up Apple’s shitty patents around Widget Security, I learned that if you have a good idea, then you should put into the public record as quickly as possible (unless you intend to patent the idea, for fun and profit). It seems that the US patent office will grant a patent for just about anything, probably even a knife and fork. The state of the United States patent system truly is an embarrassment (for more info, thepublicdomain.org).

Idea: Web Actuators, an API for  Web Browser to allow control of physical output component, including, but not limited to LEDs, speaker, motors, or anything detectable by any human sense (sight, touch, smell, taste, hearing).

interface Actuator(){
   //details coming soon...
   //pulse width modulation
   void pwm();
}

This Actuators API would compliment a general purpose Web Sensors API: an API for detecting and reacting to events generated from reading “low level” sensor data (e.g., a flew sensor, a switch, a pressure sensor, a temperature gauge, etc…. any sensor that can take a reading).

Marking files as binary in CVS

When multiple people are working with CVS, what can sometimes happen when you do a “cvs update” is that binary files get “merged” as if they were text files. Naturally, this can cause some file types to become corrupt.

To avoid this happening, type:

$ cvs admin -kb path/to/binary.file

Usually, you have a large number of these files (in my case, I had about ~1000 zip files). So combining the above with Bash’s find can be very useful. Assuming you are in the working directory:

$ find . -name "*.ext" -exec cvs admin -kb {} ;

The “{}” substitutes the found file, which CVS marks as binary for you.

There is also a handy guide on working with binary files in CVS.

Finding the value of “xml:lang” of an element

XML Spec says that when someone declares xml:lang somewhere in the ancestor chain of an XML document, element nodes in the DOM are supposed to inherit the value of xml:lang. However, although xml:lang is an inherent part of XML, the DOM Core level 3 specs lacks means to easily find what value of xml:lang an element has inherited (or explicitly has been assigned).

From section 2.12 Language Identification of the XML spec :

The language specified by xml:lang applies to the element where it is specified (including the values of its attributes), and to all elements in its content unless overridden with another instance of xml:lang. In particular, the empty value of xml:lang is used on an element B to override a specification of xml:lang on an enclosing element A, without specifying another language. Within B, it is considered that there is no language information available, just as if xml:lang had not been specified on B or any of its ancestors. Applications determine which of an element’s attribute values and which parts of its character content, if any, are treated as language-dependent values described by xml:lang.

Below is a little useful code snippet to help you find the value of xml:lang. The code simply recurses up the tree till it finds an xml:lang attribute to inherit the value from. If it can’t find one, it just returns an empty string:


function xmlLang(element){
  var xmlns = "http://www.w3.org/XML/1998/namespace";
  var value = element.getAttributeNS(xmlns,"lang");
  //check if we are at the root
  if(element === element.ownerDocument.documentElement){
      //no xml:lang?
      if(!element.hasAttributeNS(xmlns,"lang")){
          return "";
       }
       //we have it, so return it.
       return value;
   }

   //this is an element in the tree
   if(!element.hasAttributeNS(xmlns,"lang")){
       //no xml:lang? recurse upwards
	    return xmlLang(element.parentNode);
   }
  //we have a value, so return it
   return value;
}

To make it more useful, it would be good to validate the value derived from the code above against the IANA language tag registry.

Firefox 4 beta and geolocation

Had a brief look to see if anything had changed re: geolocation in Firefox in its first beta release of 4.0. Seems they have started to integrate an indicator into the address bar.

Firefox 4, beta 1's handling of geolocation

Firefox 4 Beta 1's handling of Geolocation...

The indicator still does not show up when geolocation is active, but it’s a start and it’s good to see that they are working to fix that.

Daniel Solove at Google

While investigating privacy, I read a fantastic book by Daniel Solove called The Future of Reputation: Gossip, Rumor and Privacy on the Internet. Daniel is a professor of law at the George Washington University Law School who has written extensively about privacy.

Yesterday, I found this video lecture given by him at Google. Check it out! It covers a lot of things that are in the book.

I’ll just say, it’s a little bit sad to see such few people in the audience. Also, the questions from Google employees are very defensive. In my opinion, Daniel is right to say that people should have more control over Google results about themselves, specially if those results are slanderous.

Privacy issues in Mobile Safari on iPhone OS 3.2

With iOS 4.0 around the corner, its probably timely to get this post out now. This little post is part of my position paper, “Privacy of Geolocation Implementations”. I’m taking sections out that paper and republishing them here for comment.

Iphone 3.0's modal geolocaiton popup

A website viewed in Safari on iPhone 3.0 requesting to use the end-user's current location. But what will the data be used for? And where is the application getting the data from?

As can be seen in the screenshot on the right, when a web page attempts to access geolocation services on Mobile Safari, the browser presents the end-user with a dialog that states “[URL] Would Like To Use Your Currrent Location” with two options: “Don’t Allow” and “OK”.

This “click to confirm” model suffers from a number of  privacy issues: For one, the confirmation dialog does not give any indication to the end-user how their location is being derived: Is the location-provider the GPS? or is it the WIFI, or the cellular network, or a Web service? or a combination of those? and under what privacy policy does the location-provider provide that information? The iPhone provides no accessible means of viewing or changing the geolocation provider; hence an end-user has no control over the geolocation provider or even of knowing if their data is being encrypted on request.

Another privacy issue of Mobile Safari is that the confirmation prompts are modal: the user cannot fully view or interact with the underlying application to make an assessment of what the application might do with the positioning data, without first rejecting geolocation access to the website. Also, it is generally accepted that this kind of modal confirmation dialog lead to ‘click fatigue’: whereby users simply become accustomed to clicking “OK” to every prompt without grasping the consequences of their actions, and without having any real control over what personally identifiable data gets used, what it will be used for, or how long that data will be kept, or even if it will be made available (sold) to third parties. The privacy policies that govern geolocation services are buried three-levels deep in the “Settings” menu of the iPhone, under the “Legal” option, which contains about 50 a lot of pages of legalese and no searchable index!

Iphone 3.0 Legal page

The Iphone 3.0 "Legal" screen does not contain an index. Nor are hypelinks active.

Similar confirmation dialogs are found in the iPhone’s native applications (e.g., the Camera and Maps applications). If a user changes their mind about allowing location services, there is usually no way in the application  for them to revoke geolocation access without either quitting the application, uninstalling the application, or finding some other convoluted way to revoke access to geolocation services (e.g., having to globally disable location services on the device through the “Settings” menu). What is worst is that  once a user grants an application access to geolocation services three times, the system grants access to location services forever – or until the device is “reset”, meaning resetting back to factory default settings.

UPDATE: @andreasbovens pointed out to me on Twitter that the iPhone does, in fact, contain a way to reset location warnings. Go to “Settings > Reset > Reset Location Warnings”. My bad.

Iphone reset location warnings

Iphone reset location warnings, which I didn't find the first time around :(

Applications that get granted access then do not generally provide an end-user with a means to revoke that access on an individual basis. This is also true on Mobile Safari: even after clearing the cache, history, and cookies Mobile Safari still grants websites access to geolocation without prompting the user.

In summary, Apple’s Mobile Safari browser (and iPhone 3.0 in general) provides end-users with limited access to privacy controls. It also provides no means of seeing which Websites have access to geolocation, nor once granted can that access be easily revoked by an end-user. The OS, however, provides means of achieving confidentiality by allowing the end-user to globally disable location services, WIFI, and cell-tower communication (via “Airplane Mode”). INSERT: The iPhone OS also provides a “Reset Location Warnings” option for all applications.

Iphone Airplane mode

iPhone Airplane mode: anonymity?