Projects and observations
Currently Browsing: Projects

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.


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
#!/bin/sh
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
#!/bin/sh
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 = infile.read()
 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.)


Resist

The night of the latest US election was tumultuous for many of us. For me, it meant getting only a small amount of fitful sleep. My mind was racing about what I could do. (Which is telling, I suppose, as at that point I was barely concerned with how things happened, just that they had and that I needed to do something to help.)

Within that mental turmoil, I seized on an image of an inverted capital T – an anti-Trump symbol in my mind. The next morning I spent some time playing around with some designs. It was therapeutic as it kept my hands, eyes and brain engaged in something that, while small, was at least productive.

During that exploration I checked – as I try always to do – on alternate meanings of the inverted T. It never does to introduce a symbol to mean one thing only to find that it means something vulgar, silly, or even opposite in intent in another culture, language, etc. I was very pleasantly surprised to find that ⊥ is also used to convey “contradiction” or “unconditionally false” in mathematics. (And, also, “perpendicular to” in geometry.) So I found I had a symbol that directly referenced an inverse of Trump’s policies that already had very similar connotations in existing usage.

That feels powerful to me.

I released some graphics, made some jewelry, ordered some buttons and bumper stickers, and officially released the design to the public.

A silver metal inverted T charm suspended from a silver chain on a blue background with white stars reminiscent of the US flag.

It turns out this is my most popular jewelry design to date and the buttons and stickers are proving popular too. To be clear, I’m not trying to capitalize on the events in our country (though that would seem to be the most modernly American thing to do) and so I’ve priced everything well below what I would for purely aesthetic designs. My costs are covered and just enough extra is added to let me expand the line, but I’m not making bank on this.

If it means something to you, please use and share.

You can access high-resolution and vector images here: http://www.waaronw.com/resist

By the way, the “Up Tack” character (⊥) is U+22A5 and the similar “Perpendicular” character (⟂) is U+27C2.


Powered by WordPress | Designed by Elegant Themes

Pin It on Pinterest