Projects and observations
Currently Browsing: Media

Propaganda: TAX THE RICH

When I first conceived of the precursor to Citizen Supported Propaganda, I started to mock up various advertisements that I might like to see be part of public messaging campaigns. One that I think is particularly needed right now is featured here.

We have a strong narrative in this country that our economic woes are due to immigrants and “moochers” who, so the story goes, take more than their fair share of public funding. Many factions in this country have villainized these groups and accused them of being responsible for the accuser’s own poor economic position. Of course we know that no data actually backs up these claims. In fact, the groups that have siphoned off the largest amounts of public funds and who have exploited the economy are those who are already unusually wealthy. Anyone who has looked at the increasing wealth inequality in America will have a difficult time arguing otherwise.

However, we worship and laud these incredibly rich individuals and families. We idolize them and see them as role models. Whether it’s reality or scripted TV, megastar performers, or classic “old money” aristocrats, we seem to be crazy over rich people and, perhaps more accurately, the lifestyles they lead. I think we need to begin to change this public sentiment. We need to look at extreme levels of wealth as a sign of selfishness, not success. We need to accept that, while we may be a bit envious of their position, ultimately it is this group who is taking more than their fair share and this group that must be brought to heel.

In this vein, I designed an initial batch of public messaging ads which stress elements about the lifestyles and actions of rich people in an attempt to break the admiration and replace it with revulsion. If we no longer look at rich people as our heroes, maybe we can engineer effective ways to limit their negative impact on the economy and society as a whole.


Photo of a fancy Mercedes car with the text "This is not success, this is selfishness. Tax the rich"

Let’s change the narrative around expensive things.

White text on a black background reading "RICH PEOPLE buy influence and destroy democracy. Tax the rich."

Remind people what they already know.

White text on a black background reading "RICH PEOPLE keep us all down. Tax the rich."

Relate it to all of us – we are in this together

A photo of Warren Buffet with the text "While you ride this train two stops, this man makes over a million dollars doing absolutely nothing. That's what 20 average American families make in an entire year. That's 80,000 hours of hard work. Tax the rich."

Point out just how unequal we are, and how absurd it is to claim rich people “earn” their levels of increased wealth.

White text on a black background reading "RICH PEOPLE will take it all if given the chance. Tax the rich."

Remind people that it won’t get better without action.

Photo of a fancy yacht with the text "Yacht for rent. Just 1.2 Million Dollars Per Week. That's the annual income of 23 American Families. So a rich person can ride in a boat. TAX THE RICH."

Point out just how absurd the luxury market for ultra-rich people is.

Public spaces for the public: Taking a break from the ads

When I first conceptualized Citizen Supported Propaganda, it was after years of thinking about the concept in less over-arching, more project-oriented terms. I have often envisioned a project whereby members of the public (made easier today by croudfunding infrastructure) collectively buy out the advertising in public and quasi-public spaces and, for some length of time, replace it with content that makes simply existing in these spaces more enjoyable while simultaneously calling attention to the lack of advertising present.

As a pie-in-the-sky project, I have imagined taking over an entire concourse at a busy airport. Through the years, the project has variously included displaying classic art with no textual mention of the lack of ads, to the idea of having every single ad surface plastered with “This is not an ad” and similar messages. While I think that the most effective message is neither of those extremes, this thought of removing advertisement from a space where many people spend substantial time is something I can’t shake.

Other venues provide a much more accessible laboratory for this kind of intercession. In Boston, for instance, I know that public transit advertising packages start at about $8,000. This is a number that is reasonable to raise from a small group. I question often, however, whether the distributed campaign that eight grand brings could be made as effective as, say, a single subway car take-over. Is it better to reach more people with a simple message among many (distributed campaign) or to provide fewer passengers (a take-over) a much more intense experience? My gut feeling says the latter is true, but I have not yet researched this enough to know for sure where the biggest bang-for-the-buck is likely to lie.

I hope to get the chance to research this more fully, by both looking at what others have found in the past as well as conducting experiments myself. In particular, I want to know what the lasting effects of these different modes of presenting public messages might be. A year later, say, are people more likely to be influenced by one or another? Are more people influenced in one scenario over the other? Can any of this lead to lasting mind change?

We shouldn’t have to wait for camera encryption

I recently completed a project wherein I built a proof-of-concept encrypting camera that included no changes to the essential hardware or user interface of the device, yet provided strong, on-the-fly encryption of digital photos. I want to discuss more about why I created that project.

I have been aware of the targeting of journalists for decades. This is certainly not new – leaders of all kinds of organizations have known that keeping information out of the public view is how power is amassed and retained. Stories of journalists detained, and even killed, existed in my childhood. The Committee to Protect Journalists counts 1237 journalists killed since 1992.

Throughout this time, the raw information collected by journalists has also been a target. The seizing of cameras and notebooks is not a new phenomenon. The difference today is in the magnitude of information that is captured by journalists and the difficulty in securing it against seizure. Not only that, but the very equipment that journalists have come to rely upon can betray them in ways that notebooks and film cameras never could. We no longer expect journalists to return from the field with a couple of notebooks and a few rolls of film, but rather with hours of video and audio recordings, detailed location information, and thousands of high-resolution photos of their sources. To capture and store this information, journalists rely on a lot of technological equipment.

Yet the industries that provide this equipment are stubbornly behind in providing what should be considered routine and minimal capabilities to protect users, including journalists.

I was fortunate enough to attend MIT Media Lab’s Forbidden Research conference last year during which Andrew “bunnie” Huang and Edward Snowden released their initial research into better tools for monitoring cell phone transmissions. (It is possible for some phones, even in an “off” state, to transmit wireless signals.) One of the inspirations for this work was the tragic story of Marie Colvin.

Marie was a journalist in Syria preparing to report about attacks on civilian targets near the city of Homs. She and photographer Remi Ochlik were killed when radio emissions from their electronic devices, including cell phones, were used to find and target their camp with artillery. This deliberate, state-directed act against a journalist really made clear how the vast amounts of technology that have become mainstays of the journalist have also substantially increased the risk they take.

While I may not be able to do much about rogue wireless transmissions (other than to remind everyone to carry a good faraday bag), I do think I can shed a little light on how direct the path to better encryption on cameras is. As a letter, published by the Freedom of the Press Foundation and signed by 150 documentary filmmakers and photojournalists says, many manufacturers of electronic equipment have begun to implement strong, useful encryption on devices, putting the notes and other content gathered by journalists beyond the reach of those who may want to use it nefariously. However, in the area of high-quality, professional cameras, no on-the-fly encryption is currently available.

This is, simply, not an excusable state. There are no good excuses for Canon, Nikon, Sony, Fuji, Olympus and others not to have added real-time encryption by now. The professional cameras offered by these companies contain very fast processing chips, and while the pursuit of faster frame rates and quicker focus is to be lauded, to not give users the choice to trade some of that performance for basic safety is pernicious.

The driving factor behind why I created my proof of concept encrypting camera is to show that it is possible to retrofit current camera models – even those on the market for years – with strong, easy-to-use encryption without hardware or user interface updates required. I want to show that it is not technical limitations preventing camera vendors from producing these devices but rather an unwillingness to provide the technology that keeps our journalists (and others) in unnecessary danger.

Cameras are seized all the time throughout the world, and with every seizure both the journalist and their sources are endangered. The Committee to Protect Journalists tells Freedom of the Press Foundation:

“Confiscating the cameras of photojournalists is a blatant attempt to silence and intimidate them, yet such attacks are so common that we could not realistically track all these incidents. The unfortunate truth is that photojournalists are regularly targeted and threatened as they seek to document and bear witness, but there is little they can do to protect their equipment and their photos.”

I am tired of waiting for companies to decide adding encryption is a commercially viable feature. I’m tired of companies actively endangering the lives of journalists when this problem that is as old as photojournalism itself can finally be solved. While the best user experience may, indeed require hardware updates, camera vendors can fix this problem now, with a software update alone, so don’t believe any of them that claim there is a major technological hurdle to jump. Don’t believe them when they say you must buy a pricey new model to get these features when they eventually do show up. These cameras can offer encryption today, and vendors should be racing to provide it.


Note: Look, cryptography can be complex and getting it right requires time and care, I fully understand this. Additionally, retrofitting a custom processor for new tasks can be problematic and may not result in the best possible performance. However, my research indicates that the custom processors in digital cameras may be well-suited to encryption tasks, even though there will certainly be a substantial performance penalty to pay initially. This is not an excuse for not offering the security and safety of a software update enabling real-time encryption for, at a minimum, still photos to those who are willing to make the trade-off.

Automatic Encrypting Camera Proof-of-Concept

A collage including people icons in the upper right, a camera icon with a compute chip and key icon included, and an old-style photograph with the image replaced by random text representing an encrypted photo.A few months ago, I ran across a post at Boing Boing by Cory Doctorow in which he relayed the desire of journalists to have cameras that would encrypt images on the fly. The uses for this are many and can protect journalists and also, crucially, those the journalist has documented. Siezed images can be used against people by governments and other agencies. It seemed a pretty sound idea to me.
The post imagines the requirement for new user interfaces on cameras to allow the entering of passphrases and the like. While certainly I don’t think that would be a bad idea, the format of dedicated digital cameras does make it a challenge. Small screens are prone to typing errors when using touch-screen keyboards and the small form factor of most dedicated cameras limit hardware input options. However, what immediately struck me was that no changes really need to be made at all, as long as one crucial trade-off is accepted: not being able to review images on-camera.
Since public key cryptography feels well-suited to the task of encrypting images on the fly, I imagined an interfaceless update to existing cameras that would provide strong encryption but without the need to enter a passphrase or any other information. It is, effectively, transparent.

Here is the system I imagined:

  1. Use a well-known (and thoroughtly vetted) public key crypto package on a computer to generate a keypair
  2. Copy the public key to the removable media used by the camera
  3. Insert the media in the camera, which imports the public key included thereon
  4. All images taken by the camera and written to the media will be encypted by the key included on that media
  5. The key is purged from the camera when the media is removed

In this system, the camera never writes an image to storage without first encrypting it. There is nothing for other parties to recover from the media apart from the strongly encrypted images and the public key – which cannot be used to decrypt the images stored. This does bring up the one tradeoff I mentioned previously – there is no way to view any of the images taken on camera. In practice this should not be too difficult to live with as taking lots of shots to be sure a good one is captured has become standard practice, but certainly this could be an unacceptable tradeoff in some situations.


Theory is all well and good, but I wanted to see if this system could be realized in the flesh. Since affordable prototyping platforms abound these days, I decided to build a proof of concept encrypting digital camera.

First, I chose a platform – this was a very easy decision. I went with the Raspberry Pi as it is readily available, has substantial online resources available for it, it very cost effective, and supports a native camera device. It ended up being particularly wonderful that Adafruit (an online retailer of electronics) also had a tutorial and software available to turn the Pi into a ready-to-use point-and-shoot camera — that made this a relatively straightforward project.

A clear plastic box containing a circuit board and camera. A power cable is attached to the top and a removable USB drive to the side.

The Raspberry Pi 3 with camera mounted in a case from Adafruit

Step one was getting the hardware. As I live in the Boston area, I’m lucky enough to have a Micro Center local to me which carried everything I needed. (I used the BOM from Adafruit’s camera build.)

  • Raspberry Pi 3 (the faster processor is good for prototyping and encryption, but a Zero might work)
  • Adafruit touch screen
  • Nifty case for the screen+Pi
  • Pi camera w/cable
  • 64GB USB flash drive (I used one with an A and micro-B connector so it could be tested with a Zero in the future – one could also use an SD card reader with card.)
A black plastic case with an opening for a 2.3" touch screen displaying a "gear" and "play" icon. Four hardware buttons are on the right of the case, a USB drive is attached on the left and a power cable is attached on the top.

The back of the Adafruit case with their touch screen installed displaying the camera UI developed for the linked tutorial.

From there, I simply followed Adafruit’s tutorial until I had a working digital camera. If you’d like to build one of these for yourself, follow Adafruit’s build and then come back for the rest.

Please note that this is intentionally not a detailed tutorial. This is a proof-of-concept project and it is not audited or secured in any way. If you need the protection of an encrypting camera, you’ll need to understand it deeper than following a recipe allows. However, below is a discussion of the steps I followed to implement the camera along with snippets of my custom code. With work and understanding, you’ll be able to re-create my project.

Once I had the camera working, I needed to identify how I would have the system perform the encryption. I chose GPG (Gnu Privacy Guard) because it is well-vetted, available for every platform, includes a Python library (conveniently, the camera software is Python) and already familiar to many. I installed GPG on my laptop and on the Pi and performed a few excercies to familiarize myself with the tool, such as generating, exporting, and importing keys, and encrypting/decrypting files between systems. Once I was comfortable, it was time to automate things on the Pi.

I installed the usbmount library on the pi and created a mount script for my USB device in /etc/usbmount/mount.d. Usbmount allows the system to automatically run a script when a specific USB device or class of device is inserted or removed. An included script ensures that the flash drive is always mounted at /etc/usb0 so I can make sure to put images in the right place. My custom script then automatically imports a GPG key from the “key.asc” file found on the drive into a known GPG homedir. That way the camera script has the key available in a known location later. In addition, I created an unmount script that removes the key from the system once the drive is removed.

Mount Script
mkdir /tmp/gnupg
export GNUPGHOME=/tmp/gnupg
gpg --import /media/usb0/key.asc
gpg --list-keys --with-colons 2>/dev/null| awk -F: /^pub/{print\$5} > /tmp/gnupg/keyid
exit 0
Unmount Script
rm /tmp/gnupg/*
exit 0

After a few rounds of testing, I was ultimately happy that this solution was reasonably robust. To get the key onto the camera, one only has to export it from GPG into “key.asc” and place it in the root of the media. Every drive/card could have a different key if needed, and all could be prepared ahead of time. (In fact, the system containing the private key need not even be in the same country as the camera or even available to the camera user!)

Next, I needed to modify the camera script that was installed as part of the Adafruit tutorial. This turned out to be pretty straightforward. (Though there was a bit of trial-and-error getting the python gnupg package to properly encrypt.) Ultimately, I simply needed to intercept the saving of the image to camera, run the in-memory image through the encryption package instead, and redirect the output to the configured USB drive. Just a few lines of code (mostly to import and configure python-gpg) were needed. Note that I did not take the time to disable alternate saving methods like Dropbox, and I did not test what happens should one try to use them with my script modifications.

#At the top of the file with the other imports:
import gnupg

#I modified the array (~line 260) used to direct where images are stored this way:
pathData = [
 '/media/usb0/DCIM', # Path for storeMode = 0 (Removable Media)
 '/boot/DCIM/CANON999', # Path for storeMode = 1 (Boot partition)
 '/home/pi/Photos'] # Path for storeMode = 2 (Dropbox)

#In the takePicture() routine (about line 450) I added these GPG-related lines to
# read the key ID that the usbmount script helpfully stored for us:
gpg = gnupg.GPG(gnupghome = '/tmp/gnupg')
 infile = open('/tmp/gnupg/keyid', 'r')
 gpgTempKey =
 gpgKeyID2 = gpgTempKey.rstrip('\n')

#A little further down in takePicture() I intercepted the camera capture
# and writing commands and replaced with this:
camera.capture(camera_image, 'jpeg')
#I found gpg.encrypt didn't play well with the BytesIO() object
temp_image = camera_image.getvalue() 
#encrypts and automatically writes the output to filename
encrypted_image = gpg.encrypt(temp_image,gpgKeyID2,always_trust=True, output=filename) 

A photo inside a building including part of a table-top in the foreground with a wood door and glass door in the background a few feet away.

This haphazard photo of the inside of the Democracy Center in Cambridge, MA was the first encrypted photo to be taken with my camera.

Finally, I had a working Encrypting Digital Camera! Whenever I insert media in the camera that contains a valid GPG key in a file called “key.asc” the camera then begins to encrypt every image taken until the media is removed. On my computer, I can then use the private key (protected by a passphrase) to decrypt the images on the command line and I’m left with pristine* jpgs! (*Well, 8MP noisy JPGs but that’s a function of the mediocre Pi camera, not the encryption!) It’s not exactly fast, though. It took approximately 6-10 seconds to encrypt and write the JPG to disk. Of course, this is a low-powered processor and a single-threaded encryption engine. It is, however, a very successful proof that this system can work.

I have shown that with minimal software changes, cameras can support robust encryption with no changes to user interface at all. I would hope that we see commercial camera producers consider integrating a system like this in the near future. Additionally, I have to wonder if third-party firmware updates (like CHKDSK for Canon cameras) could add such support. At worst, with some effort, platforms like the Raspberry Pi could offer a decent starting point. Of course speed may be an issue until dedicated encryption hardware is added to cameras. I am unclear as to how well-suited the DSP custom processors found in digital cameras could be adapted for encryption tasks (possibly very well!) but in the near future, retrofit software would probably preclude the super-fast capture rates that professional photographers have come to expect.

Now, for the BIG HUGE DISCLAIMER: This is a PROOF OF CONCEPT. While I’m providing some code snippits here so that others can recreate my work, it’s super important that everyone understand that this project has not be audited or vetted by security professionals, nor was it created with the intention of being used in the field. It’s possible that this project could give some level of protection as-is, but it’s also possible that there are glaring errors that would erase any gains or even exacerbate the situation you may be trying to avoid. Please don’t use this in production! (As a note, I have made no attempt to harden the Pi against access, for instance via wifi, ethernet, or USB. It could be trivial to circumvent the entire encryption system via these vectors.)

Why is it so Wrong to be Wrong?

The text "Evolution of Beliefs" behind the universal symbol for "Prohibited"

We aren’t allowed to evolve our beliefs.

As I continue to think about how we may be able to really change minds over the long term, I have been regularly struck by just how horrible our society sees being wrong. Apart from a tiny (and privileged) community in the startup world espousing “fail early and often,” being wrong is seen as anathema today. It seems impossible for anyone to change their minds without being ridiculed and embarrassed. And I don’t think this is only for the Big Things nor is it reserved for well-known people.

Until we can de-stigmatize changing one’s mind, we are likely to make very little progress towards ways to actually do so.


« Previous Entries

Powered by WordPress | Designed by Elegant Themes

Pin It on Pinterest