Guardian – Page 2 – nathan's open ideals

The Droid's Dharma: Supporting the Tibetan Language on Android

DISCLAIMER: I am by no means an expert in this issue – I am just an an enthusiastic hacker with a dream. Also I don’t read Tibetan, but I enjoy looking at it!

Thanks to the open-source movement and the hard work of many Tibet supporters and typography experts, I am happy to announce that rendering of Tibetan characters is now supported on the most fantastic of mobile smartphones, Google Android!!!

Tendor’s Yarlung Raging blog viewed on a T-Mobile myTouch3G Android Phone

While it only has a small alphabet of characters, the Tibetan language has been notoriously difficult to support on Mac, Windows and Linux due to some complexities in how one character can modify the next. Dedicated academics, volunteers and software engineers have stayed focused on solving this and the most recent versions of all major operating systems are able to render Tibetan and provide Tibetan character input tools. Google Android is based on Linux, and fortunately is able to support the use of the GPL-licensed Tibet Machine Unicode font.

However, by default Android only has a small number of fonts built-in, and doesn’t support the easy addition of new fonts or locales. It does however have something called the “fallback” font, which is used to render any encoded text it comes across that it doesn’t quite know what to do with.

What I realized is that you could replace this font with a Tibetan unicode font compatible with Linux, and that this would then enable Tibetan support in all applications on Android, including the web browser, email apps, instant messaging, and short messaging (SMS), among others.

The steps below outline the technical how to for Android users.

WARNING: This is not for novices. However, it isn’t rocket science either. Your average neighborhood mobile phone enthusiast should be able to figure out how to do this, and potentially help their friends do it too. Down the road, I hope we can make this process easier and/or Google will allow for the addition of any font to the system.

Step 1: Get Root on your Android device. You don’t need to mod your phone with a custom firmware, you just need root access to change system fonts. Here’s some places to start looking on how to (this changes weekly, btw, and differs for each type of Android phone):

Step 2: Download Tibet Machine Unicode font. You can learn more about the variety of Tibetan fonts available here.

Step 3: Make the system font folder writeable and backup the existing font
This can be done using desktop ‘adb’ tool from the SDK or the Android terminal app on the device

# su
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system/fonts
# cd /system/fonts
# mv DroidSansFallback.ttf DroidSansFallback.ttf.bak
# exit

Step 4: Write the Tibetan unicode font as the new fallback font:
Using ADB Desktop tool with Android connected via USB

adb push TibMachUni-1.901b.ttf /system/fonts/DroidSansFallback.ttf

Using on-device terminal app:

#cd /system/fonts
#wget -o DroidSansFallback.ttf http://tinyurl.com/tibfont /system/fonts/DroidSansFallback.ttf

Step 5: Reboot your Android phone

Step 6: Point your Android browser at http://yarlungraging.blogspot.com, http://lobsangmonlam.org/ or http://tb.tibet.cn to verify the Tibetan font support is properly installed.

What’s Next

Two big steps from here… this is a call to action for Android developers out there:

Develop a one-click app that can install Tibetan (or any other third-party language) font for any rooted device
Port an existing Java-based Tibetan input utility into Android as an Input Method Editor so that you can have a way to write Tibetan character emails, SMS messages and blog posts.

Many thanks to the authors and developer behind the following posts upon whose work this effort was based:
karuppuswamy.com: How to change fonts in Android?
karuppuswamy.com: Mounting /system partition in read-write mode in Android
android-devs.com: Adding Additional Language Fonts to Android

Mobile Apps under Duress: User Interface Guidelines

One of my students at ITP is working on a mobile application for the Android platform that will be used under duress and in generally stressful conditions. These situations might include documenting children at a refugee camp, capturing medical information in a remote clinic, or identifying victims after a national disaster.

I’d like to use this post to build up a list of useful guidelines for building mobile application user interfaces that can be effectively used during these situations. More specifically, with the capabilities of modern smartphones (large screen, capacitive/multi-touch touch, accelerometer, compass, camera and so on), what more can an application provide than just dumb entry forms and checkboxes.

Here’s my start… please add your own in the comments!

Applications must be INSTANTLY responsive. Not only is there no time to lose in these situations, but the patience of the user will be at an all time low. Any data lookup should be cached, paged or otherwise optimized.
Common tasks should be “shortcutable”… perhaps the user should be allowed to define their own shortcuts.
Any queries or searches should be auto-magically remembered and available via dropdown so that the same text doesn’t have to be remembered multiple times.
All actionable buttons/icons should be large… at least 64×64.
Lists of selectable, pre-populated options should always be used instead of freeform text entry to improve accuracy of data entry. If freeform is required, suggestions for existing matches of data should be provided.
Any network transmission of data or remote access should be done in the background without interrupting the work at hand. Again, remember the user should be expected to have ZERO patience.
All color palettes should be HIGH contrast – the lighting situations may not be good AND the device screen brightness will most likely be set to very low in order to maintain the best battery life
If the camera is expected to be used for image capture, remember that a 3 or 5 megapixel image can be quite large. Determine the need for resolution quality of the documented image and downsize that at capture time. Otherwise, loading, saving, and transmitting the captured photo could take up a lot of processor time and battery life.
Make sure your UI works in both portrait and landscape modes… you just want the app to work no matter which orientation the device is being held.
GPS – if you can use geolocation data to make the life of the user easier by prepopulating data or automatically geotagging items, then do it! However, they may need to turn off GPS in order to save battery life, so make sure to gracefully degrade.
Any persisted data should be stored on the external SDCard storage so that it can easily be removed, backed up, read on a PC, etc… the phone might die, but you should be able to pop out the card and put it into a SDCard reader for any device to read. This may mean that instead of using the SQLite database on the device, you instead use an XML, JSON or CSV format on the card.
If you need to record audio notes, a bluetooth or wired headset should be used. The built-in mics aren’t very good on most devices out today.
Swiping, multi-touch or other gestures can be very natural and intuitive UI control mechanisms if used properly. If your applications lends itself to these, make sure you work closely with users to make sure they work… they should be almost natural for a user to do (like swiping photos left and right in a photo gallery) as opposed to some complex secret handshake.

Any more? Please add your ideas in the comments below…

Orbot: An Anonymous Proxy for Android using Tor

I’d like to make this post without much fanfare. Just looking to share information on the work I’ve been doing with the fantastically radical team over at the Tor Project, as part of my work on the Guardian Project. We have successfully ported the native C Tor app to Android and built an Android application bundle that installs, runs and provides the glue needed to make it useful to end users…. secure, anonymous access to the web via Tor on Android is now a reality. (Update: Tor doesn’t magically encrypt all of your Internet activities, though. You should understand what Tor does and does not do for you.)

However, there is still much work to be done… read on!

1) Tor 0.2.2.5-alpha release contains all the necessary code for building the Tor binary exe using the Android C SDK. I utilized http://github.com/tmurakam/droid-wrapper toolchain wrapper scripts to make life easier. This will produce the output Tor exe that can run on Android w/o needing root.

Update: Thanks to Jake, you can now read the updated Orbot BUILD doc for the step by step build how to.

(thanks to ioerror for the pic)

At this point, we are pretty convinced that the performance and efficiency of the C binary is quite significantly better than the Java-based ports of Tor running within Dalvik… this translate to a better experience for the user, with no noticeable increase in battery drain or lag on the rest of the device while Tor is running in the background.

2) Orbot – this is the new Android app which bundles the Tor binary, handles its proper installation on the device and then provides a gui for starting/stopping, view the log and torrc, etc. It also provides a built-in HTTP Proxy and is licensed under the Tor license.

Just to be clear – we aren’t using the NDK or a shared library… we are actually extracting a binary and managing it via Runtime.getRuntime().exec() calls. This is 100% supported – who knew?! More info on how to do this here

The first code is up here… all is working, but def needs much polish:
https://svn.torproject.org/svn/projects/android/trunk/Orbot/

This post is in part a call for developers to contribute to the continued development of Orbot, so we can get it to a 1.0 state. The other big task is to modify the open-source, privacy focused Shadow browser, from the University of Cambridge DTG group, in order to make it work with our HTTP proxy. That would be a really great step forward, as right now, we have to ask users to set their global APN (read: https://svn.torproject.org/svn/projects/android/trunk/Orbot/INSTALL)

Thanks for everyone’s help and support to get here. I’d like to keep pushing on to a public release via the App Market very soon. Let me know if you’d like to contribute in any way – code, screen designs, icons, testing….

Domo arigato, Mr. Orbot-o!!

My thoughts on the Google Android v. Cyanogen Kerfuffle

A few of you know that I’m a huge fanboy of something called the CyanogenMod. If you have a Goodle Android phone, like the T-Mobile G1 or myTouch, watch out, because before you know it, I’ll have it rooted and running an alternate version of the operating system.CyanogenMod is like Ubuntu for mobiles – the sexiest, smoothest running “distro” you can get your hands on, and that you want to show off to all your friends running lesser, closed, proprietary operating systems (especially ones distributed by Apple). CyanogenMod exists because Android is an open-source mobile operating system – in fact, it is the only commercially viable open-source mobile operating system. When the words “open-source” and “commercially viable” exist in close proximity to each other, I usually start talking too fast and wave my arms excitedly.

Recently, a kerfuffle arose where in some overeager/ever-vigiliant IP lawyers at Google sent the developer of Cyanogen a CeaseAndDesist letter, because in his custom distro of Android he included certain closed source applications that are NOT part of Android. Unfortunately, the closed source applications weren’t just some utilities or demo applications, but actually GMail, Google Maps, YouTube and the Android Market. It could be stated that these are pretty much the essential end-user experience for the common user. In addition, some of the companies behind the hardware device drivers in the ROM are also beginning to complain.

However, Cyanogen, being the innovative, clever hacker he has revealed himself to be, along with the hundreds of other Android MOD hackers out there, are bound to come up with a clever solution to this mess shortly. After all, when you purchase an Android phone off the shelf, you buy the right to a license of those applications, and should be able to continue using them on your device, regardless of the underlying operating system flavor you are running. (To keep abreast of the latest developments, which seem to be taking new twists and turns each hour, you should check http://twitter.com/cyanogen)

Finally, I just wanted to state some points about my perspective on the “open source”-ness of Android and the possibilities for any project looking to distribute custom MODs of it , including my own Guardian Project:

Android is not completely open-source; we’ve all known that for awhile, specifically b/c the entire baseband layer and radio firmware are closed source. These are the pieces that manage the GSM radio, controlling all the actual interface into the wireless network. This is just the reality of the mobile phone industry today. (Mad props to OpenMoko and BugLabs for making actual, true completely open-source mobile software and hardware.)
Having custom MODs of Android released without the Google pieces in there by default is actually a good thing… Android has always been perceived as being too tied into Google by default. I want to build the non-Google Google Phone. If Yahoo had a clue, they’d release their own open-source client applications for their mail and map services and make a Yahoogle Phone.
There are plenty of excellent, truly open-source alternatives out there for the market, maps and video players. This will give those solutions opportunities to shine. Specifically checkout the OpenStreetMap-based AndNav and AndAppStore an open alternative to the Market. PixelPipe offers uploads to YouTube, Blip, Flickr and many other media sharing sites. Finally, K9Mail is a open-source email client that works just fine with GMail’s IMAP service.
Android is fundamentally built to route around Google’s centralized control… you don’t NEED a marketplace. You can download and install apps directly via a URL link, send them via Bluetooth, install them from an SD card and so forth.
Just the fact that it is possible for Cyanogen and the tens of other MOD and theme distributors out there to do what they are doing is completely freaking fantastic. We have to thank and commend Google for that. Compared to the glacial speed of OS update release cycle, etc. of Palm when I worked there, Cyanogen is moving at warp speed, embracing the best practices of agile and duct tape progamming.

That’s all I have for now… I’d love to hear from you. Perhaps I being too kind? Any other excellent true open-source alternatives out there for the Google closed apps? What do you think about the possibility for a Yahoogle phone?

Guardian Project: SMS Encryption (non-)Options for Android

My first post was titled “Guardian Approved” as I did want to highlight applications that were of a certain quality or caliber. Unfortunately, in the realm of secure, private, encrypted short messaging (SMS), I can’t really say I have anything to approve! The best, most trusted solution out there (from CryptoSMS.org) hasn’t been ported to Android yet, and the rest of the offerings either cost too much, aren’t targeted directly at SMS, are closed source or generally poorly written alpha quality applications.

I’ve quickly realized that a quality SMS encryption application for Android (along with interoperability with other mobile phone platforms) is a critical application for the Guardian Project to focus on. One of the really cool aspects of building apps for Android is that you can completely replace the core applications on the device, meaning that an encryption-enabled SMS application isn’t relegated to a third-party status within the device. It can actual take over and replace the built in “Messaging” application and seamlessly handle SMS traffic and transparently handling encryption of messages to and from those addresses you have done a key exchange with.

Where Its At

In the meantime, here is a quick breakdown of what is available on Android today:

While not used for encryption, ChompSMS represents an excellent example of a “power-up” replacement for the built-in Android messaging application. It does offer an ability to send SMS through their Internet-based SMSC gateway. This means that as long as you have an mobile Internet data connection, you can send SMS messages without being monitored by the local mobile carrier, and even send SMS over a WIFI connection.

Encrypted SMS – $1.99 – “Parents Spy Much? Here’s your solution!” – This app is clearly targeted at the “passing secret notes in class” audience and not meant for anything serious. The encryption used seems to be of the basic letter substitution pig-latin variety, which could be cracked in about two seconds by someone with a pencil and paper.
Platinum RSA SMS – Free – “Encrypted text messaging service for your Android device. 1024 bit RSA math” – While the potential for this app seems good and the heavy use of the phrase “RSA math” indicates they know SOMETHING about encryption, the user interface is very confusing, even for me a seasoned user of terrible mobile user interfaces.
TXTCrypt – $9.99!

“With TXTcrypt just enter your message and a password for it , now the encrypted message can only be decoded with that password , just tell it to someone , and send them message encrypted with it , they can use TXTcrypt to decode it..”. This application is very powerful and well written. However, it costs way too much for what it offers. No key change, no proper integration with SMS… it is just a basic password-based plain text encryption tool.

CryptoSMS

As mentioned before, there is a quality, open-source solution available called
CryptoSMS. From their site: “Cryptosms provides public/private key encryption, key generation and key management. it sends and receives encrypted sms and public keys, de- and encrypts files, offers key verification via fingerprints and provides a secure login. ”

Unfortunately, CryptoSMS is only available for J2ME-based phones today, which Android is not. There is a J2ME emulation app for Android, but it is a terrible user experience. What this is all adding up to is that the Guardian Project must/will plan to contribute to and otherwise support porting efforts of CryptoSMS to Android… while the user experience and integration with Android OS concepts like intents and content providers will take some work, the core engine of CryptoSMS appears to be just what is needed.

If you are in the New York area, and would like to learn more about CryptoSMS, you can attend a workshop this Thursday evening, August 13th, at The Change in Williamsburg, Brooklyn. More information available here…