I’ve posted a small manifesto on the (not) mesh experiments I have been posting here. I now call the concept Statuscasting, though I feel that this is a term with a short self life. My goal is to move away from the baggage of mesh, and be as open minded as possible on how mobile devices can communicate without internet or telecommunications infrastructure.
Author: me
Sooper-seekritness is not the problem with Firechat
Here is my first (and most likely a very rare) post on Ello in response to Clay Shirky and apparently Firechat’s Chief Marketing Officer
@cshirky (Okay you got me to use ello!) There are many threats beyond sooper-seekritness, and issues beyond Mesh vs “meshy” that need to be considered. I don’t think anyone in the security/hacktivist community means to be disempowering, but I admit sometimes we have to reduce our public messages to “don’t use X app” in order to be heard. I’ve gone through this same discussion with Tibetans using WeChat – they know they are being watched and logged, and sometimes arrested, but the net benefit of being connected is worth the risk. We then say “use X app, but you should know Y”, which is fine. People in the streets are clearly ready for danger. The bigger fear I have about these communities on WeChat, and the people in the streets adopting FireChat is not what can happen to an individual, but what can happen to the crowd, movement or campaign. When the lights go off, will it really magically mesh as much as they want you to think? Does it defend against misinformation, social engineering, impersonation or have any way to block or defend against bad actors? I think Firechat’s answer would be “yes of course!” and “that is not our problem”, while I and others might disagree. Trust me, I have a long history foisting consumer social media tools onto activists groups, but in this case, I just can’t… yet!
@dalijet No one is trying to smear you. You just need to be ready for the spotlight, transparency and responsibility required when you latch your wagon to situations when groups are hitching their movements, freedom and lives, to your app. It is great if you can both serve humans and solve problems at Burning Man and Occupy Central – you’ve touched on a real base need, and thought outside of the typical architecture. That is commendable. I also know that the Occupy Central folks chose you, so you somehow broke through the noise of WeChat and WhatsApp, and showed them there are more possibilities for connecting. That is also a great feat. Now you must earn the trust they’ve put in you, and that many others surely will down the road, and fulfill the features and functionality you’ve touted. You must ensure your new users communities are not somehow subverted or made more vulnerable, by all choosing your app on which to organize and share. You must stand up to the governments who will undoubtedly come to you and ask you to shutdown a chatroom or block a user. Are you ready for that? Is your business model ready for that? So, don’t get defensive, and either embrace the high-risk user stories you now must adopt, or go back to the playa.
Bluetooth name meshyness on a Linux machine
First committed here: https://github.com/n8fr8/gilgamesh/blob/master/docs/linux-howto.txt
Since the Gilgamesh system uses plaintext bluetooth names for its basic broadcasting communication mode, it is a very easy system to participate in from any desktop system. Below is the set of steps that can be performed at the Linux command line to configure the device name to be up to a 248 byte message (~248 ASCII characters, or ~60 Unicode characters).
These commands can be easily used to build a stationary repeater system, using a high powered bluetooth antenna, or you can just use them to broadcast your own status constantly in the background, to anyone in the area who might be listening.
1) Install Bluez Tools (https://code.google.com/p/bluez-tools/)
> sudo apt-get install bluez-tools
2) Find your Bluetooth adapter
> sudo bt-adapter -l
Available adapters:
default-device-name (A1:B1:C1:D1:E1:F1)
3) Set Discoverable and Powered
> sudo bt-adapter –adapter=A1:B1:C1:D1:E1:F1 –set Powered true
> sudo bt-adapter –adapter=A1:B1:C1:D1:E1:F1 –set Discoverable true
> sudo bt-adapter –adapter=A1:B1:C1:D1:E1:F1 –set DiscoverableTimeout 3600
4) Change the name of your device to a Gilgamesh compatible string (starts with space or special character)
> sudo bt-adapter –adapter=A1:B1:C1:D1:E1:F1 –set Name ” this is my laptop it is a great big BT device”
5) Listen for and discover other devices in the area
> sudo bt-adapter -d
Searching…
[A2:B2:C2:D2:E2:F2]
Name: Now what. This is a message from my phone…yo..
Alias: Now what. This is a message from my phone…yo..
Address: A2:B2:C2:D2:E2:F2
Icon: phone
Class: 0x5a020c
LegacyPairing: 0
Paired: 0
RSSI: -59
Update: Added bash script to make it simpler:https://github.com/n8fr8/gilgamesh/blob/master/docs/gilgamesh.sh
> ./gilgamesh.sh
> Powered: 1 -> 1
> Discoverable: 1 -> 1
> DiscoverableTimeout: 3600 -> 3600
> What’s happening nearby? this is a big ol’ test
> Name: this is a really long string that I am typing now!!!! -> this is a big ol’ test
> checking for local updates…
> Searching…
The Difference between Repeat (RPT) and Retweet (RT) on a Mobile (sorta)Mesh
There are two behaviors I have been considering during my adventures in human-powered mobile mesh these last few weeks. The first is Retweet or Reshare, as invented by Twitter users manually (“RT @foo this is important”) and then later on built directly into the Twitter platform as a feature. The second is “Repeat”, as inspired by radio repeaters.
Retweet (RT) is meant as a human-powered endorsement of a message. The meaning and content of the messages have been ideally verified, or at least the source is trusted.
Repeat (RPT) is meant to allow a message to extend further in its reach, by allowing the receives device to reshare it another 10 to 100 meters from its current and future positions. It is an active way to participate in extending the mesh, but it should not be seen as endorsement of fact or an act of verification or trust.
A mixture of retweeters and repeaters in a crowd, can then extend the reach of a message from 10m or 100m up to say, 400m in the drawing below. A repeater might be a fixed device, say a phone or tablet with a good solid antenna plugged into a battery pack or an outlet somewhere.
A retweeter is more likely a person in the crowd, moving through the area in a variety of directions. As they continue moving however, they will keep rebroadcasting their last few tweets, including the retweet. As they encounter new receivers / lurkers, they will receive the original message, and the mesh is now extended in a non contiguous-manner.
The Gilgamesh app supports a simple two-tap feature to manually reshare any status message you have received. Once this is done, your device then rebroadcasts the message over its Bluetooth and Wifi radios, with the expected “RT @900734 i am live on air” format. Also, remember beyond this particular app, any user can manually set their Bluetooth device name, be it a laptop or an iPad, to use a similar format. The app also now supports an automatic repeater mode, that can be easily toggled off and on. In this mode, *ANY* message you receive is automatically rebroadcast, using the “RPT @900734 does the repeater hear me” syntax. You can see this in the screenshot below.
Ultimately, because we are limiting this experiment to a very simple plaintext status messaging system, we have made our lives very easy, and made the possibilities of successful use quite good. Since we aren’t concerned with routing internet protocol or creating a reliable LAN network that can sustain HTTP, we can take advantage of ideas like non-contiguous meshes, retweeting and repeating to extend the range, reach and impact of the communications.
In the screenshot, you might have also seen the use of direct messages with delivery confirmations. I will cover that in a future post, as it is another complex and fascinating topic of possibilities!
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.
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!