For the past month I have been working on a new project called medly. Out of all the software projects I’ve worked on I think medly is one of the most exciting and has a decent chance of success.
Before I get into too much detail on what I think about medly I suppose it would be best to explain what it is. medly is an app that will enable its users to share a digital equivalent to the mixtapes that we all used to make back in the ’80s and ’90s before the days of mp3 players and iPods. The concept is also akin to the CDs we would burn from mp3s but those don’t quite provide the nostalgia that mixtapes do.
When this idea first came across my mind I initially dismissed it as useless. Why would anyone want a service like this? We have the ability to create playlists today that are unlimited in length and we even have computer programs that will make playlists for us either by crowd sourcing the process (e.g. Genius playlists) or by using smart playlists that generate playlists based on certain criteria. These methods are both very powerful and provide us with fairly good results with little to no effort on our part. The problem is that I see them as the fast food of our music consumption patterns.
No human thought or passion goes into creating these playlists and they can go on forever so why not just put every song you want in? To me the beauty of the mixtape is that you had limited space for songs and it took substantial time and thought to put together a good one. If your cassette tape could only hold an hour’s worth of audio, you could only pick an hour’s worth of music to include. I think that constraint caused more thought to be put into what music people listened to and shared. medly aims to bring that back.
Of course medly cannot legally share the actual music so for right now only the metadata of the songs is shared. This means that when someone sends you a medly mix any songs you already own will be playable from the mix, the other songs will be 30 second previews and you will be given the option to purchase them from Amazon or iTunes. I hope to also include songs from 3rd party music subscription services like Rdio so that if you have a subscription with them and they have a song you will be able to play it.
I think if this idea takes off it has a lot of potential. Right now medly isn’t ready to meet the world, but it will be soon. Until then you can visit the medly teaser site at medlyapp.com. Be sure to sign up for the mailing list and like or tweet about medly!
Over the past several days much ado has been made over a file located deep within iOS called consolidated.db. Judging from what I've heard and read in the news and on blogs it sounds like Apple is tracking iOS users like a dog and keeping a record of their every move.
I was skeptical about this conclusion from the first time I heard it. It seemed odd that people were using this to vilify Apple when they couldn't even demonstrate that Apple was collecting the information for their own commercial use. By admission of the security researchers who found this file the data was kept on the device and in backups but was never sent to 1 Infinite Loop. Some suggested that this was a 'programming mistake', but I couldn't believe that Apple would let this database needlessly take up space and cycles on their resource constrained mobile devices. There had to be a good reason for this database's existence.
I decided to download the application provided by the researchers and run it on my device. I had to decrypt my backup to get it to work but eventually I got the maps with dots showing where I had been recently. I was surprised at how unspecific the data was. In fact, the dots formed a near perfect grid completely covering the town in which I live. It was immediately clear to me that this database was not logging my location but the location of the cell tower to which my device was connecting.
At this point I was annoyed that the media had made such a big deal about this. This data did not reveal anything more than what towns I had spent time in. I can't think what sort of damning conclusions this data could help anyone come to about my travels or anyone else's. Yet the question still remained, what is the purpose of this database?
I decided that I needed to inspect this file for myself to see if I could derive any sort of reasoning of why Apple would have iOS keep this database. I downloaded the nifty iPhone Backup Extractor from supercrazyawesome.com so that I could get to the consolidated.db file. I then opened the database in Base which is a SQLite database client available on the Mac App Store.
After inspecting the database for a few minutes it was clear what was really going on here. The consolidated.db file is located at this path: "/Library/Caches/locationd". This part of the iOS filesystem is well out of reach of the normal iOS user so the naming of the directories in this path are meant to hint developers within Apple as to what is in the directories. It is inside Caches so this is obviously some sort of cache. To any developer who has spent time with UNIX "locationd" would hint to them that the files within are used by a system daemon that has something to do with location. A system daemon is a long-running background process that acts upon certain events as they occur.
So clearly the data about cellphone towers is related to the devices location not anything to do with quality of cell service. What we know so far is that this is a cache of location data based upon the location of towers this device has connected to.
Now lets look at the tables within the SQLite database. There are 3 significant groups of tables within the databases:
On my GSM iPhone the CDMA related tables were all empty. The GSM related table contained numbers that I suspect identify the tower, a timestamp, GPS coordinates, and a confidence field. The Wi-Fi related tables were very similar. I think the confidence field is very telltale of the purpose of this database. It seems to be a number between 0 and 100 that could possibly represent how confident iOS is of the accuracy of the measurement of that location.
Anyone who watched the iOS 4.0 keynote saw Apple explain how location tracking works in iOS and any developer who have used the location APIs are very familiar as well. iOS uses three methods to locate the device it is running on. These are via nearby Wi-Fi networks, nearby cell towers, and traditional GPS. Each of these methods provide a trade-off between battery power and accuracy. The more accurate the location data the more power is used to determine it.
I think this tradeoff is where consolidated.db comes into play. What if when your phone used the power-hogging GPS chip to get a super accurate location on you it also logged the specifics of the current network conditions to later use as a fingerprint for that location. That way in the future the device could compare the fingerprint of the current network conditions against its database and could then derive a fairly accurate location of the device. This would help bridge the gap of the accuracy/power tradeoff especially in places you have spent time before.
So I would say that this consolidated.db file makes your iOS device better over time. The longer this file has been in existence on your device the more accurate your locations will be and the longer your battery will go. Should Apple be encrypting this data? Perhaps, but the information isn't nearly specific enough to be incriminating and any law enforcement officer could get much better data than this in minutes from your wireless carrier. I do not see how a burglar could determine the location of your home or place of work from this data especially due to the hoops they would need to jump through to access it. I would recommend you encrypt your backup, but I don't think you should worry about this data harming your privacy. Oh, and don't jailbreak your device dummy.
I'm always starting a new project and for mostly good reasons they almost never get finished. Sometimes I just get lazy or bored and decide to not finish what I'm working on but more often than not my progress is hindered by forces outside of my control.
In 2007 before the iPhone had the App Store I wrote a small web app that was built for the iPhone. Basically the app was a quick way to check whether you should buy a product in the store or online. You could go shopping in a brick and mortar store and enter a UPC code or product name and it would tell you how much it cost on popular online stores like Amazon.com
I spent several months worth of weekends putting together and just as I was getting ready to publish it online I noticed a single line of text on Amazon's API website. It stated that Amazon's API could not be used "in connection with a mobile device."
I was disappointed and even tried to contact Amazon to see if I could get a waiver from this policy. They denied my request several times. This policy is still in effect today and has prevented the creation of many great mobile applications.
It is for reasons like that that my projects and ideas are often not brought to completion. It can be very frustrating at times that I don't really have many finished products to show for all the time I've spent working on them. So this time I'm going to do something different.
I decided a couple of months ago to find an idea for a project that I knew could not be hindered by technical or legal limitations. It took me awhile to think of something as I typically don't get excited to work on ideas that have been done before. I realize now that the tendency of mine to avoid projects that have been before done is one reason I repeatedly hit limitations. It is obvious now that those things haven't been done yet for a reason.
Last week I came up with my idea and I'm starting on it this weekend. I don't want to divulge it just yet but I'll be posting more about it soon. My goal is to be at least in beta in time for WWDC 2011.
Back to work!
Yesterday I got my hands on an awesome new domain: macinjo.sh! Earlier in the week I had been browsing around the internet and I stumbled across a .sh domain name. I had previously known about the .sh ccTLD but I had never found a way to register one unless I wanted to move to The Island of Saint Helena in the middle of the Atlantic Ocean.
I was hoping I could register jo.sh but unfortunately two letter second–level domain names are not allowed. I also looked into josh.ua (.ua is the Ukranian ccTLD) however you must have a company in the Ukraine to register a .ua domain.
I think I'll be holding on to this domain for as long as the good people of The Island Saint Helena will let me.
