Gilgamesh: Twitter over Bluetooth


Hey, looks, it is like Twitter… except without any Internet! The Gilgamesh App continues to evolves, and is now tagged at 0.0.4. You can unofficially find it on FDroid thought it might take a bit for the latest code to show up there.

device-2014-10-06-165429 device-2014-10-06-165405 device-2014-10-06-165421  device-2014-10-06-165447


The primary update is that I have made the user interface look somewhat like a real app. This includes an easy popup menu to reshare (“retweet”) messages, which helps expand the reach of any message, while the human aspect of it combats spam and false information.

I have also added the ability to send a direct (private) message to anyone easily, as well. The direct messages will be queued and stored until delivered, which means you can send a message when someone is out of range, and it will be delivered if they happen to come into range. Delivery is indicated by a ✓mark.

This is all still operating using the plain text Bluetooth Discovery name hack that I’ve been writing about here for the last week, or so. Any Bluetooth device be it a $1000 iPhone or a $10 Nokia can participate in this network simply by changing their Bluetooth name to have a space in front of it, and then writing their own status updates there. They can view all of the messages as well, by scanning for nearby devices. This Android app simply builds on top of that network to support private messages, and a persistent log of all status/names encountered.

Finally, just to review some of the privacy-enhancing aspects of this app:

  • If you just want to listen/consume information, you do not need to broadcast (make your device visible), making it very difficult to target your device
  • The passive broadcast/discovery conduit allows for people that do not know each other, to passively and async exchange information in public spaces, with their devices out of sight (in their pockets)
  • The asynchronous direct message features allows the exchange of messages in public places without any direct or visible interaction between parties
  • All data received in the app is stored in memory, and not permanently stored to the device. This means killing the app wipes all memory clean, leaving no trace behind.
  • All user identifiers are derived from the device’s ID, and though simple to remember, are not “friendly” in anyway that allows for easy social engineering impersonation attacks
  • If Bluetooth pairing is done between devices, an extra level of identity verification is provided, and an * is tagged to all identifiers when displayed to ensure this is who you think it is.
  • For Direct messages, any device which you have paired with, will use the Bluetooth “secure” socket connection mode, which provides a basic level of encryption and verification
  • No registration, real name, phone number or email is required, providing no link to any other identity
  • All resharing/re-broadcasting of information is powered by human minds and human hands, making it more difficult for any attacker to poison the information flow

As always, feedback on these, the code, the design and the concept, are welcome here, on github, diaspora, twitter, etc, etc, etc… see you around, and I really hope to find you on the Gilgamesh soon!



Retweeting (and Wifi P2P) on the Gilgamesh

The primary question I have received so far when describing how this project is using Bluetooth to create a lightweight, informal mesh, is “how far can it reach?”. The quick answer is “about 10m or 30ft”. That is the typical range of a Bluetooth radio, without interference. Obviously, that is not very far, and the response is usually “Well, can’t I just pass a note or tell the person directly what I want to say?”. This is a fair statement, and so we must do better. In the last 24 hours, I have tested and implemented two new ideas for the Gilgamesh, that address this problem in two very different ways.

First, I have implemented support for Wifi Direct, which is another way that modern Android phones, can create adhoc peer-to-peer networks. It has the same capabilities of discovery and dynamic names that we are build on top of for our broadcast message layer, and so the same hack we using with Bluetooth can be applied here.

wifidirectmsg wifidirect

Unfortunately, the names seem to be of much shorter length (like a typical Wifi SSID), but it can still be used for short messages, and we can come up with a way to packetize messages, as well. The upside of Wifi Direct is that its range is, in open spaces, up to 100m/300ft! That has amazing potential. You can see the relevant code here.

Second, within the limits of Bluetooth, we can employ some useful app behaviors to extend the range of any message. In the latest code, if you have paired with a trusted person’s device (using the built-in Bluetooth settings panel of your device), and the Gilgamesh app receives a broadcast message from that user, it will be automatically re-shared, aka re-tweeted, aka RT. (Yes, we are building old school Twitter here, just over Bluetooth). What this creates then is a chain reaction – “the wave” phenomenon that I blogged about earlier – that allows a message to propagate up to 30ft in any direction, over and over again, as long as there are trusted/paired devices out in the crowd.

paireddevices retweet

By using the RT method, we can see the chain of users who have sent and replicated the message, and that helps embed trust and reputation into the message as well. Anyone looking to spread misinformation, would have to be on the ground in the area, and would need to convince many people to RT them, either through force or social engineering. This is many times more difficult than just being able to send a message in a global chatroom, like you can on some other apps, ahem.

In addition to the auto-retweet feature, anyone can press and hold on a message, and it will allow for a manually RT, whether you are paired with the sender or not. Finally, let’s not forget that anyone with any bluetooth device, be it a simple feature phone, an iPad or a laptop, can participate in this process, by changing their Bluetooth device name manually themselves, and setting it to a retweet message.

Through both of these new concepts, the simultaneous use of Bluetooth and Wifi Direct to extend the range, and the application and human-powered behavior of retweets, we can effectively extend the range of Gilgamesh to as far as you have people participating in it. It can even survive gaps in coverage, as people move from one mesh group to another, they would bring along their retweets.

Finally, if you haven’t yet, please read my thoughts on the four roles that can and need to be played by people and devices, for the gilgamesh to even be more robust.

Thoughts on Four Mesh-y Roles

These are four roles to play in the lightweight mesh concept I have been hacking on, under the name Gilgamesh. The roles are Leader, Lurker, Repeater and Notary. The goal is to provide varying levels of risk, find ways to extend the range of message distribution, and to add a layer of reputation and verification into the system.

These roles map to existing systems like Twitter in a fairly easy manner. Leader is someone who tweets, a Lurker is someone who reads tweets (mostly), a Repeater is someone who retweets, and a Notary is the “verified account” feature.

In the case of a crisis situation, or where apps are not viable, these roles can all be implemented manually, by humans, using the Bluetooth protocol and settings built into their phone directly. However, the plan is to implement these in the Gilgamesh app itself, to really take advantage of the dynamics expressed below, in a seamless user experience.

Leader (Read/Write): In this mode, you are communicating information by using your device radio to broadcast updates and information to all who will listen. This is the highest risk, highest visibility role to play in the mesh. There is also an idea of a Trusted Leader, who is one that you have paired or verified your device with, or been verified by a Notary “Numbers Station” (see below).

Lurker (Read Only): In this mode, the radios on your device are not broadcasting anything, but only set in receive or “discovery” mode. You can receive messages from leaders, but you cannot send anything. It is the lowest risk, least visible role in the mesh. Most people in the crowd, and new users of the app, will be lurkers. Switching to a Leader mode on your device is as easy as entering in a status update.

Repeater (Read/Write): A repeater listens for messages for known (paired/bonded/verified) Leaders and rebroadcasts anything they say, to anyone who will listen. Repeaters can be positioned in central fixed locations, or they can move through out a large area, to really extend the range of the mesh. The last set of received messages from a Leader are repeatedly broadcast on a regular basis, and if any new Leaders come in range, the Repeater will share any messages with them that have not been sent to them before. Repeaters can also be set to only repeat messages from Trusted Leaders.

Notary (Write Only): A notary, or “Numbers Station” is a device, managed by a trustworthy human, that Leaders can add their device ID to through pairing, to spread the device IDs of verified, trusted devices. If you are a Lurker or Leader, and you encounter a trusted Notary, then your device can accept any of the device IDs that are being broadcast by it, as trustworthy.

Feedback and thoughts are welcome here, or on the Github project tracker:

Hacking on a basic Bluetooth mesh-y concept

Inspired and frustrated by the closed, murky, proprietary nature of FireChat, and equally frustrated by my experiencing working on the way too complicated Commotion mesh project, I wanted to find a simple way to answer the question “what do we do when the Internet goes away” problem. FireChat is clearly not the answer for the types of communities I am trying to help, but in its absence, we have no other solutions, it seems.

What I have discovered is that Bluetooth device names (the things  you see when you are trying to pair a bluetooth device to your phone for instance) are actually a really great way to broadcast messages from your phone or computer to anyone within distance. This was partly inspired by the humorous wifi SSID messages that people often use, but the key difference is that Bluetooth device names can actually be 248 bytes long (80-240 letters/glyphs depending upon unicode language), as opposed to the much shorter ~30 character wifi SSIDs. It is also very easy to dynamically change your Bluetooth device name through open programming APIs.

The idea then is to use your device’s Bluetooth name as a kind of Twitter status message bearer, sharing key information during a crisis or as an act of protest/speech. It doesn’t require an app, just a little bit of knowledge and a new behavior. I have built an app (more below) that makes the user experience much simpler, and adds the ability to support retweets/shares (to expand the radio mesh reach), verification, privacy and even encryption (in theory).

To test the basic premise however, if you have an iPhone or iPad, you can set your device name in the general about settings. Then go to the Bluetooth settings area, and you will see all devices that are currently broadcasting. With Android, go to the Settings->Bluetooth screen, and you can “rename phone” from the menu, and set the visibility and timeout of your broadcast. With iPhones, as long as you stay on the Bluetooth screen, it will broadcast. With many new Android phones, you can set your visibility/broadcast timeout to 1 hour or infinite.

You can set a message like “!Gather 7pm at 1st and Main” or “@press please don’t photo faces” or “#Legal Aid is 2125551212”, or even just motivational messages “#staycalm #noviolence” or “#theworldiswatching”. If people like what you have written, they can change their status that message, and rebroadcast another 30 feet in whatever direction they are headed. Again, it is basically Twitter combined with doing “the wave” at a football game, except the wave is powered by these little super computers+radio stations we have in our pockets.

The Gilga app I am working on makes this all feel much more like a chat or Twitter type experience. The app also supports direct messaging using a secured RF socket. The important thing is that there a baseline concept here, that can be tapped into by anyone with a bluetooth device, be it a smartphone, an old Nokia, a PC with a huge Bluetooth antenna etc.

From a threat modeling perspective, there are risks about Bluetooth device IDs being scanned and logged, impersonation attacks based on modified Bluetooth radios, and the same misinformation spreading we see whenever we have an open commons, be it FireChat or Twitter. We have some ways to combat that, but it will be hard. My hope is that, by doing this work in the open, and with contributions by brilliant minds like yours, we can come up with some additional breakthroughs.


Gilga Meshenger: Messaging in the Bluetooth Babylon!

Some notes on the implementation, aka the glorious hack of Bluetooth Device Names. This application was original based on the Android SDK BluetoothChat sample. It used insecure (unpaired) and secure (paired) Bluetooth RFComm sockets to allow for short messages to be sent between devices. The primary modification that this project has made has been to add support for a “Broadcast” mode, that uses the Bluetooth device name, that is public visible during the Discovery process, as the message transport itself.

The design goals of this project are:

  • A truly decentralised application that requires only Bluetooth connectivity and has no central user registry
  • Incredible ease of use that ensures all “mesh” connectivity happens with as little user involvment as possible
  • Ability to enable trust or reputation for specific users or devices you message with
  • A very transient app that stores no data permanently
  • Ability to share the app easily between devices
  • A “fire and forget” mode, where the user can enter a message, put the phone in their pocket, and walk around and area and have it broadcast to all devices it encounters

alt   alt

The key innovations/hacks/revelations that led us to this point were:

  • As of recent Android versions, you can call an API to set your the device’s Bluetooth visibility to a very long time ~1 hour
  • You can dynamically change the Bluetooth device name, and it can be long – up to 248 bytes encoded as UTF-8
  • That the first two things above could be wrapped mostly in API calls the user did not have to see or worry about

Finally, some thoughts on security, privacy and reputation:

  • This app supports both a public broadcast mode, and a private, direct message mode. It is easy to use to both. The direct message mode is optionally secured and encrypted at the Bluetooth level if you have paired with the device/user you are connected with.
  • Impersonation is combatted by simplified user id’s to a short (6 character alphanumeric) value, based on the device’s unique Bluetooth ID. This makes them speakable and easy to remember. If someone says “trust messages from A1BC99” then likely you will be able to rememember that.
  • If you pair with a user (using standard Bluetooth pairing settings), their userid will be appended with a *, to make it even easier to know this is someone you should trust
  • The app ONLY works in Bluetooth mode, so though is no confusion when it might be using 3G/4G, Wifi or some other mode, and possibly go through a centralised server
  • The code is open-source, very small, and the entire app is only 28kb making it easy to audit, test and share
  • We make it easy to “retweet” a message by long pressing on it, which enables reputation for something to be built up by multiple people resharing it. If the user has paired with the user, you will also see the * next to the name to further indicate trust.

Assessing the Impact of Five Years of Mobile Security Problem Solving (and Planning for Five More…)

Below is the text of my successful application to the Berkman Center 2015 Fellows program, including the concept for my fairly ambitious project that I look forwarding to finding some allies and collaborators on during the year.


In a recent leak from the Snowden files, one of the mobile security apps I have developed, Orbot (Tor for Android), showed up in an NSA powerpoint slide explaining the different forms that the Tor anonymity and circumvention software takes. Next to the app’s name was a comment that stated it was “easy to use!”. It was a strangely gratifying moment to know that I had done a good enough job building a mobile version of Tor that it both showed up on the radar of an NSA analyst, and that it merited a positive comment about its usability. It also triggered a good deal of reflection on the impact my efforts were having in the world, and just who was paying attention out there.

It was in the Fall of 2009 that I began work on the Guardian Project, an effort to research and develop open, free security software for mobile devices, with a particular focus on solving problems for people living and working in high-risk, high-surveillance situations. I had recently seen a group of my friends working as undercover journalists in a hostile country, get tracked down, arrested and temporarily imprisoned due to use of their mobile phones to organize and communicate. I was determined to come up with software that would defend against such an situation occuring again in the future. I knew the undertaking was significant, and so I set my horizon five years out, and came up with a feature roadmap that I hoped to fulfill.

That milestone is now looming, and coincidentally it also times well with the beginning of this fellowship opportunity at Berkman. At this point in the project, I and my team have developed and release a number of open-source apps for Android, and recently iOS, that enable encryption and circumvention features for voice calls, mobile messaging and mobile web access. We’ve also come up with some clever ideas like a camera app that automatically blurs faces detected in a photo. There have been millions of downloads, resulting in a hundreds of thousands of active users, around the globe. We have received grant funding from a diverse set of sources, recruited a brilliant team of talented engineers and designers, and generally done well delivering on our promises. The original feature roadmap I set out to build, has largely been fulfilled.

I seek then, some time, a context and community in which to reflect on the work I have done, to asses its merit, worth and impact, and to begin planning for the next five years. Beyond a collection of really amazing, moving emails and anecdotes from real users in difficult places, I still have trouble answering “Who are we helping, and how much?”. I want to ensure we are doing more harm, than good, and that we are actually reaching the types of users we hoped to in the beginning. I seek to understand better the different global, legal, and cultural contexts in which tools for privacy, security and expression are utilized for social change. This can be easily boiled down to questions I often receive when I am giving a mobile security training in some far flung location in the world – “Is this legal for me to use?” and “Can I be arrested for having this on my phone?”. While there is no simple answer, it is also true that there is a huge disconnect between the Internet idealists perspective “If it is not legal, it should be, so you should use it anyways”, and the on the ground reality of being detained and incriminated because of some digital bits in your pocket.

While the tool builders goal is to develop and provide a tangible tool for someone to fight back against oppression and corruption with, they are often unwittingly turning those they want to help into practioners of a type of civil disobedience without explaining to them what the risks of that are. Does the net benefit of the increased mobile privacy, ability to avoid traffic surveillance, and to general keep your plans and dreams confidential to yourself and others you trust, a net positive benefit, versus the increased scrutiny or exposure to incrimination by association one might face? Is it actually safer and more powerful for an activist or organization to operate transparently, in the open, and not expect to have any communications privacy outside of close physical proximity?

These type of questions need to be both researched and explored within an authoritarian state context, as well as within our own democratic (self-inflicted?) surveillance states, as increasing lobbying pressure from law enforcement on legislation might turn my team and I into outlaws quite soon. In other words, the axom “No one has ever been arrested for using Tor” may need to be refreshed soon. The concept of “lawful intercept” is a globally fungable term more better expressed as state-required eavesdropping for corporations seeking to do business in a certain region. Whether the interception is just or not, is the important question, when seeking to develop and deploy tools that improve and empower a community of users.

During my fellowship, I hope to reach out to legal and research resources within the Berkman community to assist in building a global map overlaying lawful intercept laws and capabilities with the robustness of the larger rule of law. Additional layers of data could include records of persecution based on possession or use of cryptography or other advanced communication tools, whether real name registration is required for mobile network use, data on user groups in the area that are known to be using mobile security tools, and information about surveillance infrastructure known to be use at telcos and internet service providers in the region. If possible, details on collaboration or collusion by corporate communications hardware and software companies could also be useful to display. I see this resource both as an effort to bring a spotlight on these issues, and as an active resource for any advisor, trainer, activists or journalists traveling to an area, who wants to understand the challenges they might face in using a particular type of software, or promoting its use to local communities.

For example, as a journalist working in a region, I might want to know if I should encourage my sources to use mobile security software that would protect my communications with them, but also increase their chances of coming under greater scrutiny by network operators? If I am a labor organizer supporting exploited workers, I also need to make sure I don’t radically increase the chance they will lose their job or be otherwise because they got caught using an app. I will research and document these type of user stories, and test them against the resources, to understand the value of this research.

I want the software I develop to work, and to be helpful, useful and empowering. I do not want to just solve for threat X, and not think properly about threats Y and Z. I also know that my work is just one small part of a sea of solutions both free and commercial, attempting to enhance privacy and security for mobile users. The work I am proposing for this fellowship aims to help that larger community of tool builders to think about the use, deployment and realization of their efforts in a more complete way, so that the result can be what we all hope for. It also aims to ensure our users can make the best decisions about the threat they face, and whether or not using a piece of mobile communications software is ultimately beneficial for their situation.

Finally, I envision the output of this work not to be a static report, but a dynamic, shared dataset, that any website or application could clone or tap into. I would ideally also develop a default mobile website or app that would give users a “sixth sense”, warning them of potential risks, by cross-refering their devices network operator, geographic location, and installed applications, with the data available in the networked mobile security risk database.

I cannot think of a better place to pursue this work than at the Berkman Center, within a community of fellowship to help tune, improve and realize this complex effort. I expect there to be good amount of overlap with other communication infrastructure mapping efforts. I also realize that there exists a great deal of expertise well beyond my own into the legal aspects of the issue. This work would greatly benefit from access to these efforts and skills, and I from a supportive network of like-minded colleagues, and thus humbly ask for your consideration of my application.