Tag Archives: iOS

FreeOTP Releases

The past few weeks have seen new releases of FreeOTP on both of our supported platforms.

FreeOTP iOS

FreeOTP iOS
FreeOTP iOS

On iOS, we released a small bug-fix release to the initial version we published several months ago. Aside from a crasher bug, the main theme of this release is UI refinement.

Editing and reordering is now modal. When in edit mode, a single press will bring up the edit menu and a long-press will activate reordering. We also now properly handle scrolling when there are too many tokens for the screen. Lastly, the token is automatically copied to the clipboard when activating a new token code.

All in all, this is a solid release.

FreeOTP Android

FreeOTP Android
FreeOTP Android

On Android, we released a major release which brings many new features and UI refinements. The biggest of these is image support. Images can be selected for each token. Images can also be provisioned to the device via an undocumented OTP URI query parameter. Aside from image support, the UI has begun to shift towards the Material Design specifications (for the upcoming Android L release). This includes a change from the card UI to a grid UI. Additionally, like iOS, tokens are now automatically copied to the clipboard.

One note about permissions is necessary. In the new Android release, the INTERNET and READ_EXTERNAL_STORAGE permissions are now required. In the latter case, this enables us to read images stored on the external storage. In the former case, this permits OTP token provisioners (the people who give you the QR code) to bundle a link to a token image. We feel this features is worth the additional permission. In the case of iOS, FreeOTP already has these permissions and uses them responsibly. Android will be no different. If you don’t trust us, you can read the code.

If you are running CyanogenMod, or have installed an app which allows you to manage permissions on installed apps, you can feel free to turn off the internet permission. You will not lose any functionality except automatic provisioning of token images.

Canonical, Launchpad and Unity

So there is obviously lots of talk about Canonical’s decision to use the Unity shell on top of GNOME, particularly around events that transpired this weekend (which I’m not going to link to since I have no interest in fanning flames). However, I think something needs to be said that is missing in the context of all of these debates. I hope to say this as irenically as possible. In short, I’m not a hater.  Further, any troll comments will be deleted by me.

Although this should be obvious, I’ve not yet seen anyone state it frankly: Canonical has a vested interest in co-opting existing development communities and reconstituting them around Launchpad. This isn’t because they are evil, its because it is their business model. Just imagine if SourceForge made a distro. Would that distro not contain as much SourceForge hosted software as possible? Wouldn’t they try to innovate the distro in order to create a community around their code collaboration platform? Canonical’s business model is, in part, to rapidly innovate their OS using software that is hosted in Launchpad in order to draw users to Launchpad. Canonical is creating a platform, much like Apple:

  • iTunes == Ubuntu One Music Store
  • .Mac == Ubuntu One Sync
  • iOS == Ubuntu
  • App Store == Launchpad
  • DRM == Bazaar (which, some of its fantastic technical merits aside, largely serves as a way to lock people into Launchpad)

Although you might laugh at the App Store / Launchpad comparison, you must realize that in FLOSS circles we buy our Apps via the economy of code (or other contributions).

Unity is just the latest in a string of these attempts.  From Ayatana (a GNOME-based UI usability project that is unrelated to GNOME and hosted by Canonical), to AppIndicators, to Bazaar (a RCS used almost exclusively by Launchpad), to the constant complaint that “Canonical doesn’t contribute upstream”: this is not a mistake, it is Canonical’s business model.

But! But! Isn’t this evil?!

In a word, maybe.  But, I tend to think this is not the case (at least for now).  Canonical has released almost everything they do under an OSI (and I think FSF) approved license.  For this, they are to be commended! Thus, I don’t go as far as Bradley Kuhn (for whom I have great admiration).  At worst I think we can say that Canonical is sort of like the kid who agrees to share, but only at his house.  This points to what I believe is the greatest current weakness of Free/Open Source Software: we have plenty of excellent software licenses which effectively and legally govern the exchange of software, but what we do not have is a way to enforce the various cultures of Free/Open Source Software.*  Thus, while many companies and individuals are participating in our communities, much tension is created when these entities don’t follow our various, and sometimes conflicting, mores.  This is further compounded by the fact that while we formally agree to the basic freedoms provided by Free Software, there is a lack of formal agreement on the proper protocols and manners used when contributing to such communities.  I tend to think Canonical falls entirely in this grey area (intentionally or unintentionally).

I will agree with Bradley Kuhn on one important point: their current copyright assement does make gross evil possible.  If, as Mark has stated, Canonical has no such plans to misuse copyright assessment by making open source code proprietary, they should make a legally binding promise to this affect as part of the contributer agreement.  Such a simple act of good faith would, in my opinion, go a long way towards combating the “Canonical is evil” narrative that is currently circulating among certain journalists and bloggers.

* – I do not here mean to imply only that Free Software advocates and Open Source Software advocates have somewhat different cultures, but even that these cultures differ on a project to project basis, and sometimes multiple cultures even exist within a single project.