KEYBOX 2.4.1 was released today.
This version corrects a bug where the password strength checker did not indicate the strength using colors (red = weak, blue = safe) in iOS 6.0 and also addresses overly repetitive memory warnings on some screens.
It is recommended that users upgrade at their earliest convenience.
KEYBOX 2.4 was released today.
It adds support for selecting preferred language, a much improved image viewer, import/export functionality enhancements and UI improvements.
I hope users will enjoy this new update and all are recommended to upgrade at their earliest convenience.
This is a friendly reminder to backup your KEYBOX secrets prior to upgrading to iOS 6.
Due to legal reasons regarding iCloud storage and the need for Apple to be able to divulge data stored in its servers, KEYBOX data is not stored in “the cloud” and only resides in one’s iPhone and/or home PC/Mac.
Most of the time this design is a great benefit to users, but when updating to a new major version of iOS there is the chance of a failed upgrade which will force a factory reset of the iPhone, thus losing any KEYBOX’s data yet to be backed up. Once that data is lost there is no getting it back so please keep in mind just how important frequent backing up of KEYBOX data to one’s PC/Mac is.
I hope everybody enjoys iOS 6 and I’d like to take this moment informally announce that version 2.4 of KEYBOX is just around the corner and features some nice improvements to the already excellent KEYBOX experience which I hope users will enjoy as well.
Stay tuned!
KEYBOX 2.3 was released today.
It adds support for the new iOS Chrome browser (when launching a page externally) and features numerous improvements and a small bug fix.
Users are recommended to upgrade at their earliest convenience.
KEYBOX 2.2.1 was released today!
It addresses two small bugs involving network connectivity and importing of unusually small backup files.
It is recommended that all users upgrade at their earliest convenience.
KEYBOX 2.2 is now out at last!
This update improves importing speed and robustness and introduces a new face for KEYBOX, a more high-tech one that embodies the advanced techniques KEYBOX uses to keep secrets securely encrypted.
I’ll be commenting more on the icon design later. For now I encourage all KEYBOX users to upgrade to the latest and greatest version!
Inspired by Chris Eidhof’s “I USE THIS” post, I decided to post about where the magic behind my apps happens.
My Environment:
My Flow:
Dual monitors is a god send for me. I spend most of my day in Xcode and its usually on the left monitor and whatever I’m making is on the right. Safari on the right when I’m looking something up. Also when using inkscape I can edit the XML in one monitor and see the visual changes in the other.
The only downside from having a dual monitor setup is my system’s video performance is a bit slower but I don’t use my Mac for gaming and video playback is sufficiently good. The productivity gains more than make up for it.
I used to have a Power Mac (Dual G5s) that performed great for 8 years but was a bit noisy in summer when all the fans would turn on (burning G5s!). This Mac mini is ninja-silent and fits directly under/between my monitors.
My Software:
* I try to support indie developers as much as possible. They go above and beyond and I want to reward them for it. The developers in question here are all stand up guys.
Today my newest iPhone app, LandMarked was released worldwide on the App Store!
What is LandMarked?
Have you ever had trouble getting back to a place you were introduced to by a friend or you accidentally stumbled upon? I have, and I created LandMarked to solve this problem.
LandMarked lets you instantly and easily drop a point on any location, take a photo of it, write some notes, rate and categorize it. Even if you forget where it was, LandMarked won’t.
The rule for using LandMarked is simple: If it’s worth coming back to, it’s worth marking down. And if it’s a really great place you can even share it with friends too. LandMarked is not a social network, but it lets you tweet or mail any place you know people will love.
It’s that simple! So what are you waiting for? Get LandMarked today for your iPhone (it’s FREE!) and start making your mark!
Vic Gundotra has today shared via Google+ the below report that the Path iOS app has been found uploading each user’s entire address book to the Path servers without first notifying users or otherwise asking permission.
http://mclov.in/2012/02/08/path-uploads-your-entire-address-book-to-their-servers.html
How Path Works
Dave Morin, the CEO of Path was quick to comment on the report and explained this behavior citing the reason below…
“We upload the address book to our servers in order to help the user find and connect to their friends and family on Path quickly and effeciently as well as to notify them when friends and family join Path. Nothing more.”
Regardless of reason, this is in clear violation of at least rule 17.2 of Apple’s App Store Review Guidelines and possibly rule 17.1 depending on your definition of “user data”.
Matt Gemmell, directly beneath Dave Morin’s comment, offers a proactive solution to the issue in hashing the data prior to upload (it neatly skirts around Apple’s rules, protects the user’s privacy and still accomplishes the task at hand with zero server-side performance impact). Hashing transforms the private data into a stream of garbage data that is unique for each data entry. It allows Path to go on matching contacts without knowing who those contacts are.
Going Forward
What concerns me about all of this is that this solution is so trivial (anybody developer who understands one way hashing can do it) that Path should have implemented it right the first time (had they care enough to do so).
I want to give Dave Morin and his company the benefit of the doubt here but it’s a bit hard. I don’t think the security and privacy of Path’s users is a topic with which they are concerned. There are simply too many mistakes here to think otherwise. Everybody who follows my blog knows how I feel about privacy matters and usually I would advocate immediately removing the Path app until the issue is resolved but in this case it will do little good. The damage, as they say, is done. The best recourse is perhaps to report this issue to Apple instead.
Many companies violate user privacy, until they get caught, and they need to be taken to task lest this negligent behavior become even more widespread.
Path should consider itself lucky that a sole individual discovered this issue just by poking around and not by having every user’s private data their servers house leaked into the wrong hands as a result of having their servers hacked. It’s still a possibility until they rectify the issue.
After weeks of testing KEYBOX 2 against iOS 5.0 and the new iPhone 4S as well as fixing some bugs introduced by both I’ve finished testing and finally submitted KEYBOX 2 to Apple.
Barring any approval process snafus I expect to release it Saturday Dec 17th 2011, just in time for the year end holidays!
Release 2 is of course a free upgrade from the first release and users purchasing it now will not have to pay twice.
I want to thank all the people who’ve expressed their enthusiasm for the next release for their continued patience. I hope to make more incremental releases in the future.
Stay tuned for the release 2 and the new revamped website that will accompany it!
Some KEYBOX users ask me why it is needed when iOS devices are protected by passcode screens.
I respond along the lines that the passcode screen only prevents people from using the device and not accessing the data that resides within (by backing up that data to a computer).
Now it seems a serious security flaw has emerged that that allows anybody with a Smart Cover to break into an iPad 2, even when protected with a passcode.
9TO5Mac has an excellent breakdown of how to recreate it here. This is yet another reason why apps like KEYBOX are beneficial to people who value their privacy.
If you own an iPad 2, make sure to apply the workaround detailed there.
According to this Yahoo Headlines Japan article, KDDI has revealed on September 22nd that it has officially signed on to carry the next-generation iPhone under its AU carrier brand. AU will sell the iPhone 5 (tentative name) in October.
The old one-carrier-per-country model previously favored by Apple is being abandoned in its bid to better compete with Android which is supported by all 3 major Japanese carriers.
It is expected that this move will have a deep impact on current smartphone shares for iOS and Android.
Also, it is curious that NTT DoCoMo was not the next carrier to offer the iPhone as its network is much better prepared for it. Prior to the arrival of smartphones, AU was better known for its less-is-more strategy and its limited 3G network rollout as a reflection of this. It’s clear that KDDI has cemented its reversal of this strategy with this announcement.
Interesting times ahead!
I’ve been hard at work on the development of KEYBOX Release 2 and I’m happy to report that it is nearing completion.
My plan is to make it available after I’ve confirmed compatibility on the next version(s) of the iPhone with iOS 5.0.
Aside from many improvements, Release 2 includes an important fix for a compatibility issue regarding importing secrets via Safari 5.1 in Mac OSX Lion. Safari 5.1 caught me off-guard because I released KEYBOX just prior to obtaining lion.
As much as I want to get this fix into everybody’s hands as soon as I possible I am not willing to do so at the expense of getting caught off-guard again by such OS changes. I could risk breaking the working order of KEYBOX for everybody.
Having said all this, I appreciate everybody’s patience and Release 2, like all upgrades, will be free of charge, and a worthwhile one you’ll all love.
I have been testing the solution proposed by StackExchange user ‘shipmaster’ for obtaining a MAC address as a device ID.
I’m a private person, as everybody knows, so I won’t be posting the MAC addresses of my various iOS devices but I will say that I was able to confirm the the MAC address’ suitability as a UDID replacement.
How I conducted my testing
Across two iPhone 3GS units and one iPod touch 4th gen unit with two apps (KEYBOX and KEYBOX lite) I was able to reliably retrieve the per-device MAC addresses across distinct apps regardless of whether using Wi-Fi, 3G (only tested on iPhone 3GS as iPod touch doesn’t do 3G) and in Airplane Mode.
I do not own an iPad or iPad 2 with which to test but I suspect MAC addresses will make for reliable UDID substitutes there also.
It would be great to hear from iPad owners who have tried this technique. Please contact me at jay@jayfuerstenberg.com.
Nobody in Eastern Honshu (Japan’s main island), myself included, will ever forget the March 11th M9.2 Mega Quake.
An earthquake of this scale produces aftershocks the likes of M6~7 and during the first month we witnessed aftershocks at least M5 every hour. It tested everyone’s nerves to say the least.
Shortly after the megaquake many iPhone owners proceeded to download a free app ゆれくるコール (Roughly translated: It’s about to shake call). For a few months this app worked extremely well. The sound it emitted was similar to the early warning we hear on TV.
But in recent months this app’s reliability has degraded. So it’s welcome news (as reported by 9to5mac.com) that Apple will be embedding early earthquake detection service directly into iOS itself!
This is a facility DoCoMo subscribers have had forever, even in feature phones and it’s a joke among Japanese and expats here that we hope to be near a DoCoMo user whenever the big one hits! Now we’ll have to extend that to iPhone users on SoftBank as well!
As posted yesterday, the UDID is being deprecated from from iOS 5 and will possibly be phased out in iOS 6.
This is mostly a good thing. Since the UDID does not change between the apps we use nor the sites we visit a very specific bread-crumb trail of our movements can be determined. It’s akin to leaving your business card at every restaurant and shop you patron. If all those cards were entered into a shared database the type of person you are and what your likely interests are can easily be guessed.
However, some of us developers simply want a means to distinguish the users who use our apps. The UDID was the silver bullet and its deprecation presents challenges for us.
A GUID is one partial solution to this. GUID stands for Globally Unique IDentifier.
The properties of a GUID
Unlike a UDID which is tied to the device, a GUID is not necessarily tied to anything. It’s just a unique ID.
A user could have many GUIDs so it’s impossible to say that GUID A and GUID B are 2 distinct people as the same person could own both. However for most purposes a system which separates content by GUID can reliably keep my documents separate from yours on the cloud.
GUID Generation In Objective C
Generating GUIDs is trivial. KEYBOX generates GUIDs to uniquely identify each secret across exports and imports. Here is the relevant snippet of the GUID generation implementation used by KEYBOX.
+ (NSString *) generateGuid {
CFUUIDRef uuid = CFUUIDCreate(NULL);
CFStringRef uuidStr = CFUUIDCreateString(NULL, uuid);
CFRelease(uuid);
[(NSString *) uuidStr autorelease];
return (NSString *) uuidStr;
}
It won’t help determine the exact device or its user nor will it help track users across sites or apps but it will help to assign identifiers like Twitter User Numbers to users who want to sign up to a cloud-based service.
In the end it may prove the most balanced ID system for users and developers.
TechCrunch’s Erick Schonfeld is reporting today that iOS 5 comes with a big surprise in that developer access to the UDID, the device’s unique ID number, is being deprecated.
What does this mean?
As early as i0S 6 perhaps, we developers will no longer be able to uniquely identify devices. These are good and bad outcomes of this. Developing user profiles based on the apps downloaded and ads clicked begins to get a bit creepy and this will now be thwarted. But some of us developers use the UDID in ways that are not evil per se.
What about KEYBOX? Is it impacted by this change?
Somewhat, yes.
KEYBOX lite uses the device’s UDID to detect when a user is importing an export secret file onto the same device that generated it when the secret file is obviously older than the install date. In other words, cheaters who thought they could back up their secrets, uninstall KEYBOX lite and reinstall it and get another free 30 days of use.
KEYBOX lite then issues a stronger recommendation to purchase the full edition. After all, anybody who loves KEYBOX enough to go through the hassle of reinstalling it over and over ought to just purchase it and support further development.
At no time was this UDID ever transmitted in any form to my site or any other by KEYBOX or KEYBOX lite. In any case I will phase out this check in KEYBOX release 2. I don’t like relying upon deprecated functionality in my apps.
To support BCrypt encrypted login passwords in KEYBOX I ported the very excellent Java implementation by Damien Miller to Objective C. iOS 4.0 unfortunately does not offer this algorithm out of the box the same way it does SHA-256 and AES-256 and many iOS developers are rolling their own or giving up and settling on SHA-256.
Why use BCrypt instead of SHA-256 to one-way hash passwords?
Recently there have been advances in using high performance graphics cards equipped with GPUs to speed up the brute force process of discovering passwords encrypted with SHA-256. BCrypt is resilient against this strategy by virtue of the fact that it employs a very slow work factor in its hashing. This is why KEYBOX takes a little while to log you in. It’s one-way hashing the login password using BCrypt at a work factor of 10.
How to use BCrypt in your iOS app.
My ported implementation is called JFBCrypt and relies on 2 other resources, JFGC and JFRandom, which are located with it in my Github repository. As such, it is fairly self contained and does not require any external dependencies. Just drop these files anywhere in your iOS project and include logic similar to that shown below.
Example usage:
NSString *salt = [JFBCrypt generateSaltWithNumberOfRounds: 10]; NSString *hashedPassword = [JFBCrypt hashPassword: password withSalt: salt];
JFBCrypt is covered under the very liberal Apache license and can be included in both open source and closed source apps. Damien Miller’s original license is also included in accordance with his wishes.
If you have any questions or feedback feel free to contact me at jay@jayfuerstenberg.com.
My sincere thanks to AppFresh Daily for featuring KEYBOX in their TOP 3 apps listing and for their compliments regarding its user interface and powerful encryption.
Before starting, I want to thank my wife and son for their frequent weekend sacrifices over the past year. They literally made KEYBOX possible. I’d also want to thank the reviewers at Apple if for no other reason than their job is a thankless one.
What is KEYBOX?
Privacy is a topic near and dear to me. I wrote the original version of KEYBOX to scratch a personal itch back in 2005.
My apartment was broken into and many of my and my wife’s belonging were stolen, even using our bags to haul it all away. Worse of all the thief left us a note showing off how proud he was. This was not our home anymore and everything we thought was private was no longer. Only after becoming victims did we start to invest in dimple keys and other preventative measures.
For myself, it didn’t stop there. I was compelled to take my privacy very seriously from that moment onward. The original version of KEYBOX was the culmination of careful design and development to address this.
2009 and 2010 were years that presented challenges to protecting people’s privacy. I wrote KEYBOX for the iPhone in response to this changing lanscape.
I don’t believe privacy is a dying concept as Mark Zuckerberg would have us believe. Privacy has never been more important. As we move more of our lives onto the cloud we open ourselves to more security risks. Who we are and what we do is no longer tucked away safely in a drawer in our homes. It’s now sitting on a 24h accessible server on the Internet and we are no longer in full control of our privacy.
How KEYBOX works and what distinguishes it from alternatives is a bit too much for this post. I’ll be discussing the design, development, marketing decisions behind KEYBOX and where the app is going in the future in future posts.
If you are serious about security and your own privacy you can learn more here… http://www.jayfuerstenberg.com/keybox/
A kind reader by the name of SpoonReloaded has helped me optimize the Objective C memory management macros in JFGC.h I introduced in an earlier post.
If you’ve been using these macros in an iOS game or other app where performance is of the utmost importance you’ll stand to benefit from this update.