Nathan Freitas will be on a panel at the 2nd annual Open Video Conference in New York this Friday and Saturday. He will be on the panel entitled “Cameras Everywhere” led by our partners at Witness, on Saturday at 3pm.

Summary: Cameras Everywhere: Human Rights and Web Video - (2:45 PM – 3:30 PM)

Description: Once upon a time, video cameras were rare. Now they are ubiquitous—as are the opportunities to share, use, and re-use video. What are the limits and possibilities of an ethics of openness when it comes to human rights footage?

Videos (particularly mobile and online video) make it possible to document and publicize human rights struggles – from monks marching for freedom in Rangoon and Lhasa, and the election protestors in Tehran, to individual voices speaking out against injustice on YouTube and other online spaces. But despite the growing circulation of images of human rights violations, of victims and survivors, there is limited discussion of crucial safety, consent and ethical concerns – particularly for people who are filmed.

Issues around consent, representation and re-victimization and retaliation have emerged even more clearly in an open and networked online environment, as have concerns about intentionality and authenticity. Video is being reworked, remixed and recirculated by many more people. New possibilities for action by a global citizenry have arisen, but these carry with them substantial challenges, opportunities and dangers.

Presenters:
Sam Gregory — WITNESS
Gabriella Coleman — NYU
Nathan Freitas — The Guardian Project
Steve Grove – News and Politics, YouTube

Following the panel, there will be an open workshop, to continue the discussion and brainstorm new approaches and tools to address the issues raised. This feedback will be gathered and fed into the OVC Hackday, held at NYU ITP on Sunday. Team Guardian will join in with whoever shows up at the hackday, take the ideas from the previous day, and build prototyped mobile video solutions in response to them.

You can get more information and register for the hackday here: http://www.openvideoconference.org/hacklabs/

OVC hack labs: Sunday, October 3

Join us at NYU’s Interactive Telecommunications Program for an all-day open space gathering for innovators of all stripes. Meet and collaborate with conference attendees, HTML5 developers, transmedia storytelling experts, and more. Among the planned activities:

Make interactive HTML5 video using WebMadeMovies technology like popcorn.js
Map out a transmedia strategy for your content
Build a custom HTML5 player for your site
Create robust video sites using the free+open source Kaltura CE 2.0 self-hosted software stack
or just grab a room and hack on your project!

OVC hack labs are free and open to the public.

You might have seen an earlier post I wrote about this here, and I’ve essentially done the same thing this time, but with an important addition of code from Tom that properly stacks the characters (a critical feature often not available in an OS font library), and a new Tibetan font (actually Bhutanese) from Chris which is small, lightweight and efficient enough to be used on Android. All together this provides support for reading Tibetan text on web pages, and within full application user interfaces, eBooks and more.

With up to 32gb of storage possible via the tiny micro SD Card, this one device could probably store and serve up the majority of Tibetan Buddhist texts, not to mention literary, poetic and historic works, that exist, all in a lightweight, energy-efficient device. Since the device is also networked, you can use it to pull down the latest Tibetan language online news and blogs.

And yes, this is all possible because the Nook is based on the free, open-source Android operating system. Yay for freedom in all forms!

Here’s a brief summary of what we’ll be covering:

Join us for this important on-line dialogue featuring Documenting Violations: Choosing the Right Approach from January 27 to February 2, 2010. This dialogue will feature practitioners that have developed database systems to document human rights violations, organizations on the ground documenting violations, and those that are training practitioners on how to choose the right approach and system for their documentation. We will look at options for ways to collect, store and share your human rights data safely and effectively. If you are trying to figure out the best documenting system for your work – or if you have found something that works well, please join us for this conversation to share your questions, ideas, resources and stories!

Featured Resource Practitioners
Featured resource practitioners for this dialogue include (click here for more biographical info):

• Vijaya Tripathi and Megan Price work with the Martus database developed by Benetech
• Agnethe Olesen, Daniel D’Esposito and Bert Verstappen work on the OpenEvSys database developed by HURIDOCS
• Jorge Villagran and Sofia Espinosa of the Guatemalan National Police Archive Team
• Patrick J. Pierce, head of the International Center for Translational Justice – Burma Program
• Oleg Burlaca, utilizes HURIDOCS methodology and working on websites for World Organisation Against Torture and SOVA Center for Information and Analysis
• Patrick Stawski, Human Rights Archivist at Duke University and Seth Shaw, Duke’s Libraries’ Electronic Records Archivist
• Jana Asher, M.S., is the Executive Director of StatAid
• Agnieszka Raczynska of Red Nacional de Organismos Civiles de Derechos Humanos, Mexico
• Daniel Rothenberg is the Managing Director of International Projects at the International Human Rights Law Institute (IHRLI) at DePaul University College of Law

Read on:
http://www.newtactics.org/en/blog/new-tactics/documenting-violations-choosing-right-approach

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):

• CyanogenMod: How To Root
• Android 1-click Root
• Android InstantRoot

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.

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!

1. 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.
2. Common tasks should be “shortcutable”… perhaps the user should be allowed to define their own shortcuts.
3. 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.
4. All actionable buttons/icons should be large… at least 64×64.
5. 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.
6. 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.
7. 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
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. 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…

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!!

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?

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…

The Guardian project has no official relationship with these apps or their creators, but as we work towards developing our own unique software, we want to make sure to shine the spotlight on existing efforts that we admire and which are currently available. We’d also happily collaborate with any of them (or *you* if you are a developer reading this), and have them join our open-source efforts.

The first application is Walkie Talkie Push to Talk, which is a great alternative take on real-time VOIP or standard phone calls. Physical walkie talkie radios and Nextel-style PTT services have long been a valuable tool for many activists, and this application bring that capability to a global scale. Walkie Talkie can be used over GRPS, EDGE, 3G or Wifi networks, as well – whatever is available at the time.

Here’s a short description from the developer:

Walkie Talkie Push to Talk is a mobile application that allows walkie talkie style voice communications. Simply hold down the “Record & Send” button and speak. Messages can be sent to a group of people. Received messages are automatically played. If program is running, incoming messages arrive as soon as 15 seconds. If program is not visible, it polls in the background every 1 minute (to save battery).

The back-end messaging system used by this application is actual POP or IMAP, in other words email! If you utilize a secure IMAP/S connection with the application, then the voice communications are transmitted securely over the wireless network and Internet. If you use a service like Gmail (which offers secure IMAP access), then your access is hidden within the millions of other users accessing Gmail, as well.

Not drawing attention to your network traffic is often as important as securing your data. Also, while Gmail isn’t always the ideal service to use if you wish to retain full control of your data, it is much more difficult for an authority to block than a single proxy or a private server.

A few screenshots below:

Learn more about Walkie Talkie and download it from the Android Market today.