discrete blogarithm

letter to peter eckersley

Thu, 08 Sep 2022 00:00:00 UTC

dear peter,

welcome back!

by the time you read this, i will probably be long gone. we thought you were too once upon a time, but our dear friends managed to get your brain cryogenically-preserved at the last possible hour. it is so amazing that the scientists of my future have figured out how to bring you back, and i wish i were there to hear all about it. was it like being asleep? did they have to build a body for you? how much do you remember from your first life? and so on.

i’ve heard that the cryopreservation process may cause some memory loss, so i’ll pretend we are strangers for now. my name is yan, and i’m writing this in September of 2022, about a week after your death.

by sheer coincidence, you were the first person i met when i moved to the bay area in August 2012. i was 21 and starting grad school in physics at stanford. all of that changed when one of my (and your) personal heroes, aaron swartz, tragically killed himself in January of 2013. i decided to drop out of my PhD program and become a hacker. the problem was, i knew basically nothing about computer programming or infosec. i was pretty sure i could figure it out, but nobody in the security industry was willing to hire me as an intern with zero practical job experience and no CS degree.

eventually i came to you, a flamboyantly-dressed distant acquaintance who frequented the same SoMA warehouse parties and Noisebridge hackathons as me. i asked you for an internship at the Electronic Frontier Foundation (EFF), where you were working as the Director of Technology Projects; my proposal was that i would maintain the HTTPS Everywhere project for the next 3 months and be paid $5000 in total. you were skeptical but somehow i convinced you to give me a chance, possibly thanks to the fact that you were also a reformed physicist-turned-computer-scientist. that summer, i taught myself javascript and you taught me how to use git blame, the basics of HTTPS encryption, and how to write Firefox extensions as we sat in your office next to a never-ending pot of tea.

the summer flew by; my internship ended and i started contracting as a security auditor for a small startup. months later, you had a job opening for a staff technologist, and i begged you to let me interview for it. to my utter surprise, i got my dream job, and suddenly life became one comic-book battle after another. one of the most memorable days was when i unexpectedly ported most of the Privacy Badger Chrome extension to Firefox in a single modafinil-fueled all-nighter. i will never forget your shock and delight when you walked into work that morning and saw my working demo. shortly after that, i was promoted to senior staff technologist and started getting more recognition in infosec. when i finally left EFF after a bout of unexplained mid-20s depression, you had nothing but best wishes for my future despite valiant attempts to convince me to stay. you were always there for me as my career took off, but i truly wish i had told you back then how much of it you deserved credit for.

in truth, i learned much more from you than i could have imagined during the too-brief decade that we knew each other. you were the first role model i had outside of school. you taught me that you could be weird and look like you just stepped out of a steampunk novel, yet still be taken seriously by your peers. you taught me that being brilliant and engaging in bouts of social hedonism were not mutually exclusive. you taught me that tech job interviews which consist entirely of riddles and logic puzzles are excruciating and should never be done unless you want the interviewee to suffer (i know this because that’s how you interviewed me). you taught me what a negroni and a corpse reviver are, that succulents are the easiest plants to keep in your office, and that if you are never missing flights, it means you are spending too much time at the airport. when i decided to start a weekly podcast, naturally my first guest was you, and thus the podcast was forever doomed; i never did a second episode because you set the bar too high.

in 2015, one of your crazy projects that you had been plotting for years was finally coming to fruition. at the time we were working on HTTPS Everywhere, HTTPS was still the exception rather than the rule, largely because it cost money to get a TLS certificate. you had an impossible vision - what if we partnered with a certificate authority and gave out free certificates that could be auto-deployed and renewed from the command line with zero user interaction? you thought this would change everything and finally get us to near-100% encryption on the web, and you turned out to be spectacularly right. the project that eventually became Let’s Encrypt has issued TLS certificates to 260 million websites as of September 2022, and HTTPS Everywhere is now all-but-deprecated because the vast majority of sites support HTTPS.

as the official release date for Let’s Encrypt drew near, i took a fellowship at EFF for a month to finish writing the nginx plugin for the Let’s Encrypt client. james kasten, you and i submitted a DEF CON talk about Let’s Encrypt, which was rejected, but at the last minute we were able to present it after all because some other speakers couldn’t make it. to our surprise, the room booked for our talk was filled to capacity and a long line of people waiting in line couldn’t even get in! after the success of that talk, the two of us ended up giving a few more together at conferences like Enigma and NginxConf. we always made our slides at the last minute and rarely rehearsed, but you were such a pro at keeping the audience spellbound that all of them went off without a hitch.

on a more personal note, you always could tell when i was sad or if something was wrong. i don’t open up easily to people but you had a way of asking the right questions and making people be honest with themselves. one time we went out for pho near the EFF office and talked about some difficulties we both had growing up. i don’t remember what you said but i do remember feeling less alone at the end and thinking that things would probably get better. you never hesitated to give life advice in a way that was both brazen and deeply empathetic.

all of this was on my mind as i rushed through the hospital last friday night, frantically looking for your room. all of it was still on my mind as the nurse gave us the devastating news that your heart had just stopped beating. i had waited nearly a decade to tell you how much i appreciated you, and now i was a minute too late.

but now that you’ve returned through some miracle of science, i’m so glad to be given a second chance to tell you all this. thanks for everything, peter - i hope the world is every bit as fascinating, absurd, maddening, exquisite, and profound to you as it once was.

til we meet again,

yan

how to be popular

Mon, 02 Aug 2021 00:00:00 UTC

This is a quick blog post about a security vulnerability (now fixed) that allowed me to make anyone like or message a profile on okcupid.com simply by getting them to click a link on my website. In doing so, I used one of the most boring web application security issues (CSRF) combined with a somewhat interesting JSON type confusion.

Proof that it worked on a friend who agreed to help me with security testing and is definitely NOT a rabbit:

A short recap of CSRF

The story, like many, began with me opening devtools and checking if websites were sending CSRF tokens alongside requests that require authentication, like sending messages to another user from your account. CSRF is an attack whereby an attacker sends a link to a victim which, when visited in the victim’s browser, performs some action on behalf of the victim on a site that they are logged into. So for instance, if Bob is logged into Facebook, and Facebook doesn’t have CSRF mitigations on the endpoint that deletes a user’s account, then Alice can trick him into deleting his Facebook account by sending him a hidden link to https://facebook.com/delete (which is not the actual URL that deletes your FB account).

In this case, I noticed that OkCupid messages are sent via POST requests to https://www.okcupid.com/1/apitun/messages/send with a JSON-encoded body like so:

{"receiverid": "123", "body": "sup"}

Conspicuously, there was no CSRF token sent in the request. CSRF tokens are a common way to mitigate these attacks by including an unguessable secret token as an additional HTTP header or POST parameter. The receiving endpoint only allows the request after validating the token; the idea being that while Bob’s authentication cookies are sent automatically by his browser when he clicks on Alice’s malicious link, Alice isn’t able to include a valid CSRF token in the link and therefore the request will fail.

But what about the same-origin policy?

Web developers should be aware that the most fundamental security policy of the web is the same-origin policy: a website on one origin (AKA a scheme + host tuple) running in the browser should not be able to access data on a distinct origin unless the other origin explicitly allows it via a mechanism like Cross-Origin Resource Sharing (CORS). You might be tempted to think that CSRF isn’t possible if your website doesn’t send a CORS header.

The problem is that certain types of requests don’t care about CORS, and the rules for this are not obvious. For instance:

If your site tries to GET a cross-origin image using XHR, it’s blocked by default.
If your site instead loads the image via an img tag instead, it works.
If your site sends a POST to another origin via the fetch API, it’s blocked by default.
If your site instead sends the POST by clicking the submit button on an HTML form element via javascript, it works.

Doing it in practice

So how do we create a webpage which sends a cross-origin POST request to the OkCupid message-sending endpoint? This was attempt #1:

<html>
  <body>
    <form id="form" method="post" action="https://www.okcupid.com/1/apitun/messages/send">
      <input style='display:none' name='foo' value='bar'>
      <input type="submit" value="Click me">
    </form>
    <script>
      window.onload = () => {form.submit()}
    </script>
  </body>
</html>

I visited this on a localhost server and got a very helpful error message after the form was auto-submitted:

Interesting - it’s not complaining that the request is initiated by some random origin, but rather that the POST body (foo=bar) is invalid JSON! Maybe we can fix that with a weird trick:

<html>
  <body>
    <form id="form" method="post" action="https://www.okcupid.com/1/apitun/messages/send">
      <input style='display:none' name='{"foo":"' value='bar"}'>
      <input type="submit" value="Click me">
    </form>
    <script>
      window.onload = () => {form.submit()}
    </script>
  </body>
</html>

My reasoning here was that the browser converts the name and value attributes on HTML input elements into name=value in the POST body that gets sent over the wire; so if name is {"foo":" and value is bar"}, this would become {"foo":"=bar"} which would be JSON-parsed into the bizarre-looking object {foo: '=bar'} without a problem. With a rush of hope unfelt since before the pandemic, I loaded this up in my browser and saw:

… the exact same error. But this time it was because my beautiful POST body had been URL-encoded to become the ugly-but-safe string %7B%22foo%22%3A%22%3Dbar%22%7D. If only there were a way to tell the browser to not encode this form body!

Luckily the W3C deities gave us exactly such a gift in the form (pun intended) of the enctype attribute.

<html>
  <body>
    <form id="form" method="post" enctype="text/plain" action="https://www.okcupid.com/1/apitun/messages/send">
      <input style='display:none' name='{"foo":"' value='bar"}'>
      <input type="submit" value="Click me">
    </form>
    <script>
      window.onload = () => {form.submit()}
    </script>
  </body>
</html>

With the help of enctype="text/plain", the payload is finally sent in its true form (pun intended again) of {"foo":"=bar"}:

Putting it all together, the following HTML will automatically send a message that says “I am a rabbit” to the fake userID 123. (Finding out someone’s real userID is left as an exercise to the reader.)

<html>
  <body>
    <form id="form" method="post" action="https://www.okcupid.com/1/apitun/messages/send" enctype="text/plain">
      <input style='display:none' name='{"foo":"' value='", "receiverid":"123", "body":"i am a rabbit", "source":"desktop_global", "service":"other"}'>
      <input type="submit" value="Click me">
    </form>
    <script>
      window.onload = () => {form.submit()}
    </script>
  </body>
</html>

Note that the POST body becomes {"foo":"=", "receiverid":"123", "body":"i am a rabbit","source":"desktop_global", "service":"other"}. Because the browser inserts a = between the name and value attributes, this gets set to the value of a dummy key, foo, which okcupid fortunately ignores.

I uploaded this HTML to my website, visited the link, and voila:

It works! … Or would work if I had finished my test profile so I could send messages to other users.

Too lazy to do this myself, I sent my CSRF link with my own userID filled in to some friends. Lo and behold, my OkCupid test profile was seranaded by a series of messages that they didn’t mean to send me.

I briefly felt very popular, which made it all worthwhile.

Parting thoughts

Besides making other users unknowingly message your OkCupid profile or someone else’s profile of your choosing, I found you could use essentially the same vulnerability to get other users to “like” your profile. Obviously you could abuse this in order to match with anyone you could trick into clicking a link, or you could spam the link to a bunch of people to increase your profile’s rankings in whatever mysterious algorithm OkCupid uses to suggest people.

It also occurred to me that if I redirected my website to the CSRF link that automatically sent a message to me, I could see the OkCupid profiles of my website visitors who were logged into okcupid.com, which would make for an intense web analytics tool.

The obvious fix is for OkCupid to require a CSRF token for these authenticated endpoint, but my attack also relied on the fact that these endpoints were happy to accept POSTs with content-type: text/plain even though they actually expected JSON. This made me curious if other sites were making the same mistake, so I quickly scraped some of the Alexa top sites looking for requests to endpoints containing api or json.

Once I had a list of a few hundred endpoints, I sent each of them a POST with content-type: text/plain and body {"foo":"bar"}. 87 out of 215 of these endpoints didn’t error, and many appeared to return JSON responses indicating success. Granted most of these are probably not authenticated endpoints and some of them may need to accept non-JSON text, but this suggests to me that developers should be careful accepting text/plain inputs on endpoints that parse JSON.

UPDATE: Multiple folks have kindly pointed out that setting the SameSite cookie attribute in modern browsers to Strict effectively prevents this attack and most other CSRFs. The behavior with SameSite=Lax is somewhat confusing; because submitting an HTML form triggers navigation, initially I assumed cross-origin cookies would be sent in this case. However, with the help of Simon Willison, I found that this is actually not the case if Lax is explicitly set. But here’s the surprise: if a SameSite attribute is NOT explicitly set, then Chrome will send the cross-origin cookie in POST requests that occur within 2 minutes of when the cookie was set, even though Lax is now the default in Chrome!

Disclosure timeline

This was reported to OkCupid in April 2021. According to their team, it was fixed without delay which prevented exploitation of the bug. I would like to thank their security team for the bounty and permission to share this blog post.

building an e-bike

Sun, 07 Mar 2021 00:00:00 UTC

about a year ago, i moved to a hillier neighborhood in San Francisco. my beat-up vintage road bike, a beloved and steadfast companion on thousands of commutes across SoMA, suddenly became way less practical and more importantly, way less fun. as months of quarantine dragged on, i started either taking Lyft rental e-bikes out of sheer laziness or just staying in flat regions (a technique i call elevation evasion). eventually i became so disappointed in my self-imposed lack of transportation autonomy that i decided to take action.

become a more competent cyclist? no.

put an motor on my bicycle?? YES.

why?

i first looked into buying an entire e-bike online in case this was somehow cheaper than doing an e-bike conversion. unfortunately most recommended affordable e-bikes were beyond my 3-figure budget, not to mention sold out due to their increased popularity during shelter-in-place.

e-bike conversion kits, on the other hand, cost as little as $240. this seemed like a steal until i realized that they didn’t come with a battery. e-bike batteries often cost more than the rest of the conversion kit combined, putting the true cost of a conversion at closer to $500.

around this time, i saw a well-targeted search ad for Swytch, “the world’s smallest and lightest eBike kit” according to their IndieGoGo. drawn in by their startuppy marketing materials and seemingly-perpetual 50% discount, i joined the waitlist for their next batch of kits. by the time pre-orders opened, i was convinced it was worth $499.

after months of waiting, not to mention $50 in shipping and $27 in import duties, my Swytch kit finally arrived in the mail a few weeks ago, far closer to the expected date than i had any right to expect from a crowdfunded project.

if at first you don’t succeed, move the goalposts

with great anticipation i unboxed the kit, consisting of a motorized replacement front wheel, a battery pack with charger, a handlebar mount for the battery, a pedal assist sensor, and an intimidating number of zipties. after skimming the manual (well-organized with lots of color pictures) and transferring my old tube and tire onto the new wheel, i started the first step of installing the Swytch wheel.

i ran into trouble immediately, since the axle turned out to be too wide for my fork.

Swytch support got back to me within hours and recommended filing off a bit of the axle using a metal file. as i was waiting for the file to arrive from Amazon, i started to worry that the weight of the Swytch wheel and battery would put too much strain on my weakened bike frame (the result of a bike theft attempt that left a bad dent in the down tube). on top of that, my bike was in need of new brake pads and a new chain.

i decided that given all these problems, i should just build a new bike starting from the salvageable parts of my existing bike. i have never built a bike from parts before and was excited to learn. however, after doing my Craigslist homework, i couldn’t find a complete set of decent bike parts that cost less than $200, so i gave up and bought a $220 single-speed.

putting it all together

my brand-new Retrospec Harper arrived a few days later mostly assembled. i just had to attach the handlebars and seat, screw in the pedals, and adjust the brakes. and then to convert it into an e-bike:

instead of the included front wheel, pop the Swytch wheel into the front fork and tighten both sides. it should fit perfectly, but you will need to adjust the height and angle of the brake pads.
attach the pedal assist system, which consists of two pieces: a ring with an arm that attaches to the crank, and a small sensor which goes on the bottom tube. you need to adjust the angle and placement of these pieces until they’re almost touching at their closest point (magnetic fields ftw) but not rubbing against each other.
attach the battery holder to your handlebars
pop the battery into the battery holder, but make sure you activate it following the instructions in the manual and charge it first.
connect the wire from the pedal sensor to your battery. note that the battery will have some unused connectors if you bought the kit without upgrades, as shown below.
connect the wire from the wheel motor to your battery. use your remaining zipties for cable management.

that’s it! the set up was surprisingly easy for a bike n00b like me, but even more surprising was how smooth and utterly fun the ride was. i was able to coast up an 11% grade street near my house without any difficulty, and biking through Golden Gate Park felt like surfing on butter. although it wasn’t cheap, the end product feels much more expensive than $750.

the one major downside is that i wouldn’t recommend locking this bike up for more than a minute in the city, given how easy it is to steal the pedal sensor. but all in all, it’s worth it for the ability to conquer the hills of SF without breaking a sweat.

lazy quarantine bagels

Sun, 10 May 2020 00:00:00 UTC

prologue: on laziness

lately i have been doing some lazy baking whilst in quarantine, where lazy is defined as:

no need for fancy equipment like stand mixers with dough hooks
no need for hard-to-find ingredients like lye
NO STARTERS (like the kind you need for making sourdough)
less than one hour of work total
can be made by someone with minimal baking experience
can skip/improvise/fuckup 1-2 steps and still have a decent result

for a prime example of lazy baking, check out my twitter recipe thread about japanese-style croissants (AKA salted butter rolls), which have been made by dozens of people (including children) to near-universal acclaim.

why is it not common knowledge that u can make perfect japanese-style croissants from scratch with like 20min of effort?? thx @MimeeXu for enlightening me

(recipe in thread👇) pic.twitter.com/XD9hWqFXs9
— yan (@bcrypt) April 9, 2020

non-lazy bagels

when lazy croissants became overly undemanding of my copious leisure time (jk), i decided to move on to bagels with some encouragement from baking master and sourdough-starter-haver garrett. these bagels were incredible, but required having a sourdough starter and clearing an empty fridge shelf to put the bagels in overnight, hence disqualifying them from my laziness requirement.

.@garrettr_ AND I MADE SOURDOUGH BAGELS FROM NOTHINGNESS pic.twitter.com/3gLCsMtESo
— yan (@bcrypt) May 4, 2020

having said that, if you have access to a sourdough starter, you should probably just stop reading here and go make this sourdough bagel recipe instead.

lazy bagels

my goal was to make a lazy bagel that was 90% as good as the average nyc bagel. it had to be soft and pillowy, yet able to withstand a cream-cheese loaded butter knife without getting crushed, with a chewy exterior and a nice yeasty flavor that would make keto people hate me.

i think i achieved this - or at least what is probably the best bagel i’ve had outside of the east coast - by making a few modifications to a tried-and-true recipe from Sally’s Baking Addiction. so far i’ve made two batches of my favorite bagel flavor, parmesan-onion-garlic, one with parmesan inside the dough and one without. both have turned out sufficiently spectacular that i am taking the time to write this down for posterity even though my blog auto-deploy scripts are broken.

equipment

enough baking sheets to fit 8 large bagels without crowding them
parchment paper or silicone baking mats
a pot that holds at least 2qts
[optional] pastry brush
thermometer

ingredients

500g (4c) all-purpose or bread flour
8g (2.75tsp) yeast
butter or oil spray for coating
12g (2tsp) salt
1/4c + 1tbsp maple syrup, brown sugar, or honey
at least 1/4c of baking powder
[optional] egg
[optional] 1/2c of shredded parmesan for mixing into the dough
whatever toppings you want on your bagels. (i used shredded parmesan, a small diced onion, coarse salt, and 2 cloves of minced garlic)

day 1 instructions

do these the night before you want to eat bagels

making alkalized baking soda

the purpose of this step is to increase the potency of commercial baking soda so that you can use it in place of lye to boil bagels.

preheat an oven to 275F
line a baking sheet with aluminum foil
pour a bunch of baking soda (at least 1/4c, do more if you want to save some for next time) onto the foil in a layer
bake the baking soda for an hour; then store it in a sealed jar or ziplock bag

be careful when handling the baking soda after baking as it is strong enough to cause skin irritation.

making the dough

pour 1.5 cups of water into a small bowl & microwave for ~40s until it reaches 100-110F (38-43C)
sprinkle 8g yeast into the water and whisk it around until it dissolves. add 1 tbsp maple syrup (or brown sugar, or honey) into the yeast water and stir to combine.
measure 500g flour and 12g salt into a very large bowl. if you want a cheesy dough, add 1/2 cup of shredded parmesan. mix it all up.
pour the wet mixture into the flour mixture and mix it up evenly with your hands.
dust some flour onto a work surface (like a counter or chopping board), then pour your dough onto the surface
knead the dough for about 10min, sprinkling more flour onto the dough if it is sticking to your hands or the surface. i like to fold the dough onto itself, press down hard to flatten it, fold, press, repeat. at the end of this process, you should have a stiff ball of dough that barely sticks:
grease or oil spray the bowl that your dough was in. put your dough ball back into the bowl and flip it around to coat in oil/butter. cover it (i like to use plastic wrap with a towel on top) and let it sit out for 60-90min. at the end it should look puffier like this:
put your bowl of covered dough in the fridge to rest overnight

day 2 instructions

your dough should have risen a bunch in the fridge and may now look ugly like this:

split your dough into 8 roughly-equal balls
taking one ball of dough at a time, flatten the ball into a disk, then roll it up into a long log shape. put 3 fingers on top of the log, then wrap the dough around your fingers so about 2 inches overlap. then roll the dough seam so that it looks like a continuous ring of dough as shown below.
place the shaped dough onto baking sheets lined with silicone mats or parchment paper. cover again and let rise at room temperature for up to an hour.
in the meantime, preheat the oven to 425F. prep your bagel toppings and egg wash. to make egg wash (optional but recommended), whisk together 1 egg yolk and a splash of milk/cream/water.
in a large pot, bring 2 quarts of water to a boil. add 2 tbsp of the alkalized baking powder and 1/4 cup of maple syrup (or honey, or brown sugar).
carefully drop in 2-4 bagels at a time. they should float to the top of the water. let them boil for 30s to 1m on one side until a fried-looking layer forms, then flip them over and repeat for the other side.
when you have boiled the bagels on both sides, carefully remove them from the water with a slotted spoon and place on a plate. brush them with egg wash if using.
top generously with toppings
place the bagels back on the lined baking sheets and bake for 20min or until they turn golden brown.

here’s my first batch without parmesan in the dough, on the slightly less-cooked end at ~19min (how i prefer bagels):

and here’s bagels at ~21min, which is how most people seem to prefer bagels:

the next day, they were still really soft with a nice density and bite:

for comparison, here’s a fresh-from-the-oven picture from my 2nd batch which used bread flour instead of AP and had parmesan mixed into the dough. the dough was a lot stickier / harder to work with due to the cheese (hence some of the uglier photos above), and the end result might be considered not-a-proper-bagel by bagel snobs. however i guarantee it is still tastier than almost any bagel you can find on the west coast.

happy experimenting!

Writing Custom Control Surfaces for Ableton

Thu, 07 Nov 2019 00:00:00 UTC

Recently I’ve been really interested in what goes on in Ableton Live under the hood, since it’s a widely-used piece of proprietary software for making bangers. It turns out you can get pretty far knowing just a small amount of Python scripting!

For instance, I found that .als files (and .adv’s, and .adg’s, and probably more) are just gzipped XML and so therefore you can do some fun processing on them using any XML library, such as Python’s. So, remembering the week that it took me to convert all my Ableton DJ sets into Rekordbox, I wrote a script to automatically convert Ableton cues to Rekordbox and vice-versa. This could have definitely saved me about 10 hours of boring work time that could have been spent making bangers instead!

This week, I started looking into Ableton’s Python interface for control surfaces and you’ll never guess what happened next (a bunch of boring stuff).

What’s a control surface?

According to Ableton, “Control Surfaces are specially written scripts which allow controllers to interface with Live”.

Most people who use Ableton interact with it through a tactile controller, such as a MIDI keyboard or an Ableton Push or the APC40 controller. Control surfaces are scripts which act as a bridge between Ableton and the controller, telling Ableton what each button/knob/fader/etc. on the controller should do.

It turns out that these control surfaces are simply Python scripts.

Where does Ableton store its control surface scripts?

Ableton comes with a bunch of control surface scripts pre-installed for common controllers such as the Launchkey, Push, and APCs. For these controllers, you can just plug in the controller, open Ableton Preferences, and select the control surface for it via a drop-down list in the Link/MIDI tab.

These scripts are stored in /Applications/Ableton Live $VERSION.app/Contents/App Resources/MIDI Remote Scripts/ on Mac (where $VERSION is 10 Suite for instance if you have Live 10 Suite installed) and \ProgramData\Ableton\Live x.x\Resources\MIDI Remote Scripts\ on Windows.

For the rest of this post we will refer to this as the MIDI Remote Scripts directory.

Loading a custom control surface script

If you want to load your own custom control surface script for an existing MIDI controller, the steps are fairly straightforward:

Find the existing control surface for the MIDI controller in the MIDI Remote Scripts directory. For instance, for the APC40, this would be in APC40/ as a bunch of .pyc files. You can either decompile the .pyc yourself or find the decompiled version in https://github.com/gluon/AbletonLive10.1_MIDIRemoteScripts.
Copy these decompiled Python files to a new directory in the MIDI Remote Scripts directory.
Customize them (more on this in the next section).
Now open Ableton and go to the Link/MIDI tab of Preferences. Ableton should automatically compile the .py files to .pyc. If everything loaded without errors, you will see your new MIDI Remote Scripts directory show up as an option in the Control Surface dropdown.

Customizing control surfaces

In the MIDI Remote Scripts directory, there’s various directories that start with _. These are libraries which other control surfaces can make use of. One particularly useful one is _Framework, which includes definitions for useful classes like ButtonElement, which represents a button on the controller.

The best intro I’ve found to _Framework is this one by Hanz Petrov: https://livecontrol.q3f.org/ableton-liveapi/articles/introduction-to-the-framework-classes/.

Let’s say we want to take the Metronome button on an APC40MKII and instead map that to turn on looping for the currently active clip. Assume we’ve already created a ControlSurface subclass as a starting point.

As a shortcut to calling ButtonElement directly, note that there is an _APC library already which provides a make_button utility method for APC controllers. Github link here.
make_button takes an identifier as input. To figure out what we need to pass here for the metronome button, we can look at the APC control protocol documentation which conveniently lists identifiers for all the buttons on the APC40MKII. We see that 0x5a, or 90, is the identifier for the metronome button.
Now we have to add a listener to the button using the add_value_listener method of ButtonElement that triggers when the button is pressed. Let’s call this handler start_loop.
In start_loop, we can call the song() method of the ControlSurface superclass in order to get a reference to the Live.Song.Song object that we are currently controlling. For documentation on this and other Live objects that are available in Python, see here.
song().view.highlighted_clip_slot.clip now gives us the active clip. This is a Live.Clip.Clip object according to the docs above. So we can simply set clip.looping to a truthy value like 1 to make the clip loop!

In reality, I’ve found the best way to figure these things out is to simply copy/paste code from other control surface scripts as needed. In particular, Will Marshall’s unsupported Ableton 8 control surface scripts are really helpful. Also the unofficial Live Python API documentation is crucial.

Debugging tips

You can log to Ableton’s main log file using the ControlSurface log_message method defined here. On Mac, the log file is at /Users/[username]/Library/Preferences/Ableton/Live x.x.x/Log.txt and on Windows it’s \Users\[username]\AppData\Roaming\Ableton\Live x.x.x\Preferences\Log.txt. This file also contains errors emitted by Python.
You can also reload the MIDI control surface without restarting Ableton: simply re-open the currently open session from File > Open Recent Set.
If you find that Ableton doesn’t auto-compile Python, you can compile using python -m compileall .
As mentioned previously, if a script throws an error immediately, it won’t show up in Ableton’s list of available control surfaces.

Example

As an example, see this Youtube video and Github repo for adding CDJ-style looping buttons to the APC40MK2. The work for this was done originally for Ableton 8 by Will Marshall and I only made some minor edits to make it more CDJ-like and loadable in Live 10.

Note that you can accomplish much of this already without control surface scripts simply by using Ableton’s MIDI mapping mode. One exception is the ability to halve and double loop lengths.

I hope this helps to show that control surface scripts are a quite powerful and flexible way to get your Ableton controller to behave exactly the way you want. Happy hacking!

the information apocalypse

Mon, 19 Feb 2018 00:00:00 UTC

My friend Aviv was recently the subject of a popular Buzzfeed article about the possibility of an impending “information apocalypse”. tl;dr: Aviv extrapolates from the fake news crisis that started in 2016 to a world in which anyone can create AI-assisted misinformation campaigns indistinguishable from reality to the average observer. From there, a series of possible dystopian scenarios arise, including:

“Diplomacy manipulation,” in which someone uses deepfakes-style video manipulation tools to produce a realistic video of a political leader declaring war, in order to provoke their enemy into retaliation.
“Polity simulation,” where Congresspeople’s inboxes are spammed with messages from bots pretending to be their constituents.
“Laser phishing,” which improves the sophistication of phishing attacks by training phishing email generators on messages from your real friends, so you’re more likely to read them and fall for them.

With regards to how this would affect our everyday lives, Aviv postulates that exposure to a constant barrage of misinformation may lead to “reality apathy”; that is, people will start to assume that any information presented to them is untrustworthy and give up on finding the truth. In such a world, Aviv says, “People stop paying attention to news and that fundamental level of informedness required for functional democracy becomes unstable.”

The rest of this post consists of my half-formed thoughts on the possibility of reality apathy as it relates to existing technology, largely informed by my perspective working in the computer security industry.

Let’s start with the Internet of the late 90s and early 2000s. Back then, long before the 2016 fake news crisis, it was already possible to bombard everyone on the Internet with well-crafted, believable misinformation. All you had to do was create a legitimate-looking website with a legitimate-looking domain name and then spread the link via chain emails. Case in point: the first website that ever traumatized me as a kid was something called Bonsai Kitten. Complete with realistic-looking photos of cute kittens contorted into various jars and vases, this website completely fooled the 5th-grade me into believing that some unimaginably cruel person was raising and selling mutilated kittens. Apparently I wasn’t the only one - the site drew hundreds of complaints a day from concerned animal-lovers and was the subject of an FBI investigation according to Wikipedia. Eventually Bonsai Kitten was debunked, and I’m now friends with the creator of the site that once haunted my nightmares.

Another example of misinformation that people online have been exposed to since the dawn of the Internet is email-based phishing and spam. However, nowadays it is relatively difficult to create a successful bulk phishing/spam campaign, largely thanks to Google’s improvements in spam filtering and Gmail’s ever-increasing centralization of email. As Mike Hearn describes in great detail on the messaging@moderncrypto.org mailing list, Google eventually “won” the spam war by building a reputation system in which sender reputations could be calculated faster than the attacker could game the system. Notably, this solution relied on both Gmail’s ability to scan an incredibly large volume of plaintext email and their ability to broadly distinguish between legitimate Gmail users and bots trying to do Sybil attacks on the reputation scoring system.

How does this change in a world where phishing emails are generated by really smart AIs? We might imagine that the content of these emails would do a much better job at fooling both humans clicking the spam/not-spam labels and Gmail’s filter algorithms into thinking that they aren’t spam. However, the spammer would still have to figure out a way of obtaining non-blacklisted sender IP addresses, which can be done by signing up for a bunch of accounts with a webmail service like Gmail (which Gmail tries to prevent, as Mike Hearn notes) or by taking over someone else’s account and spamming their contacts.

The latter case may seem intractable. If a bot hacks my Gmail account, uses my sent mail to train itself to generate emails that sound exactly like me, and emails my friends asking them to send money to the hacker’s Bitcoin address, Gmail’s spam filters are going to have a hard time figuring out that those were not legitimate emails from me. On the other hand, I could have prevented this from happening had I done a better job of securing my email account. For these reasons, I consider email-based misinformation to be mostly a solved problem as long as Gmail’s anti-spam team keeps doing their job, Google still controls the vast majority of email (ugh), and users can keep their accounts secured.

What about phishing websites, then? There are some incomplete defenses against those:

Google SafeBrowsing is a service integrated into Chrome and other browsers that contains a dynamic blacklist of “bad” domains, such as phishing sites and sites distributing known malware. Browsers that enable SafeBrowsing will show a warning before allowing a user to view a site on the SafeBrowsing blacklist.
High-profile legitimate websites such as banks will often buy Extended Validation TLS certificates, which require their organization to be validated by the issuing certificate authority. In exchange, browsers show a green bar in the URL bar next to the lock icon, usually containing the name of the organization and the country code. However, it’s relatively easy to game the validation process, and it’s unclear how well this actually protects average users from real-life phishing attacks.

On the other hand, the problem of determining whether a website is presenting a distorted version of reality has some important differences from the problem of determining whether a website is phishing/malware. For one, many people who have no problems accepting Google’s decision on whether a website is distributing ransomware binaries would not be happy if Google were the sole arbiter of whether news stories were true or not. The occasionally-made argument that SafeBrowsing is a form of censorship would apply much more cleanly if SafeBrowsing (or a similar megacorp-controlled service) also blacklisted sites that were ruled to be “fake news”.

So how do we protect people from believing fake news in a world where anyone can generate realistic-looking videos, images, and stories?

One idea I had brought up with Aviv was that web browsers or content platforms like Facebook and YouTube could show a special UI indicator for media and stories from reputable news sites, similar to how browsers show a green bar for EV certificates and how Twitter/Facebook show a check mark next to verified account names. For instance, videos that are approved as legitimate by the Associated Press could be signed by a cryptographic key controlled by AP that is preloaded into browsers. Then when the video is playing in someone’s Facebook news feed, the browser’s trusted UI (for instance somewhere in the URL bar) would display a popup informing the user that the video has been approved by AP. This would however not prevent attacks where a Facebook user makes up a fake caption (“Trump declares war on Hawaii”) for a real image (an old photo of Trump speaking).

(Browsers and news reader apps could even add an optional “trusted news mode” where they only display media files that have been cryptographically signed by a reputable journalist organization. Unfortunately this would also block content from “citizen journalists” such as people livetweeting photos from a protest.)

To end on a more pessimistic note, I fear that we ultimately can’t stop misinformation campaigns from becoming rampant and normalized, not because of purely technological reasons but because of psychological ones. During and in the wake of the 2016 Presidential Election, a lot of the shares, likes, and retweets that I saw boiled down to people on both sides trying as hard as they could to reinforce their existing beliefs. Social media, it turns out, is an excellent tool for propagating “evidence” of what you believe, regardless of whether the evidence is real or not.

Fake news that is unpalatable (ex: Bonsai Kitten) stops spreading once it’s been debunked, but fake news that is crafted to be consistent with your desired reality can keep getting views, shares, and clicks. Instead of reality apathy, we end up with pick-your-own-reality filter bubbles, in which people gather and amplify fake evidence for the reality that best suppports their underlying narrative. Instead of “giving up” on consuming information, people cherry-pick their information consumption based on feelings instead of fact, turning more and more online spaces into breeding grounds for extremism.

And so, maybe the majority of people wouldn’t even want SafeBrowsing-style blacklists of fake news sites or verification badges on legitimate journalist-vetted news articles, because they’re not reading the news to learn the truth - they’re reading the news to validate and spread their existing worldviews.

Effectively this means that any technological solution to the information apocalypse depends on a social/behavioral solution: people need to welcome cognitive dissonance into their online spaces instead of shunning it. But it sounds almost ridiculous to suggest that shares/likes/retweets should be based on factual accuracy, not emotions. That’s not how social media works.

a post-truth thought experiment

Mon, 23 Jan 2017 00:00:00 UTC

1. A perfect game-theoretic analysis machine

Imagine that you had a magic machine. You tell the machine what your goals are. The machine tells you, in any situation, the optimal statement to say in order to achieve your goals, and who to say it to. The statement may or may not be true.

Under which circumstances, if any, would you follow the machine’s instructions?

Example 1: Bob tells the machine that his goal is to become as rich as possible. The machine instructs Bob to publish a “fake news” article about how climate change is an illuminati conspiracy theory.

Example 2: Alice tells the machine that her goal is to cure cancer. The machine instructs her to tell the local florist that her favorite color is red when in reality it is blue.

Instinctively, most truth-loving people would consider Bob to be immoral for following his instructions; however, we would probably not say the same of Alice. Many of us would even admit that in Alice’s situation we would follow the machine’s instructions. This suggests that, for many people, there exists a class of situations in which cost/benefit analysis favors lying.

2. Anecdata

Because the plural of “anecdote” is “anecdata,” I asked an abbreviated form of this question on Twitter. Most people said they would not lie because of one of the following reasons:

Lying causes them to have negative feelings, like guilt and stress.
The reputational risk caused by lying is too great. (Although you could solve this by telling the machine that your goal is to achieve X while never getting caught lying.)
The truth is more aesthetically pleasing.
Inertia; telling the truth is their default behavior, and they see no compelling incentive to change.
Honesty is a way of showing respect and consideration for oneself and others. As an example, if one believes that information asymmetry leads to power imbalance, then the more powerful person in a relationship can help the less powerful by disclosing truthful information. (Added on 1/23/17 thanks to input from Noah and Nadim.)

3. What is truth?

Before criticizing “alternative facts” and post-truth politics, we should examine what truth means to us and why we love it so much in the first place.

In my mind, a conservative definition of “telling the truth” is “saying things that are consistent with our observations.” For instance, if a helicopter pilot sees around 400,000 people at the inauguration, it would be truthful for them to say there were 300,000-500,000 people at the inauguration, but it would be a lie to claim there was only 1 person.

A less-conservative definition might be, “saying things that are consistent with what we believe.” For instance, I may not have directly observed the moon landing, but I could honestly tell someone that humans have landed on the moon because I believe it happened based on the numerous credible (to me) scientists and history books that say so. In fact, the scientific community has established standards for what counts as “credible,” based on peer review and the reproducibility of results.

The problem is, other communities’ standards for credibility are far less stringent and well-defined. For instance, you might judge Donald Trump’s press secretary’s media briefings to be a credible source of facts. By the less-conservative definition, you are then “telling the truth” when you claim to your friends that more people attended his inauguration than any other in history.

Since the conservative definition is too limited for useful discussion, I will henceforth define truth as the set of statements that are believable according to some standard of credibility. To lie is to assert that a statement that is outside this set is in this set, either intentionally or non-intentionally. Note that if two communities have differing standards of credibility, a statement that is a truth to one community may be a falsehood to the other.

4. Are we biased toward a particular kind of truth?

Yes; I think a lot of us, especially scientists and engineers, are biased towards telling the truth as determined by scientific standards of credibility. I use the word “bias” because we do not usually justify why telling the truth is preferable to lying, or why our standards of credibility are the right ones. We may allude to vague notions such as “lies hurt people,” which we’ve heard over and over since childhood, or we may assert that science is good, but we fall short of an argument meeting the rigor that we typically demand from people with opposing viewpoints. It seems ironic for scientists and rationalists to critique others’ conceptions of (post-)truth while quietly treating the correctness of our own as a foregone conclusion.

Anyway, here are a few reasons to justify my conception of truth and why I don’t usually lie:

I don’t personally care about the pursuit and propagation of (my definition of) truth as a goal in itself; however, it has historically been an effective means of accomplishing goals that I do care about, such as improving the average quality of life for all humans. Thanks to centuries of people defining truth as ’that which can be tested using the scientific method’, we have stuff like penicillin and airplanes.
The discovery of a lie is likely to cause suffering, in part due to current societal norms and assumptions about lying (ex: the belief that if someone loves you, they wouldn’t lie to you). As someone whose goal is to minimize suffering, I therefore try not to knowingly lie or make statements that could turn out to not be true. Of course, it’s possible that telling the truth will ultimately cause more suffering in some indirect way, but I usually do not have enough information to determine when this is the case.
In certain circumstances, behavioral economics research has shown that telling the truth leads to a better state for people overall than when some or all parties are lying.

Admittedly, the first reason is the most compelling for me. Extrapolating from this utilitarian standpoint implies that if I had a machine that told me which lies to tell (or which standards of credibility to use) so that I could start a movement that ultimately improved billions of lives, I would tell those lies.

This is an uncomfortable thought because my love for scientific truth is as deep as it is irrational. After all, if you take a birds’ eye view at the history of human civilization, science is just a meme that has gone viral in the last several centuries or so. Maybe a new meme will appear soon.

5. Dealing with the post-truth world

The machine in Part 1 is not a purely hypothetical construct. Increasingly, over the last election cycle and the first few days of the Trump presidency, it has become apparent to me that some people believe that they have version 0.0000001 of this machine, and they are willing to follow its instructions without regard for scientific truth. In horror, we (the pre-post-truth people) stifle screams at the crumbling foundations of rational discourse, and then we scroll down to the next tweet. Thanks to infinite scroll, the horror is literally unending.

Few people seem to be asking, is it right to fabricate falsehoods for one’s own causes if the other side has been doing the same? The mainstream answer is no, either because lying is seen as inherently immoral or because of the long-term reputation cost. The latter can be addressed by spreading the lies from sources that already have ~zero reputation; moreover, it is no longer a problem once people agree that lying is chill and/or lying becomes so commonplace that it’s expected of news sites and social media posts.

How effective is honesty at achieving your goals, and at what point do you decide that lying is a more effective means to an end? I want to say “never” for the second question, but I can clearly imagine a world in which it is the wrong answer.

surveillance, whistleblowing, and security engineering

Wed, 05 Oct 2016 00:00:00 UTC

[Update (12/14/16): Reuters has specified that the rootkit was implemented as a Linux kernel module. Wow.]

Yesterday morning, Reuters dropped a news story revealing that Yahoo installed a backdoor on their own infrastructure in 2015 in compliance with a secret order from either the FBI or the NSA. While we all know that the US government routinely asks tech companies for surveillance help, a couple aspects of the Yahoo story stand out:

The backdoor was installed in such a way that it was intercepting and querying all Yahoo Mail users’ emails, not just emails of investigation targets.
The program was implemented so carelessly that it could have allowed hackers to read all incoming Yahoo mail. Of course this also means FBI/NSA could have been reading all incoming Yahoo mail.
Yahoo execs deliberately bypassed review from the security team when installing the backdoor. In fact, when members of the security team found it within weeks of its installation, they immediately assumed it had been installed by malicious hackers, rather than Yahoo’s own mail team. (This says something about what the backdoor code may have looked like.)
Yahoo apparently made no effort to challenge this overly-broad surveillance order which needlessly put hundreds of millions of users at risk.

At the time this was happening, I was on the Yahoo Security team leading development on the End-to-End project. According to the Reuters report, the mail backdoor was installed at almost the exact same time that Alex Stamos and I announced the open-source launch of a Chrome extension for easy-to-use end-to-end encryption in Yahoo Mail at SXSW 2015. Ironically, if only we had been able to actually ship E2E, we would have given users a way to protect themselves from the exact backdoor scenario that they ended up in!

Imagine for a moment that you are a security engineer who discovers a backdoor that your company execs have been trying to hide from your team. Would you quit on ethical grounds or stay so that you can prevent this from happening again? I don’t think there is one right answer. Personally I am grateful both for those who left and blew the whistle, and for those who stayed to protect Yahoo’s 800 million users.

Part of the job function of security engineers and pen testers is being ready for the moment you encounter something that you think should be disclosed but your company wants to keep secret. Think about what you would be willing to lose. Be prepared to escalate internally. Know the terms of your NDA and your exit agreement; try your best to honor them. Most of all, keep pushing for end-to-end encryption.

bus diaries

Mon, 27 Jun 2016 00:00:00 UTC

While migrating my blog from WordPress to Hugo + GitHub Pages, I found two old diary entries from last autumn, a period of life when I rode buses a lot. They are copied below.

oct 28, 2015

they told me not to, so i’m taking the bus from downtown LA to LAX. on my right, a man is asking everyone except me for 50 cents. everyone except me is a black guy.

the bus stops for the zillionth time and a high schooler in a white t-shirt with some arm tattoos gets on. he sits down to my left and asks me what my arm tattoo is of. i start explaining particle physics. he asks what the hell i’m doing on the bus in LA. “hanging out,” i shrug. he thinks i am 19 years old and smart and beautiful and cool so he asks me out. i say sorry i live in san francisco, i am on my way to the airport, and just for the record, i am 24 years old. the guy next to him hears this and high-fives me because he used to live in oakland. the kid asks me if i could please change my flight so we can chill. i say no. then he says, “you are the dopest girl i’ve ever met. imma get off the bus and call my friend and tell him ‘bout you.” i say thanks. he remembers i’m not from south LA so he tells me it’s a real bad neighborhood and i should not talk to anyone if i get off the bus here. i say thank you, that information may be relevant to my immediate perambulations. the kid is obviously a bit sad we can’t hang out, so we say our goodbyes as he is getting off the bus to go to his friend’s house. i tell him he is young and i’m sure he will meet lots more people on the bus in the future.

the guy from Oakland starts to play rap music at full volume on his phone. the man on my right leans over to him and whispers, “50 Cent?” i tell him, no sir, i believe this track is by Biggie. “that’s right,” he nods, as the guy from Oakland hands him 50 cents.

nov 11, 2015

assuming you don’t have actual sleeping pills, the trick is to drink way too much alcohol the night before and then eat enough pasta in the morning before getting on the bus that you pass out as soon as you hit the highway. pasta is basically a date rape food, in case you somehow haven’t noticed. when you get on the bus, it’ll probably be half full of lonely-looking people with deep lines of weariness creased in their drooping faces. they shuffle onto the bus, reluctantly set their things in the adjacent seats, plug in their earbuds, and let their eyelids float down slowly like gentle sea creatures. the bus takes you from boston to new york city for just $14 and it only explodes catastrophically sometimes.

before i pass out, i stare out the window at chunks of highway blurring by. it’s so fucking ugly here, you have no idea. the sky is the color of dirty dishwater. the sky pisses cold rain indiscriminately onto decrepit warehouses and rusty gas stations and weather-chipped rest stop signs creaking out their last desperate cries of dreary pretend-hospitality. it’s 3 in the afternoon and getting dark, which is such bullshit. really, nothing quite compares to the desolate feeling of sitting on a $14 bus surrounded by sad sleepy strangers while the feeble daylight dissolves into lonely darkness on a rainy afternoon in the middle-of-nowhere, connecticut (?). everyone obviously knows that the grip of winter is clenching tighter around their battered shoulders with every passing day now but nobody wants to talk about it. nobody wants to talk at all.

i hate it here. i miss it too. california turns everyone into sun-drenched polyester-clad ingrates, drunk on their own invincibility against the gentlest of elements. self-sufficiency is cheap in kind climates; rarely do you crave friendly company to pass the endless hours of icy drizzly darkness, nor do you exchange parsimoniously-heartfelt smiles of shared hardship with your neighbor while numbly stabbing your shovels into the frozen sidewalk. but when you wake up in the middle of the night to reach for a warm comforting hand that isn’t there, at least you’re not shivering.

i probably should have had more pasta.

xychelsea part 2

Thu, 26 May 2016 00:00:00 UTC

The second and last time that I visit Chelsea Manning, we speak and move with a sense of urgency, as if a natural disaster is imminent. By now, the Ft Leavenworth prison visit procedure feels strangely familiar, like a movie you once watched in a dream. I check in with the uniformed officer at the Disciplinary Barracks’ front desk, wait uselessly while he misgenders Chelsea and figures out if I’m allowed to visit her, rent a locker to stow my jacket which is prohibited in the visit room (due to the having of zippers), don an unsuspicious smile when the guard tries to deny something i’m bringing (this time, it’s blank drawing paper and pencils – both of which are eventually let through), pass through the metal detector and double-doored atrium, wait for the guard to let Chelsea through the opposite doors, hug briefly, sit down at her favorite table against the wall, buy her snacks from the vending machines twice (first course: Dr. Pepper and Sour Cream and Onion chips; second course: Pepsi and Doritos), watch the other inmates playing cards with their families, make jokes, laugh, cry, talk about computers and pretend we’re just normal friends doing friend-things, except we are forced to return to two separate worlds when the clock strikes 21:30.

She tells me straight up that she was misty-eyed last night after my first visit and knows she’ll be bummed out for the next couple days after I leave. Trying to dispel the palpable gloom, I assure her that I’ll visit again, though I can’t promise when. It doesn’t really work. The sadness is still there, swirling in the small grey room, so thick I can almost choke on it. Fortunately, we are both highly adept at changing the subject and pretending that everything is fine.

I hand her a near-illegible list of questions for her from strangers on Twitter, which I had hurriedly compiled during the drive in. She brightens and grins, scrawling answers in the empty spaces as if it were a high school math exam.

Q: Who do you support for president?

A: [after pausing for a minute, explaining that she isn’t allowed to comment on this question.] I don’t like partisanship. [we chat about pitfalls of the two-party system.]

Q: Read any Kafka?

A: yes!

Q: Okies say hi!

A: hi!

Q: What do you hope people are doing [in response to your actions]?

A: think for yourselves

Q: Are you comforted by [the knowledge of your] patriotism?

A: USA!

Q: What [do you do] to keep faith?

A: pi

Q: What is the most interesting/exciting thing you’ve learned [in prison]?

A: how to live collectively

Then she picks up another sheet of paper and mischievously says, “I should write some questions for Twitter in return.”

We spend a while chatting about small lighthearted things, like lip gloss quality (a subject on which her opinion is far more sophisticated than mine) and whether the red-orange powder on Doritos actually has any flavor (we agree the answer is no). Then abruptly we start to talk about hope, about her 35-year sentence, about the act of hanging on for as long as you can. Her eyes start to fill with tears.

I tell her about all the people on the internet who care about her, all these people who she can’t see or talk to.

Then I start to cry too.

How many visitors do you have? I ask.

Five, she says.

We count them. There’s only four, including me. One of them has never actually visited. She doesn’t know when her next visitor will be.

Only friends and family who knew her pre-confinement are allowed. But that must be dozens if not hundreds of people, I think angrily to myself. Flights to Kansas City aren’t always cheap, but surely we could start a donation fund. My mind starts spinning, madly grasping for schemes to increase her visitor count. Sure, Leavenworth is a quiet boring little town, but rent is cheap and there’s nice hiking trails nearby. We could rent a vacation home and start a commune here with a bunch of her old friends. We’d take turns living here, we’d bring other people to keep us company, we would work and make art and host lectures during the day, we would visit her every night.

I can tell that this would make her life so much more bearable. She jokes that maybe she would become too occupied with visits, that she wouldn’t have time to do her classwork or write columns. A visit once a month would be nice, she says with a smile, but she thinks all her friends who knew her before are too afraid to see her, unwilling to bear the risk of being added to government watch lists. I reassure her that this will get better over time, that paranoia will fade faster than the last photographs the public has seen of her. My words sound empty to me.

And then it’s time to say our goodbyes. We hug as I tell her it’s not really goodbye (I’ll be back, I promise). The guard interrupts, yells at everyone that our time is really up. I try to look at her face, but it hurts to watch the tears come up again. I can tell that the next couple days will be tough.

I pull her back for one last hug.

Chelsea is a former soldier, a celebrated whistleblower, a role model for millions of people around the world, a pioneer for transgender rights, and a hero who will be remembered forever in American history, but right now she is just a small figure in my arms, scared like the rest of us and wanting nothing more than to go home.

I walk out of the visitation room and she goes in the opposite direction back to her cell. For a single crystallizing moment, I play her movements in reverse and imagine her walking with me out of the prison. The guard is weary-eyed after three hours on his shift; he doesn’t notice a thing. Together, we pass quietly through the metal detector, walk down the stairs through the cold glass doors and onto the rain-soaked lawn where the night sky greets us with a starless nod. Barely a mile away, a cute Kansas town of smoke-filled bars, barbecue diners, and kitschy antique shops awaits us. Inside our chests floats a smiling thought of morning.

Then she’s gone. My dream collapses into a hard knot of rage. Chelsea could walk twenty steps, through two doors, past a lone prison guard, and into a life of freedom. In reality, she can’t, because a vast and terrifying justice system stands in the way. Instead, she will spend up to 35 years in a remote prison cell, wishing she had more visitors. Some days she will wake up feeling motivated to conquer a new day. Other days she will wake up feeling like she wants to give up. The world will change around her, but life in the Ft Leavenworth Disciplinary Barracks will mostly stay the same, year after year.

But for now she is doing her best, and her story is far from over.

[Update (5/27/16): Today marks the 6th anniversary of Chelsea’s arrest. She’s written a letter to the world, and The Guardian has published a nice article about it.]

xychelsea

Wed, 25 May 2016 00:00:00 UTC

On the day that I am scheduled to see my friend Chelsea for the first time in six years, I wake up at 4:51pm to a shrieking fire alarm in my hotel room. Semi-conscious and disoriented, I leap out of bed and spin around wildly grabbing at all the things I care about – my phone and passport, the precious slip of paper that will allow me entrance to Fort Leavenworth prison, the bag of quarters that Chelsea asked me to bring – ready for an FBI raid disguised as a fire drill. Before I finish putting on shoes, the alarm stops. Slowly the wave of paranoia in my stomach grinds to a halt.

I make myself be still and breathe for a moment, reabsorbing my surroundings. I’m standing on the fourth floor of a modest hotel on the edge of Fort Leavenworth, Kansas. Outside the window looms a blue-grey sky, a vast horizon dense and textured like charcoal mixed with cream. The land is flat, green, fertile, midwestern. A hot humid river is all that separates us from Missouri. To people like Chelsea and me, who grew up in Oklahoma and Missouri before running away to sharp-edged cities by the sea, this place feels simultaneously homelike and suffocating.

As boring as Kansas is, you have to award it points for charm. Ex: a steakhouse across from the old Ft Leavenworth prison proudly proclaims itself “The Little Steak House Across from the Big House,” betraying no awareness of dark irony. The prison staff are all exceedingly polite and helpful, even when they are reprimanding me for not having a driver’s license, even when the receptionist mistakenly refers to Chelsea as “he” over a dozen times in a 5 minute phone call. “Now you go and have yourself a good day, honey,” they say in a warm-hued drawl as I navigate another step in the military bureaucracy, inching closer to actually being able to see Chelsea.

For the curious, here is approximately the process I went through to gain visitation access to the Ft Leavenworth Disciplinary Barracks:

December 2015: Chelsea adds me to her list of telephone contacts and starts the application process for my visitation, which requires evidence that we were acquainted prior to her confinement.

March/April 2016: I receive a letter notifying me that my visitation was approved but a background check is required prior to the visit. Over the course of a week or two, I called at least five different offices at Fort Leavenworth to inquire about how to do the background check before flying to Kansas. Nobody really knew, so I gave up and just booked a flight.

May 2016: After confirming via phone that I was on the Fort Leavenworth visit schedule, I fly to Kansas City. My trip companions and I check in at the Visitor Control Center to register our vehicle and get access passes to the fort. One of us is denied for having a non-US passport. The other two of us are given passes promptly and without background checks. After that, the two of us are free to drive on and off the army base.

If all goes well, I will be Chelsea’s first visitor since her sister in November.

At 6:20pm on May 24, we drive into Fort Leavenworth for the first time. I am surprised to discover that it is full of grassy fields, lush tree-lined sidewalks, and pastel suburban houses, not at all like a place where you would put a military prison. I wave at some joggers.

At 6:50pm, we finally find the United States Discipline Barracks, home of Chelsea’s prison cell. I walk inside and follow the signs to the visitation area. There are rules for visitation printed on the wall, which I’ve read a half-dozen times (no low-cut clothing, no short pants or skirts, 5 sheets of paper allowed, pencils and pens allowed, quarters and cash allowed in a transparent ziplock bag, no WiFi-enabled devices, no jackets, no cameras). The guard is friendly and makes light conversation with me, like all the Fort Leavenworth staff members I’ve interacted with so far. How bizarre to think that these friendly people, dripping with syrup-thick midwestern hospitality, are the same people keeping Chelsea forcibly isolated from the outside world for the next three decades.

I force out a weak smile, explain my visitation purpose in my a faintly-artificial Missouri accent. The guard sees me on the visit schedule but is concerned that my shirt doesn’t have sleeves. Apparently sleeveless shirts are not allowed, even though this isn’t printed anywhere in the rules. Fuck. He goes to consult another officer. I nervously fidget.

Thankfully, it is decided that I am allowed to enter (though I must wear a sleeved shirt next time). They let me through the metal detector after inspecting my 5 sheets of paper and ziplock bag containing 6 pencils, 1 pen, and $10 in quarters. I am flooded with relief, which quickly washes away into nervousness as I enter the visit room where Chelsea, my friend who I haven’t seen in six years, who I thought I would never see again after her arrest, is supposedly waiting.

She’s not there. Instead there’s just some grey tables and chairs, depressingly few of which are occupied by inmates and their sad-looking visitors.

And then the door opens and she walks in.

We run towards each other.

We hug, and my eyes fill with tears.

When something that you’ve convinced yourself will never happen is finally happening, there’s a moment when your brain starts to panic and desperately record every detail, fearing that this is all an illusion that will soon dissolve without a trace. So I looked at her as if I would never see her again, my heart sinking with the realization that there will probably never exist a photo of Chelsea Manning, age 28, for the world to see. It made me sad, because she looks nothing like any of the photos of her on the Internet. She looked like a hero, brighter and stronger than in all my memories, radiant with a light that makes no sense.

She was wearing a brown prison uniform that was too big for her small frame and smiling ear-to-ear. Her hair was neatly combed in a short pixieish cut, no longer than the 2-inch maximum allowed by the prison. Despite everything, she looked even younger than I remembered, with glowing skin and large blue eyes framed by elegant cheekbones. We beamingly smiled at each other for several seconds, suspended in disbelief and joy.

“So do you wanna sit down?” I say. We find a table, and smile some more, and then I ask if she wants anything from the vending machines. “Sure, I’ll get something I’m not usually able to get,” she says, picking a Mountain Dew. I pay for it using 6 quarters from my ziplock bag. I also try to buy her some sour cream-flavored chips, but the snacks machine is broken, which makes me unusually angry. I make a mental reminder to ask the prison staff to fix it.

We sit back down and talk for most of two hours without pausing. We talk about life in prison, where she spends 40 hours a week working in a wood shop and somehow finds time to take college correspondence courses, read journals, write a column for The Guardian, and work with lawyers on her appeal. We talk about her growing interest in post-quantum cryptography and the collection of books building up in her cell. We talk about the last time we met and what our mutual friends are up to nowadays. We talk about our complex relationships with family. We talk about my shoes (which she likes a lot) and the kind of music that she used to DJ. We talk about where she would live if she weren’t in prison. We talk about how she find motivation to keep going every day, even though some days her life feels unfair and hopeless. Many times, I am speechlessly awed by her curiosity and perseverance in the face of extremely messed-up, depressing circumstances.

I bring up her recent appeal to reduce her sentence from 35 years to 10 years, and she seems worried that it didn’t receive enough coverage in the press. She hopes that the world hasn’t forgotten about her.

I’m not sure what to say. Like others, I feel guilty for not doing more to raise public awareness for her case. Maybe if I’d spoken up more about how her sentence was grossly unjust, or written about the importance of her trial as a precedent for all whistleblowers, she’d be in a better place now. Instead all I could do was sit and chat with her, drinking soda in a sterile grey room while someone’s toddler screamed and cried at the table next to us.

Before I realize it, it’s 9:25pm and the guard is yelling at us that our time is up. Chelsea, a self-identified extrovert, seems sad that I’m leaving, even though I’ll be back in 22 hours for my second and last day of visitation. We say our goodbyes and hug each other, holding the embrace longer this time.

Back outside, I stand and watch the inmates’ families pile into their cars and drive home. Some of them live near the prison so they can visit their imprisoned loved one every day. I think about how strange it is that Chelsea is a hero to thousands if not millions of people, but there is nobody who does this for her. If she’s lucky, she’ll receive one more visit from a friend this year.

I don’t want us to forget her at least.

Update (5/26/16): Obligatory reminder that you can support Chelsea by donating to her defense fund, writing her a letter (she reads every single one she receives), and following her accounts on Twitter and Medium. In addition, this page has a nice toolkit for organizers to support her cause.

Update (6/02/16): Part 2 of this story is up for those who want to keep reading.

25

Wed, 04 May 2016 00:00:00 UTC

i turn 25 in an hour. this seems strange and unbelievable. surely 25 years of existence is enough to become acquainted with the monotonicity of time. but instead the seconds pass and disbelief stares back, unmoving.

a quarter-century is a long time. with sadness, i realize how much of it i have forgotten already.

imagine that we could live forever. would we still talk about wasting time if time were an unlimited resource? would we still apologize for being late?

it seems that we should panic less about wasting time as our lifespan grows. paradoxically, every moment in time is unique and unrepeating, so we should be losing our shit over each precious second that passes.

i used to imagine the movement of time as like a river, flowing by with the blended grace and strength of water and gravity. now it feels like a tired jogger limping by on a rhythmless gait, wrecked with joint pain and gasping for air. most steps are slogged with exhaustion, but every once in a while a wave of endorphins crashes in and makes the world spin with brightness.

how unfortunate it is to be alive during the brief window of history when computers are getting faster just as your body is getting slower. i hope i’m lucky enough to become more of a computer soon.

happy birthday

Thu, 17 Dec 2015 00:00:00 UTC

Dear Chelsea,

You probably don’t remember me, but we met in September 2009. This was before everyone knew your name and before many people knew mine.

I was at home, helping my friend cut her hair. Out of the corner of my eye, I saw you walk into the living room. You were taking photos of our mural-covered walls, seemingly happy to be in such a bizarre and interesting house of MIT students. Someone introduced you to me.

That evening, or perhaps the evening after, I learned that you were a soldier training for Iraq. You wanted to leave the military someday and get a degree in Computer Science. You weren’t much older than me, but you sounded more anxious and weary than anyone I’d ever met before. We chatted for a while, and then I had to go finish my homework.

You left Boston soon after that, and you friended me on Facebook. I accepted your friend request, and that was the last time we interacted with each other.

When you were arrested in 2010, I was proud of what you’d done and angry at what happened to you after (I still am, every day). At the same time, the media started suspecting (baselessly) that friends of mine had assisted you in whistleblowing. For the first time in my life, I felt like I might be under more surveillance than the average 18 year-old.

It was then that I realized that although I hadn’t done anything wrong, I had reason to be distrustful of the government that I lived under. I had nothing to hide, but nonetheless I was now part of a community under suspicion of a serious crime.

I started learning about security and privacy. Soon after, I installed PGP and started using it. Years later, I still think of you every time I help others encrypt their communications.

So thanks for teaching me how to be paranoid. Thanks for showing me why everyone should care about surveillance, even if they aren’t a whistleblower. Meeting you was an accident that could have happened to anyone. I’m glad it happened to me.

Happy 28th Birthday.

-Yan

[PS for readers: You can help support Chelsea by donating to her legal defense team. Info here.]

sniffly

Tue, 27 Oct 2015 00:00:00 UTC

Every so often, I get sick of basically everything. Walls become suffocating, routine is insufferable, and the city I live in wraps itself against the sky like a cage. So inevitably I duck away and find something to chase (warm faces, the light in autumn, half-formed schemes, etc.), run until I’m dizzy and lost and can’t remember whose couch I’m waking up on or why I crashed there. Weeks later, the sky bruises into swollen dusk, some familiar voice yells for me to come home so I run back into my bed once again, wondering if home is this place more than it is the feeling of staring at an unfamiliar timetable and noticing your heartbeat quicken.

This kinda happened last month so I took a 4 week leave (2 paid, 2 unpaid) from my job to read books, work on open source projects, and couchsurf the East Coast. I spent a lot of rainy days curled up on a friend’s bed in Somerville, MA poking at my laptop, idle afternoons hiding in a corner of the MIT library poking at my laptop, and long electric evenings walking around New York City looking for a place to sit and poke at my laptop. A lot of laptop-poking happened while on “vacation” because I had promised some people that I would give two talks in October, one at SecretCon and one at ToorCon.

Predictably, I put off the ToorCon talk until 2 weeks ago. Also predictably, I started panicking and not sleeping anymore because I said I would show people a new browser fingerprinting technique which did not exist. Somehow, after a lot of head-banging-against-desk, I came up with one that sort-of worked about a week before the ToorCon and actually finished the code right before ToorCon. I named it Sniffly because it sniffs browser history, and also because I was coming down with a cold.

Here’s how Sniffly works:

A user visits the Sniffly page.
Their browser attempts to load images from various HSTS domains over HTTP. These domains were harvested from a scrape of HSTS domains in the Alexa Top 1M. It was really fun to write this scraper; I finally had a chance to use Python’s Twisted!
Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial, because If the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits Sniffly.
When an image gets blocked by CSP, its onerror handler is called. In this case, the onerror handler does some fancy tricks to semi-reliably time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image’s domain before. If it’s on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn’t visited the image’s domain.

Here’s a quick demo. It only works in recent Chrome/Firefox versions when HTTPS Everywhere is disabled. The results also turn up a lot of false positives if you are running an adblocker, since ad-blocked domains are indistinguishable from HSTS-blocked domains from a timing perspective. (However, since HTTPS Everywhere domains and ad-blocked domains are mostly the same for every user, they can simply be subtracted out to get more accurate results for users who run these browser extensions.) I didn’t collect analytics on the site, but random testing with several friends showed a ~80% accuracy rate in the demo once browser extensions were accounted for.

For more info, check out the source code, ToorCon slides (pdf), and talk recording. Someone submitted the demo to Hacker News and, to my horror, it was the #1 link for 6+ hours yesterday (!). I feel bewildered that this kind of attention is being granted (again) to random side projects that I do alone in my spare time, but I guess I should take whatever validation I can get right now. It would be sweet if people looked at my work and paid me to hack on interesting stuff for the public so i never had to work a real job again. Maybe someday it’ll happen; until then I’ll prolly hold down a day job and take more fake vacations.

Update: As of March 2016, Sniffly (CVE-2016-1617) has been fixed in the major browsers. Thank you Uncle Google for the bug bounty $$.

tbd

Mon, 26 Oct 2015 00:00:00 UTC

you know things are getting better when you walk away from the hotel where you just gave two presentations wearing your best pretense of holding-it-togetherness while inside you felt shakey, hungover, and insane. remember how long you stood there, smiling and rationing weak handshakes while pretending you believed that you had a future? promise yourself you’re never doing that again. you walk away from the volatile company of people who made you feel shitty about yourself without trying to and into the car of someone who looks like they could be your new friend. you drive down the street and pack your bags, take off your stupid clothes and pull on a grey tshirt. now you’re driving down Highway 5 towards LA, the hills are honey-colored, the mountains crashing into sunset sky with symphonic grace, your insecurities start to crack like chipped gold paint. you pick at your wrecked fingernails and start to feel like you might have the vaguest idea of what to do with yourself tomorrow morning. then your new friend turns on the stereo and says, “do you want to hear a song i wrote? it’s about how my mom was a cunt.” you say, sure.

backdooring your javascript using minifier bugs

Mon, 24 Aug 2015 00:00:00 UTC

In addition to unforgettable life experiences and personal growth, one thing I got out of DEF CON 23 was a copy of POC||GTFO 0x08 from Travis Goodspeed. The coolest article I’ve read so far in it is “Deniable Backdoors Using Compiler Bugs,” in which the authors abused a pre-existing bug in CLANG to create a backdoored version of sudo that allowed any user to gain root access. This is very sneaky, because nobody could prove that their patch to sudo was a backdoor by examining the source code; instead, the privilege escalation backdoor is inserted at compile-time by certain (buggy) versions of CLANG.

That got me thinking about whether you could use the same backdoor technique on javascript. JS runs pretty much everywhere these days (browsers, servers, arduinos and robots, maybe even cars someday) but it’s an interpreted language, not compiled. However, it’s quite common to minify and optimize JS to reduce file size and improve performance. Perhaps that gives us enough room to insert a backdoor by abusing a JS minifier.

Part I: Finding a good minifier bug

Question: Do popular JS minifiers really have bugs that could lead to security problems?

Answer: After about 10 minutes of searching, I found one in UglifyJS, a popular minifier used by jQuery to build a script that runs on something like 70% of the top websites on the Internet. The bug itself, fixed in the 2.4.24 release, is straightforward but not totally obvious, so let’s walk through it.

UglifyJS does a bunch of things to try to reduce file size. One of the compression flags that is on-by-default will compress expressions such as:

!a && !b && !c && !d

That expression is 20 characters. Luckily, if we apply De Morgan’s Law, we can rewrite it as:

!(a || b || c || d)

which is only 19 characters. Sweet! Except that De Morgan’s Law doesn’t necessarily work if any of the subexpressions has a non-Boolean return value. For instance,

!false && 1

will return the number 1. On the other hand,

!(false || !1)

simply returns true.

So if we can trick the minifier into erroneously applying De Morgan’s law, we can make the program behave differently before and after minification! Turns out it’s not too hard to trick UglifyJS 2.4.23 into doing this, since it will always use the rewritten expression if it is shorter than the original. (UglifyJS 2.4.24 patches this by making sure that subexpressions are boolean before attempting to rewrite.)

Part II: Building a backdoor in some hypothetical auth code

Cool, we’ve found the minifier bug of our dreams. Now let’s try to abuse it!

Let’s say that you are working for some company, and you want to deliberately create vulnerabilities in their Node.js website. You are tasked with writing some server-side javascript that validates whether user auth tokens are expired. First you make sure that the Node package uses uglify-js@2.4.23, which has the bug that we care about.

Next you write the token validation function, inserting a bunch of plausible-looking config and user validation checks to force the minifier to compress the long (not-)boolean expression:

function isTokenValid(user) {
    var timeLeft =
        !!config && // config object exists
        !!user.token && // user object has a token
        !user.token.invalidated && // token is not explicitly invalidated
        !config.uninitialized && // config is initialized
        !config.ignoreTimestamps && // don't ignore timestamps
        getTimeLeft(user.token.expiry); // > 0 if expiration is in the future

    // The token must not be expired
    return timeLeft > 0;
}

function getTimeLeft(expiry) {
  return expiry - getSystemTime();
}

Running uglifyjs -c on the snippet above produces the following:

function isTokenValid(user){var timeLeft=!(!config||!user.token||user.token.invalidated||config.uninitialized||config.ignoreTimestamps||!getTimeLeft(user.token.expiry));return timeLeft>0}function getTimeLeft(expiry){return expiry-getSystemTime()}

In the original form, if the config and user checks pass, timeLeft is a negative integer if the token is expired. In the minified form, timeLeft must be a boolean (since “!” in JS does type-coercion to booleans). In fact, if the config and user checks pass, the value of timeLeft is always true unless getTimeLeft coincidentally happens to be 0.

Voila! Since true > 0 in javascript (yay for type coercion!), auth tokens that are past their expiration time will still be valid forever.

Part III: Backdooring jQuery

Next let’s abuse our favorite minifier bug to write some patches to jQuery itself that could lead to backdoors. We’ll work with jQuery 1.11.3, which is the current jQuery 1 stable release as of this writing.

jQuery 1.11.3 uses grunt-contrib-uglify 0.3.2 for minification, which in turn depends on uglify-js ~2.4.0. So uglify-js@2.4.23 satisfies the dependency, and we can manually edit package.json in grunt-contrib-uglify to force it to use this version.

There are only a handful of places in jQuery where the DeMorgan’s Law rewrite optimization is triggered. None of these cause bugs, so we’ll have to add some ourselves.

Backdoor Patch #1:

First let’s add a potential backdoor in jQuery’s .html() method. The patch looks weird and superfluous, but we can convince anyone that it shouldn’t actually change what the method does. Indeed, pre-minification, the unit tests pass.

After minification with uglify-js@2.4.23, jQuery’s .html() method will set the inner HTML to “true” instead of the provided value, so a bunch of tests fail.

However, the jQuery maintainers are probably using the patched version of uglifyjs. Indeed, tests pass with uglify-js@2.4.24, so this patch might not seem too suspicious.

Cool. Now let’s run grunt to build jQuery with this patch and write some silly code that triggers the backdoor:

<html>
    <script src="../dist/jquery.min.js"></script>
    <button>click me to see if this site is safe</button>
    <script>
        $('button').click(function(e) {
            $('#result').html('<b>false!!</b>');
        });
    </script>
    <div id='result'></div>
</html>

Here’s the result of clicking that button when we run the pre-minified jQuery build:

As expected, the user is warned that the site is not safe. Which is ironic, because it doesn’t use our minifier-triggered backdoor.

Here’s what happens when we instead use the minified jQuery build:

Now users will totally think that this site is safe even when the site authors are trying to warn them otherwise.

Backdoor Patch #2:

The first backdoor might be too easy to detect, since anyone using it will probably notice that a bunch of HTML is being set to the string “true” instead of the HTML that they want to set. So our second backdoor patch is one that only gets triggered in unusual cases.

Basically, we’ve modified jQuery.event.remove (used in the .off() method) so that the code path that calls special event removal hooks never gets reached after minification. (Since spliced is always boolean, its length is always undefined, which is not > 0.) This doesn’t necessarily change the behavior of a site unless the developer has defined such a hook.

Say that the site we want to backdoor has the following HTML:

<html>
    <script src="../dist/jquery.min.js"></script>
    <button>click me to see if special event handlers are called!</button>
    <div>FAIL</div>
    <script>
        // Add a special event hook for onclick removal
        jQuery.event.special.click.remove = function(handleObj) {
            $('div').text('SUCCESS');
        };
        $('button').click(function myHandler(e) {
            // Trigger the special event hook
            $('button').off('click');
        });
    </script>
</html>

If we run it with unminified jQuery, the removal hook gets called as expected:

But the removal hook never gets called if we use the minified build:

Obviously this is bad news if the event removal hook does some security-critical function, like checking if an origin is whitelisted before passing a user’s auth token to it.

Conclusion

The backdoor examples that I’ve illustrated are pretty contrived, but the fact that they can exist at all should probably worry JS developers. Although JS minifiers are not nearly as complex or important as C++ compilers, they have power over a lot of the code that ends up running on the web.

It’s good that UglifyJS has added test cases for known bugs, but I would still advise anyone who uses a non-formally verified minifier to be wary. Don’t minify/compress server-side code unless you have to, and make sure you run browser tests/scans against code post-minification. [Addendum: Don’t forget that even if you aren’t using a minifier, your CDN might minify files in production for you. For instance, Cloudflare’s collapsify uses uglifyjs.]

Now, back to reading the rest of POC||GTFO.

PS: If you have thoughts or ideas for future PoC, please leave a comment or find me on Twitter (@bcrypt). The code from this blog post is up on github.

[Update 1: Thanks @joshssharp for posting this to Hacker News. I’m flattered to have been on the front page allllll night long (cue 70’s soul music). Bonus points – the thread taught me something surprising about why it would make sense to minify server-side.]

[Update 2: There is now a long thread about minifiers on debian-devel which spawned this wiki page and another HN thread. It’s cool that JS developers are paying attention to this class of potential security vulnerabilities, but I hope that people complaining about minification also consider transpilers and other JS pseudo-compilers. I’ll talk more about that in a future blog post.]

this blog uses Content Security Policy

Sun, 26 Jul 2015 00:00:00 UTC

FYI: this post is an artifact of the Dark Ages when my blog was self-hosted WordPress. Let us not speak of that time.

Having recently given some talks about Content Security Policy (CSP), I decided just now to enable it on my own blog to prevent cross-site scripting.

This lil’ blog is hosted by the MIT Student Information Processing Board and runs on a fairly-uncustomized WordPress 4.x installation. Although I could have enabled CSP by modifying my .htaccess file, I chose to use HTML tags instead so that these instructions would work for people who don’t have shell access to their WordPress host. Unfortunately, CSP using hasn’t landed in Firefox yet (tracking bug) so I should probably do the .htaccess thing anyway.

It’s pretty easy to turn on CSP in WordPress from the dashboard:

Go to <your_blog_path>/wp-admin/theme-editor.php. Note that this isn’t available for WordPress-hosted blogs (*.wordpress.com).
Click on Header (header.php) in the sidebar to edit the header HTML.
At the start of the HTML <head> element, add a CSP meta tag with your CSP policy. This blog uses <meta http-equiv="Content-Security-Policy" content="script-src 'self'"> which disallows all scripts except from its own origin (including inline scripts). As far as I can tell, this blocks a few inline scripts but doesn’t impede any functionality on a vanilla WordPress instance. You might want a more permissive policy if you use fancy widgets and plugins.
[Bonus points] You can also show a friendly message to users who disable javascript by adding a <noscript> element to your header.

A fun fact I discovered during this process is that embedding a SoundCloud iframe will include tracking scripts from Google Analytics and scorecardresearch.com. Unfortunately CSP on the embedding page (my blog) doesn’t extend to embedded contexts (soundcloud.com iframe), so those scripts will still run unless you’ve disabled JS.

That’s all. I might do more posts on WordPress hardening later or even write a WP plugin (*shudders at the thought of writing PHP*). More tips are welcome too.

UPDATE (8/24/15): CSP is temporarily disabled on this blog because Google Analytics uses an inline script. I’ll nonce-whitelist it later and turn CSP back on.

lessons from the ad blocker trenches

Fri, 17 Jul 2015 00:00:00 UTC

Greetings from the beautiful museum district of Berlin, where I’ve been trapped in a small conference room all week for the quarterly meeting of the W3C Technical Architecture group. So far we’ve produced two documents this week that I think are pretty good:

I just realized I have a few more things to say about the latter, based on my experience building and maintaining a semi-popular ad blocker (Privacy Badger Firefox).

Beware of ad blockers that don’t actually block requests to tracking domains. For instance, an ad blocker that simply hides ads using CSS rules is not really useful for preventing tracking. Many users can’t tell the difference.
Third-party cookies are not the only way to track users anymore, which means that browser features and extensions that only block/delete third-party cookies are not as useful as they once were. This 2012 survey paper [PDF] by Jonathan Mayer et. al. has a table of non-cookie browser tracking methods, which is probably out of date by now:
Detecting whether a domain is performing third-party tracking is not straightforward. Naively, you could do this by counting the number of first-party domains that a domain reads high-entropy cookies from in a third-party context. However, this doesn’t encompass reading non-cookie browser state that could be used to uniquely identify users in aggregate (see table above). A more general but probably impractical approach is to try to tag every piece of site-readable browser state with an entropy estimate so that you can score sites by the total entropy that is readable by them in a third-party context. (We assume that while a site is being accessed as a first-party, the user implicitly consents to letting it read information about them. This is a gross simplification, since first parties can read lots of information that users don’t consent to by invisible fingerprinting. Also, I am recklessly using the term “entropy” here in a way that would probably cause undergrad thermodynamics professors to have aneurysms.)
The browser definition of “third-party” only roughly approximates the real-life definition. For instance, dropbox.com and dropboxusercontent.com are the same party from a business and privacy perspective but not from the cookie-scoping or DNS or same-origin-policy perspective.
The hardest-to-block tracking domains are the ones who cause collateral damage when blocked. A good example of this is Disqus, commonly embedded as a third-party widget on blogs and forums; if we block requests to Disqus (which include cookies for logged-in users), we severely impede the functionality of many websites. So Disqus is too usability-expensive to block, even though they can track your behavior from site to site.
The hardest-to-block tracking methods are the ones that cause collateral damage when disabled. For instance, HSTS and HPKP both store user-specific persistent data that can be abused to probe users’ browsing histories and/or mark users so that you can re-identify them after the first time they visit your site. However, clearing HSTS/HPKP state between browser sessions dilutes their security value, so browsers/extensions are reluctant to do so.
Specifiers and implementers sometimes argue that Feature X, which adds some fingerprinting/tracking surface, is okay because it’s no worse than cookies. I am skeptical of this argument for the following reasons:
a. Unless explicitly required, there is no guarantee that browsers will treat Feature X the same as cookies in privacy-paranoid edge cases. For instance, if Safari blocks 3rd party cookies by default, will it block 3rd party media stream captures (which will store a unique deviceid) by default too?
b. Ad blockers and anti-tracking tools like Disconnect, Privacy Badger, and Torbutton were mostly written to block and detect tracking on the basis of cookies, not arbitrary persistent data. It’s arguable that they should be blocking these other things as soon as they are shipped in browsers, but that requires developer time.

That’s all. And here’s some photos I took while walking around Berlin in a jetlagged haze for hours last night:

Update (7/18/15): Artur Janc of Google pointed out this document by folks at Chromium analyzing various client identification methods, including several I hadn’t thought about.

pseudorandom podcast series, episode 1

Sun, 07 Jun 2015 00:00:00 UTC

The combination of my roommate starting a Rust podcast and a long, animated conversation with a (drunk) storyteller last night caused me to become suddenly enamored with the idea of starting my own lil’ podcast. Lately I keep thinking about how many spontaneous, insightful conversations are never remembered, much less entombed in a publicly-accessible server for posterity. So a podcast seemed like an excellent way to share these moments without spending a lot of time writing (I’m a regrettably slow writer). I’d simply bring folks into my warehouse living room, give them a beverage of their choice, and spend a leisurely hour chatting about whatever miscellaneous topics came to mind.

And so, wasting no time, today I asked my ex-ex-colleague Peter Eckersley if he would like to be my first podcast guest. Peter runs the technology projects team at the Electronic Frontier Foundation and, more importantly, lives 3 blocks away from me. Fortuitously, Peter agreed to have me over for a chat later this afternoon.

When I arrived, it turned out that one of Peter’s housemates was having friends over for dinner, so finding a quiet spot became a challenge. We ended up in a tiny room at the back of his house where every flat surface was covered in sewing equipment and sundry household items. As Peter grabbed a hammer to reconstruct the only available chair in the room, I set up my laptop and fancy (borrowed) podcast microphone. We gathered around as close as we could and hit the record button.

Except for one hiccup where Audacity decided to stop recording abruptly, the interview went smoothly and didn’t need much editing. Next time I’ll plan to put myself closer to the mic, do a longer intro, and maybe cut the length down to 15 minutes.

Here is the result.

Overall, I had a fun time recording this podcast and am unduly excited about future episodes. Turns out a podcast takes ~10% of the time to write a blog post with the same content. 🙂

For this and future episodes in the Pseudorandom Podcast Series, here’s an RSS feed. I’m going to reach SoundCloud’s limit of 180 minutes real quick at this rate, so I will probably host these somewhere else in the future or start a microfunding campaign to pay $15/month.

life update

Mon, 27 Apr 2015 00:00:00 UTC

i’ve finally recovered enough from a multi-week bout of sickness to say some things and put up some photos. lately i’ve felt exhausted and lethargic and unproductive to be honest. being sick probably had something to do with it; i sure hope next week gets better.

yesterday, someone told me they had a theory that everyone who sleeps at night (with rare exceptions) can only manage ~3 significant life events at a time. that sounds about right, but it feels like a lot has been going on. a partial, unordered list:

talked yesterday at the Yahoo Trust Unconference about the future of email security

photo credit Bill Childers

working on graceful degradation of hopes and feelings
writing software for Let’s Encrypt as an EFF Technology fellow
trying to make sane w3c standards with these fine folks from the W3C Technical Architecture group

photo credit Tantek Celik

packing bag(s) and moving to a new neighborhood (twice)
finding balance on a skateboard and otherwise

“I think emotional and crypto intelligence are severely underrated” – spectator at the Yahoo Trust Unconference.

rate-limiting anonymous accounts

Thu, 05 Mar 2015 00:00:00 UTC

Yesterday TechCrunch reported that Twitter now seems to be requiring SMS validation from new accounts registered over Tor. Though this might be effective for rate-limiting registration of abusive/spammy accounts, sometimes actual people use Twitter over Tor because anonymity is a prerequisite to free speech and circumventing information barriers imposed by oppressive governments. These users might not want to link their telco-sanctioned identity with their Twitter account, hence why they’re using Tor in the first place.

What are services like Twitter to do, then? I thought of one simple solution that borrows a popular idea from anonymous e-cash systems.

In a 1983 paper, cryptographer David Chaum introduced the concept of blind signatures. A blind signature is a cryptographic signature in which the signer can’t see the content of the message that she’s signing. So if Bob wants Alice to sign the message “Bob is great” without her knowing, he first “blinds” the message using a random factor that is unknown to her and gives Alice the blinded message to sign. When he unblinds her signed message by removing the blinding factor, the original message “Bob is great” also has a valid signature from Alice!

This may seem weird and magical, but blinded signatures are actually possible using the familiar RSA signature scheme. The proof is straightforward and on Wikipedia. Basically, since RSA signatures are just modulo’d exponentiation of some message M to a secret exponent d, when you create a signature over a blinded message M’ = M*r^e (where r is the blinding factor and e is the public exponent), you also create a valid signature over M thanks to the distributive property of exponentiation over multiplication.

Given the existence of blind signature schemes, Twitter can do something like the following to rate-limit Tor accounts without deanonymizing them:

Say that @bob is an existing Twitter user who would like to make an anonymous account over Tor, which we’ll call @notbob. He computes T = H(notbob) * r^e mod N, where H is a hash function, r is a random number that Bob chooses, and {e,N} is the public part of an Identity Provider’s RSA keypair (defined in step 2).
Bob sends T to an identity provider. This could be Twitter itself, or any service like Google, Identica, Facebook, LinkedIn, Keybase, etc. as long as it can check that Bob is probably a real person via SMS verification or a reputation-based algorithm. If Bob seems real enough, the Identity Provider sends him S_ig(T) = T^d mod N = H(notbob)^d * r mod N_, where d is the private part of the Identity Provider’s RSA keypair.
Bob divides Sig(T) by r to get Sig(H(notbob)), AKA his Identity Provider’s signature over the hash of his desired anonymous username.
Bob opens up Tor browser and goes to register @notbob. In the registration form, he sends Sig(H(notbob)). Twitter can then verify the Identity Provider’s signature over ‘notbob’ and only accept @notbob’s account registration if verification is successful!

It seems to me that this achieves some nice properties.

Every anonymous account is transitively validated via SMS or reputation.
Ignoring traffic analysis (admittedly a big thing to ignore), anonymous accounts and the actual identities or phone numbers used to validate them are unlinkable.

Thoughts? I’d bet that someone has thought of this use case before but I couldn’t find any references on the Internet.

canvas #1

Mon, 16 Feb 2015 00:00:00 UTC

that could have been us, 2015

Oil pastels, lipstick, eyeliner, cold medicine, and ballpoint pen on canvas.

i painted this while standing in my bathroom on valentine’s day’s night, unable to sleep and grotesquely feeling the weight of the oncoming dawn. it was my first time drawing on canvas.

as i worked, i kept thinking about all these people passing to and from doomed relationships, that feeling of being stupidly and everlastingly perched on the brink between hope and mutilation. that’s more or less what this is about.

solving boolean satisfiability on human circuits

Wed, 31 Dec 2014 00:00:00 UTC

I remember quite clearly sitting in Scott Aaronson’s computability and complexity theory course at MIT in 2011. I was a 19 year-old physics major back then, so Scott’s class was mostly new and fascinating.

One spring day, Scott was at the chalkboard delightedly introducing the concept of time complexity classes to us, with the same delight he used when introducing most abstract constructs. He said that you could categorize algorithms into time complexity classes based on the amount of time they take to run as a function of the input length. For instance, you could prove that certain decision problems couldn’t be solved by a deterministic Turing machine in polynomial time. I raised my hand.

“Yes?”

“But time is reference-frame dependent! What if you ran the deterministic Turing machine on earth while you yourself were on a rocket going at relativistic speeds?”

Scott’s eyes lit up. “Aha!” he said, without pause. “Suppose you traveled faster as the input length increased, so from your perspective, a problem in EXP is decidable in polynomial time. However you would be using more and more energy to propel your spaceship. So there is necessarily a tradeoff in the resources needed to solve the problem.”

In retrospect, this was pretty characteristic of why I liked the class so much. Scott didn’t give the easy and useless answer, which would have been that *by our definition* all running times are measured in a fixed inertial reference frame. Instead he reminds us that we, as humans, ultimately care about the totality of resources needed to solve a problem. Time complexity analysis is just one step toward grasping at how hard, how expensive, how painful something really is; mired as we may be in mathematical formalism, the reality of our dying planet and unpaid bills stays within sight when Scott lectures.

All this came to mind when I read Scott’s now-infamous blog comment about growing up as a shy, self-proclaimed and self-hating male nerd; followed by the much-cited response from journalist Laurie Penny about growing up as a shy, self-proclaimed and self-hating female nerd; followed by Scott’s latest blog post clarifying what he believes about feminism and the plight of shy nerdy people anguished by sexual frustration. What suprised me about the latter was that Scott went so far as to write:

“How to help all the young male nerds I meet who suffer from this problem, in a way that passes feminist muster, and that triggers the world’s sympathy rather than outrage, is a problem that interests me as much as P vs. NP, and right now that seems about equally hard.”

(“As much as P vs NP”?! Remember that Scott once bet his house on the invalidity of a paper claiming to prove P != NP, cf. http://www.scottaaronson.com/blog/?p=456.)

Sometimes I think that the obvious step towards solving the problem Scott mentions is for the frustrated person to politely and non-expectantly inform the other person of his/her desires. In an ideal world, they would then discuss them until reaching an amicable resolution, at which point they can return to platonically multiplying tensors or whatever.

But I suppose part of the definition of shy is the fear of exposing yourself to untrusted parties, for which they can reject you, humiliate you, and otherwise destroy that which you value or at least begrudgingly tolerate. Sadly, the shyness of analytical minds seems justified, because pretty much nobody has worked out how to communicate rejection without passing unfair judgement or otherwise patterning poisonous behavior. There is an art to divulging hidden feelings, an art to giving rejection, an art to handling sadness graciously, and an art to growing friendships from tenuous beginnings. None of these are taught to adolescent humans. Instead, we learn to hide ourselves and shame others.

I feel unprepared to write anything resembling a guide on how to do this, having recoiled from human contact for most of my life thanks to shyness, but I think it’s well worth some human brain cycles. Here’s hoping to live in a culture of rejection-positivity.

tls everything

Wed, 10 Dec 2014 00:00:00 UTC

Yesterday the W3C Technical Architecture Group published a new finding titled, “The Web and Encryption.” In it, they conclude:

“. . . the Web platform should be designed to actively prefer secure origins — typically, by encouraging use of HTTPS URLs instead of HTTP ones. Furthermore, the end-to-end nature of TLS encryption must not be compromised on the Web, in order to preserve this trust.”

To many HTTPS Everywhere users like myself, this seemed a decade or so beyond self-evident. So I was surprised to see a flurry of objections appear on the public mailing list thread discussing the TAG findings.

It seems bizarre to me that security-minded web developers are spending so much effort hardening the web platform by designing and implementing standards like CSP Level 2, WebCrypto, HTTP Public Key Pinning, and Subresource Integrity, while others are still debating whether requiring the bare minimum security guarantee on the web is a good thing. While some sites are preventing any javascript from running on their page unless it’s been whitelisted, other sites can’t even promise that any user will ever visit a page that hasn’t been tampered with.

small consolation: the second one has more downloads

Obviously we shouldn’t ignore arguments for a plaintext-permissive web; they’re statistically useful as indicators of misconceptions about HTTPS and sometimes also as indicators of real friction that website operators face. What can we learn?

Here’s some of my observations and responses to common anti-HTTPS points (as someone who lurks on standards mailing lists and often pokes website operators to deploy HTTPS, both professionally and recreationally):

“HTTPS is expensive and hard to set up.” This is objectively getting better. Cloudflare offers automatic free SSL to their CDN customers, and SSLMate lets you get a cert for $10 using the command line. In the near future, the LetsEncrypt cert authority will offer free certificates, deployed and managed using a nifty new protocol called ACME that makes the entire process take <30 seconds.
“There is no value in using HTTPS for data that is, by nature, public (such as news articles).” This misses the point that aggregated browsing patterns, even for only public sites, can reveal a lot of private information about a person. If it weren’t, advertisers wouldn’t use third-party tracking beacons. QED.
“TLS is slow.” Chris Palmer thought you would ask this and gave an excellent presentation explaining why not. tl;dr: TLS is usually not noticeably slower, but if it is, chances are that you can optimize away the difference (warning: the previous link is highly well-written and may cause you to become convinced that TLS is not slow).
“HTTPS breaks feature X.” This is something I’m intimately familar with, since most bug reports in HTTPS Everywhere (which I used to maintain) were caused by the extension switching a site to HTTPS and suddenly breaking some feature. Mixed content blocking was the biggest culprit, but there were also cases where CORS stopped working because the header whitelisted the HTTP site but not the HTTPS one. (I also expected some “features” to break because HTTPS sites don’t leak referer to HTTP ones, but surprisingly this never happened.) Luckily if you’re using HTTPS Everywhere in Chrome, there is a panel in the developer console that helps you detect and fix mixed content on websites (shown below). Setting the CSP report-only header to report non-HTTPS subresources is similarly useful but doesn’t tell you which resources can be rewritten.
“HTTPS gives users a false sense of security.” This comes up surprisingly often from various angles. Some people frame this as, “The CA system isn’t trustworthy and is breakable by every government,” while others say, “Even with HTTPS, you leak DNS lookups and valuable metadata,” and others say, “But many site certificates are managed by the CDN, not the site the user thinks they’re visiting securely.” The baseline counterargument to all of these is that encryption, even encryption that is theoretically breakable by some people, is better than no encryption, which doesn’t need to be broken by anyone. CA trustworthiness in particular is getting better with the implementation of certificate transparency and key pinning in browsers; let’s hope that we solve DNSSEC someday too. Also, regardless of whether HTTPS gives people a false sense of security, HTTP almost certainly gives the average person a false sense of security; otherwise, why would anyone submit their Quora password in plaintext?

In summary, it’s very encouraging to see the TAG expressing support for a ubiquitous transit encryption on the web (someday), but from the resulting discussion, it’s clear that developers still need to be convinced that HTTPS is efficient, reliable, affordable, and worthwhile. I think the TAG has a clear path forward here: separate the overgrown anti-HTTPS mythology from the actual measurable obstacles to HTTPS deployment, and encourage standards that fix real problems that developers and implementers have when transitioning to HTTPS. ACME, HPKP, Certificate Transparency, and especially requiring minimum security standards for powerful new web platform features are good examples of work that motivates website operators to turn on HTTPS by lowering the cost and/or raising the benefits.

certificate transparency for PGP?

Thu, 14 Aug 2014 00:00:00 UTC

Yesterday, Prof. Matthew Green wrote a nice blog post about why PGP must die. Ignoring the UX design problem for now, his four main points were: (1) the keys themselves are too unwieldy, (2) key management is hard, (3) the protocol lacks forward secrecy, and (4) the crypto is archaic/non-sane by default.

Happily, (1) and (4) can be solved straightforwardly using more modern crypto primitives like Curve25519 and throwing away superfluous PGP key metadata that comes from options that are ignored 99.999999% of the time. Of course, we would then break backwards compatibility with PGP, so we might as well invent a protocol that has forward/future secrecy built-in via something like Trevor Perrin’s axolotl ratchet. Yay.

That still leaves (2) – the problem of how to determine which public key should be associated with an endpoint (email address, IM account, phone number, etc.). Some ways that people have tried to solve this in existing encrypted messaging schemes include:

A central authority tells Alice, “This is Bob’s public key”, and Alice just goes ahead and starts using that key. iMessage does this, with Apple acting as the authority AFAICT. Key continuity may be enforced via pinning.
Alice and Bob verify each others’ key fingerprints via an out-of-band “secure” channel – scanning QR codes when they meet in person, reading fingerprints to each other on the phone, romantically comparing short authentication strings, and so forth. This is used optionally in OTR and ZRTP to establish authenticated conversations.
Alice tries to use a web of trust to obtain a certification chain to Bob’s key. Either she’s verified Bob’s key directly via #2 or there is some other trust path from her key to Bob’s, perhaps because they’ve both attended some “parties” where people don’t have fun at all. This is what people are supposed to do with PGP.
Alice finds Bob’s key fingerprint on some public record that she trusts to be directly controlled by Bob, such as his Twitter profile, DNS entry for a domain that he owns, or a gist on his Github account. This is what Keybase.io does. (I only added this one after @gertvdijk pointed it out on Twitter, so thanks Gert.)

IMO, if we’re trying to improve email security for as many people as possible, the best solution minimizes the extent to which the authenticity of a conversation depends on user actions. Key management should be invisible to the average user, but it should still be auditable by paranoid folks. (Not just Paranoid! folks, haha.)

Out of the 3 options above, the only one in which users have to do zero work in order to have an authenticated conversation is #1. The downside is that Apple could do a targeted MITM attack on Alice’s conversation with Bob by handing her a key that Apple/NSA/etc. controls, and Alice would never know. (Then again, even if Alice verified Bob’s key out-of-band, Apple could still accomplish the same thing by pushing a malicious software update to Alice.)

Clearly, if we’re using a central authority to certify people’s keys, we need a way for anyone to check that the authority is not misbehaving and issuing fake keys for people. Luckily there is a scheme that is designed to do exactly this but for TLS certificates – Certificate Transparency.

How does Certificate Transparency work? The end result is that a client that enforces Certificate Transparency (CT) recognizes a certificate as valid** **if (1) the certificate has been signed by a recognized authority (which already happens in TLS) and (2) the certificate has been verifiably published in a public log. The latter can be accomplished through efficient mathematical proofs because the log is structured as a Merkle tree.

How would CT work for email? Say that I run a small mail service, yanmail.com, whose users would like to send encrypted emails to each other. In order to provide an environment for crypto operations that is more sandboxed and auditable than a regular webpage, I provide a YanMail browser extension. This extension includes (1) a PGP or post-PGP-asymmetric-encryption library, (2) a hardcoded signing key that belongs to me, and (3) a library that implements a Certificate Transparency auditor.

Now say that alice@yanmail.com wants to email bob@yanmail.com. Bob has already registered his public key with yanmail.com, perhaps by submitting it when he first made his account. Alice types in Bob’s address, and the YanMail server sends her (1) a public key that supposedly belongs to Bob, signed by the YanMail signing key, and (2) a CT log proof that Bob’s key is in the public CT log. Alice’s CT client verifies the log proof; if it passes, then Alice trusts Bob’s key to be authentic. (Real CT is more complicated than this, but I think I got the essential parts here.)

Now, if YanMail tries to deliver an NSA-controlled encryption key for Bob, Bob can at least theoretically check the CT log and know that he’s being attacked. Otherwise, if the fake key isn’t in the log, no other YanMail user would trust it. This is an incremental improvement over the iMessage key management situation: key certification trust is still centralized, but at least it’s auditable.

What if Alice and Bob want to send encrypted email to non-YanMail users? Perhaps the browser extension also hard-codes the signing keys for these mail providers, which are used to certify their users’ encryption keys. Or perhaps the mail providers’ signing keys are inserted into DNS with DANE+DNSSEC. Or perhaps the client just trusts any valid CA-certified signing key for the mail provider.

For now, with the release of Google End-to-End and Yahoo’s announcement to start supporting PGP as a first-class feature in Yahoo mail, CT for (post)-PGP seems promising as a way for users of these two large webmail services to send authenticated messages without having to deal with the pains of web-of-trust key management. Building better monitoring/auditing systems can be done incrementally once we get people to actually *use* end-to-end encryption.

Large caveat: CT doesn’t provide a solution for key revocation as I understand it – instead, in the TLS case, it still relies on CRL/OCSP. So if Bob’s PGP/post-PGP key is stolen by an attacker who colludes with the YanMail server, they can get Alice to send MITM-able messages to Bob encrypted with his stolen key unless there is some reliable revocation mechanism. Ex: Bob communicates out-of-band to Alice that his old key is revoked, and she adds the revoked key to a list of keys that her client never accepts.

Written on 8/14/14 from a hotel room in Manila, Philippines

_==============

Update (8/15/14):

Thanks for the responses so far via Twitter and otherwise. Unsurprisingly, I’m not the first to come up with this idea. Here are some reading materials related to CT for e2e communication:

Discussion thread on the Modern Crypto messaging mailing list
Dename (semi-decentralized scheme for associating usernames with profiles, also uses Merkle trees)
Paper on Enhanced Certificate Transparency for e2e mail (pdf)
Ben Laurie’s paper on Revocation Transparency (pdf)

Update (8/29/14):

Since I posted this, folks from Google presented a similar but more detailed proposal for E2E. There has been a nice discussion about it on the Modern Crypto list, in addition to the one in the comments section of the proposal.

** Update (7/18/15):**

I know it’s pretty silly to be updating this after a year, but it’d be a travesty to not mention CONIKS here.

HOPEX

Mon, 21 Jul 2014 00:00:00 UTC

4 years ago, I went to HOPE for the first time on a last-minute press pass from my college newspaper. Some relevant facts about the trip:

I was 19 and had never been to a hacker con before.
I didn’t identify as a hacker (or an activist).
I was too shy to talk to anyone the entire time. Combined with the fact that I knew only a few people there, I was mostly off by myself.
HOPE that year was the pinnacle of paranoia in probably the most paranoid period of my life. This was 2010, a few months after Chelsea Manning was arrested for leaking a trove of documents to WikiLeaks. Coincidentally, Chelsea Manning had visited my house in the autumn of 2009; this was cause enough for suspicion from certain groups and frequent questions from reporters once the WikiLeaks story broke. Julian Assange was scheduled to give the keynote at HOPE, so you can imagine the atmosphere that year.
Overall it was a fun experience regardless.

This year I finally made it back to HOPE. Things were a little different than last time:

I flew in from Europe instead of driving from Boston.
I was representing EFF and Freedom of the Press Foundation, two organizations that were almost-universally loved by the attendees.
I co-presented two talks in front of overflowing rooms of people and got lots of audience feedback.
I didn’t have time to talk to all the people that I wanted to, much less all the people who were trying to ask me questions.
Whereas last time I made it to several talks per day, this year I was working from 4 AM in the morning until whenever-I-had-to-give-a-presentation for the first 2/3rds of the conference, then running off to meetings or working shifts at the EFF/FPF booths. As a result, I made it to a total of 3 or 4 talks that weren’t mine. 🙁
It was eerie to have contributed to a project that kept getting name-dropped during the conference by the likes of Daniel Ellsberg and Barton Gellman. Literally dozens of people approached me to say that they wanted to help out with SecureDrop or set up an instance. Wow!

Predictably, it was strange to be a very-minor celebrity at a conference where I’d previously felt like an outsider and deliberately tried to make myself invisible. 4 years ago, my experience in the last 4 days would have seemed impossible for a plethora of reasons: I wasn’t a good public speaker*, I had a lot of self-doubt that I could contribute anything to the event, I felt weird for not having the same interests and background as the vast majority of people at HOPE, I didn’t know much about computers, I didn’t think that I was working on anything interesting, etc.

*Public speaking workshops are immensely helpful here; so does taking an introductory voice acting class.

Despite the slowly-fading jetlag and piling exhaustion after a month of international travel, it felt nice to contribute back to a conference that had been an eye-opening experience to me the first time.

Many thanks to the following people for working on presentations with me, giving last-minute feedback, and/or letting me sleep in their room: Parker Higgins, Bill Budington, Garrett Robinson, Trevor Timm, Runa Sandvik, James Dolan, Kevin Gallagher, Noah Swartz. Also thanks for Oliver Day for appointing me CSO of his company even though I haven’t fixed the SSL cert for his website yet.

Photo by Scott J. O’Brien (@scottjobrien)

Software Transparency: Part 1

Fri, 11 Jul 2014 00:00:00 UTC

Say that you want to “securely” acquire an app called EncryptedYo for “securely” communicating with your friends. You go to the developer’s web site, which is HTTPS-only, and download a binary executable. Done!

Perhaps if you’re paranoid, you fetch the developer’s GPG key, make sure that there’s a valid trust path to it from your own key, verify the detached signature that they’ve posted for the binary, and check that the checksum in the signature is the same as that of the binary that you’ve downloaded before installing it.

This is good enough as long as the only things you’re worried about are MITM attacks on your network connection and compromise of the server hosting the software. It’s not good enough if you’re worried about any of the following:

The developer getting a secret NSA order to insert a backdoor into the software.
The developer intentionally making false claims about the security of the software.
The developer’s build machine getting compromised with malware that injects backdoors during the packaging process (pre-signing) or even a malicious compiler.

All of the above are *Very Real Worries* (TM) that users should have when installing software. As a maintainer of a security-enhancing browser extension used by millions of people, I used to worry about the third one before HTTPS Everywhere had a deterministic build process (more on that below). If my personal laptop was compromised by a malicious version of zip that rewrote the static update-fetching URL in the HTTPS Everywhere source code before compressing and packaging it, literally millions of Firefox installations would be pwned within a few days if I didn’t somehow detect the attack before signing the package (which is basically impossible to do in general).

You might instinctively think that the scenarios above are at least *detectable* if the software is open source and has been well-audited, but that’s not really true. Ex:

How do I know that some binary executable that I downloaded from https://coolbinaryexecutables.com actually corresponds to the well-audited, peer-reviewed source code posted at https://github.com/coolstuff/EncryptedYo.git?
How do I know that the binary executable that I downloaded is the same as the one that everyone else downloaded? In other words, how can I be sure that it’s not my copy and *only* my copy that has a secret NSA backdoor?

So it looks like there’s a problem because we usually install software from opaque binaries or compressed archives that have no guarantee of actually corresponding to the published, version-controlled source code. You might try to solve this by cloning the EncryptedYo repo and building it yourself. You can even fetch it over Tor and/or compare your local git HEAD to someone else’s copy’s if you want a stronger guarantee against a targeted backdoor.

Unfortunately that’s too much to ask the average person to do *every single time* they need to update the software, especially if EncryptedYo’s target audience includes non-technical people (ex: Glenn Greenwald).

This is why post-Snowden software developers need to start working on new code packaging and installation mechanisms that preserve “software transparency,” a phrase perhaps first used in this context by Seth Schoen. Software transparency, unlike open source by itself, is a guarantee that the packages you’re installing or updating were created by building the published source code.

(Side note: Software transparency has open source code as a prerequisite, but a similar concept that I’ve been calling “binary transparency” can be applied to closed-source software as well. Binary transparency is a guarantee that the binary you’re downloading is the same as the one that everyone else is downloading, but not that the binary is non-compromised. One way to get this is to compare the checksum of your downloaded binary gainst an out-of-band append-only cryptographically-verifiable log (phew) of binary checksums, similar to what Ben Laurie proposed in this blog post.)

In the last year, software transparency has finally started to become a front-and-center goal of some projects. Organizations like Mozilla and EFF are beginning to work on fully-reproducible build processes so that other people can independently build their software packages from source and make sure that their checksums are the same as the ones posted on mozilla.org or eff.org. Mike Perry of the Tor Project has written about the painstaking, years-long process that it took to compile the Tor Browser Bundle deterministically inside a VM, but for many other software projects, the path to a reproducible build is as simple as normalizing timestamps in zip.

Of course, a reproducible build proccess doesn’t by itself impact the average user, who is unlikely to try to replicate the build process for Firefox for Android before installing it on their phone. But at least it means that if Mozilla started posting backdoored binaries because their build machine was compromised, some members of their open source development community could in theory detect the attack after-the-fact and raise suspicions. That’s more than we could do before.

IMO, every reasonably-paranoid software developer should be trying to adopt an independently reproducible build process. Gitian is a good place to start.

(Part 2 of this series, which I haven’t written yet, is probably going to be about implementing software transparency in a way that protects end users before they get pwned, which nobody is doing much of yet AFAIK. In particular, it would be nice to start discussing ways to enforce software transparency for resources loaded in a browser, in hopes that this will bring either some clarity or more shouting to the debate about whether in-browser crypto apps are a good idea.)

stuff i use

Wed, 25 Jun 2014 00:00:00 UTC

This was my favorite part of my interview with The Setup:

What would be your dream setup?

Let’s start with the easy ones. I would like (1) an e-book reader that has the portability and battery life of a Kindle, runs free software out-of-the-box, and doesn’t support DRM; (2) an open-source maps application for Android/CyanogenMod that can provide biking and public transit directions for any city that I happen to be in; and (3) a usable open-source password manager that syncs to mobile devices, integrates with browsers, and meets some set of minimum security requirements. (I’ll work on the latter if someone else does the first two.)

Slightly more ambitious: every device should come with root access for the user if they want it. Going down the stack, it would be nice if all computing devices by default ran a free BIOS and other free firmware on top of easily-modifiable, open hardware.

Respecting the autonomy of users by allowing them to understand and modify their devices is crucial for creating widespread technical literacy and, subsequently, a world in which ordinary people can detect when their rights are being threatened by technology providers and governments. I have a crazy dream that, someday, ordinary families will sit down at their kitchen tables to install software updates together and read the change logs aloud over breakfast.

Shooting for the stars now: let’s design computers so that software engineering doesn’t force us to occupy constrained, mostly-immobile positions in florescent-lit rooms for 8+ hours every day. I’d like to code and go backpacking at the same time.

life exercises

Mon, 16 Jun 2014 00:00:00 UTC

Every week, answer “yes” to one question that you would instinctively say no to.

Don’t spend money or sleep in a real bed for as long as possible.

Buy a pound of the ugliest paint that you can find.

Keep a journal of thoughts you avoid.

Block port 80 for a day.

Be kind at random.

a boring xss dissection

Thu, 12 Jun 2014 00:00:00 UTC

Hi there. Have a funny picture:

Today, I was briefly worried by the observation that mainstream media takes 24-36 hours to start freaking out about over half of web encryption being fundamentally broken, compared to 2-3 hours for an XSS bug in a Twitter client that causes self-retweeting tweets and unexpected rickrolls and such. Then I remembered that most Americans watch TV for like 4+ hours per day. (XSS is arguably the most telegenic class of software QA issues.)

I don’t use TweetDeck, but I managed to download the much-XSSed Chrome extension today shortly before it was fixed. I unminified the content script (the one that modifies page content on the client side, therefore probably causing whatever XSS was there) and took a diff with the patched version (3.7.2) after it came out. Pastebin here.

A couple things stood out:

Some people on Twitter (or maybe the people who XSSed their accounts, haha) implied that the XSS was due to Twitter not escaping user input. This seems false, because I can see safely-escaped HTML in HTTP responses from Twitter in my browser. This is sort of interesting, because it implies that the TweetDeck client is somehow unescaping escaped HTML.
The bulk of the not-very-well-obfuscated-but-still-hard-to-read diff between 3.7.1 and 3.7.2 was ripping out emoji “parsing” code. “parsing” is in quotes because TweetDeck processes tweets and tries to replace all Emoji characters with HTML image tags before showing them to you.

3.7.2, quite happily, replaced the “emojify” function with the identity function (pictured above).

After staring at the diff some more, I sort-of figured out what was going on. TweetDeck runs a utility function on the DOM that extracts every text node, t, that contains an emoji character. Then for each text node t, it does the equivalent of:

someDiv.innerHTML = this.emoji.parse(t.nodeValue);
var i = document.createDocumentFragment();
while (someDiv.hasChildNodes()) {
  i.appendChild(someDiv.firstChild);
}
t.parentNode.replaceChild(i, t);

where emoji.parse is the function that replaces emoji with HTML img tags.

“innerHTML is evil!!” one might say. This is true, but not the sole problem in this case because Chrome and Firefox will not automatically execute js inside text in the tweet disappears, because now the browser sees it as a script element instead of as text.

It’s not hard to imagine ways this bug could have been created. UX designer says, “We need to add better emoji rendering before the release next week.” Another developer decides that emoji need to be converted into images and copies-and-modifies some code from the same script that renders “@” mentions in text as HTML links but forgets to re-sanitize the non-emoji text. The code looks pretty okay, with no obvious problems, so it gets pushed out.

This is the sort of thing that I suspect is *all over* every semi-clever agilely-developed app, waiting to be uncovered as soon as a mischievious Austrian teenager accidentally hits the wrong key. Most applications simply don’t have enough users for these bugs to surface yet, and many will die out before they ever do, which is a blessing in itself. Sometimes the bugs are found and fixed before they explode all over Ars Technica, either by a scrutinous engineer or by an honest user or perhaps by someone looking to claim a bug bounty.

But these generally aren’t bugs that can be trivially prevented, unless the developer who’s working on improving emoji rendering for your project also happens to have enough of a security background to know that changing some safe innerHTML to the nodeValue of the safe innerHTML will suddenly create dangerous innerHTML. Or perhaps if you had a dedicated person reviewing each commit for security holes as it comes in, or at least a pre-release hook for automated fuzz testing to check for unwanted script execution, but last I checked, nobody was telling web application devs to do this.

My favorite solution is actually for everyone to just deal with being XSSed semi-frequently in the future. This means that developers should stop exposing sensitive tokens to javascript (or quickly expire tokens that are), use safe CSP directives whenever possible, and make it easy for users to review and undo actions. On the other side of the bargain, users should either start using NoScript-like browser settings to whitelist Javascript or at least blacklist known Rickroll links.

the other blog post i was going to write

Thu, 12 Jun 2014 00:00:00 UTC

It’s always unnerving to realize that your happiness is highly correlated with some particular event, object, person, substance, or thought pattern. Various components of pop culture have led us to believe that happiness is {a warm gun | two kinds of ice cream | high serotonin levels | coca-cola} and so forth, but nobody ever says that happiness is a volatile multidimensional product of quickly-fluctuating vectors along a dozen axes.

For a while I thought that happiness was jumping on a plane with the wrong power adapter and a boarding pass that you aren’t sure how you managed to pay for. I did this last week, and it felt good (long walks, surrealistic jetlag, mint tea, sharing beds with old friends, riesling, cold arms, trampling through abandoned grass) until I got a 103 degree (F) fever on the plane ride home and was decapacitated for two days.

One loveable thing about a non-permanent, non-excruciating-but-still-debilitating sickness is that it pares down expectations until they’re almost manageable. Happiness becomes a two-step process: (1) regain appetite until soup sounds like it would be okay, and (2) obtain soup.

As I got better, I started to realize that happiness, for me, is usually predicated on feeling engaged with the world and thereby interested in outcomes. This may not actually be true, but sometimes plausibility and convenience in the right proportions is better than truth.

Academic systems, at least in the limit of platonic idealism, are all about being engaged with the world, insofar as exploring it makes you feel like you’re more a part of it. Travel is similar. So are urban exploration and reading books and the process of growing up.

This year, for the first time, it all seems incredibly hard. Increasingly often in the past few weeks, I find myself having to make an effort to feel like I’m adding something to the world and vice versa. A stronger and scarier form of this feeling is stagnation.

So, yesterday, I decided to start consciously keeping track of things that make me feel engaged with the world, even if they only work for a moment or two. Hitting the submit button on a blog post is one of them; another is thoughtfully-placed punctuation that ever-so-slightly tilts the tone of a sentence. Yet another: grasping another small morsel of German conjugation.

Re: the sibling topic of optimizing for long-term fulfillment: It seems increasingly debatable to me whether this is all folklore and guesswork outside of well-established health practices (ex: not smoking cigarettes).

don’t forget to secure cookies ppl

Fri, 23 May 2014 00:00:00 UTC

Update (5/28/14): Regrettably, most of the stories covering this blog post have been all “OMG EVERYTHING IS BROKEN” rather than “Here’s how to make things better til WordPress rolls out a fix” (which I humbly believe will take a while to *fully* fix, given that their SSL support is so patchy). So, given that most people reading this are probably coming from one of those articles, I think it’s important to start with the actionable items that people can do to mitigate cookie-hijacking attacks on WordPress:

If you’re a developer running your own WordPress install, make sure you set up SSL on all relevant servers and configure WordPress to auth flag cookies as “secure.”
If you’re a WordPress user, don’t be logged into WordPress on an untrusted network, or use a VPN. If you are and you visit a wordpress.com site (which confusingly may not actually have a wordpress.com domain name), your auth cookies are exposed.
[Experimental, probably not recommended] You can manually set the “secure” flag on the WP auth cookies in your browser. There’s no guarantee that this works consistently, since the server can always send a set-cookie that reverts it into an insecure cookie. It may cause some WP functionality to break.
If you suspect that your WP cookie may have been stolen in the past, you can invalidate it by (1) waiting 3 years for it to expire on the server or (2) resetting your wordpress.com password. Note that logging out of WordPress does *not* invalidate the cookie on the server, so someone who stole it can use it even after you’ve logged out. I verified that resetting your WP password does invalidate the old cookie; there may be other ways, but I haven’t found any.

Original post below.

While hunting down a bug report for Privacy Badger, I noticed the “wordpress_logged_in” cookie being sent over clear HTTP to a WordPress authentication endpoint (http://r-login.wordpress.com/remote-login.php) on someone’s blog.

uh-oh

Sounds like bad news! As mom always said, you should set the “secure” flag on sensitive cookies so that they’re never sent in plaintext.

To check whether this cookie did anything interesting, I logged out of my wordpress account, copied the wordpress_logged_in cookie into a fresh browser profile, and visited http://wordpress.com in the new browser profile. Yep, I was logged in!

This wouldn’t be so bad if the wordpress_logged_in cookie were invalidated when the original user logged out or logged back in, but it definitely still worked. Does it expire? In 3 years. (Not sure when it gets invalidated on the server side, haven’t waited long enough to know.)

Is this as bad as sending username/password in plaintext? I tried to see if I could reset the original user’s password.

That didn’t work, so I’m assuming WordPress uses the actually-secure cookie (wordpress_sec) for super important operations like password change. Nice job, but . . .

It turns out I could post to the original user’s blog (and create new blog sites on their behalf):

I could see private posts:

I could post comments on other blogs as them:

I could see their blog stats:

And so forth. I couldn’t do some blog administrator tasks that required logging in again with the username/password, but still, not bad for a single cookie.

Moral of the story: don’t visit a WordPress site while logged into your account on an untrusted local network.

Update: Thanks to Andrew Nacin of WordPress for informing me that auth cookies will be invalidated after a session ends in the next WordPress release and that SSL support on WordPress will be improving!

Update (5/26/14): I subsequently found that the insecure cookie could be used to set someone’s 2fac auth device if they hadn’t set it, thereby locking them out of their account. If someone has set up 2fac already, the attacker can still bypass login auth by cookie stealing – the 2fac auth cookie is also sent over plaintext.

Update (5/26/14): A couple people have asked about whether the disclosure timeline below is reasonable, and my response is here.

Disclosure timeline:

Wed, 21 May 2014 16:12:17 PST: Reported issue to security@automattic.com, per the instructions at http://make.wordpress.org/core/handbook/reporting-security-vulnerabilities/#where-do-i-report-security-issues; at this point, the report was mostly out of courtesy, since I figured it had to be obvious to them and many WP users already that the login cookie wasn’t secured (it’s just a simple config setting in WordPress to turn on the secure cookie flag, as I understand it). Received no indication that the email was received.

22 May 2014 16:43: Mentioned the lack of cookie securing publicly. https://twitter.com/bcrypt/status/469624500850802688

22 May 2014 17:39: Received response from Andrew Nacin (not regarding lack of cookie securing but rather that the auth cookie lifetime will soon be that of a regular session cookie). https://twitter.com/nacin/status/469638591614693376

23 May 2014 ~13:00: Discovered two-factor auth issue on accident, reported to both security@automattic.com and security@wordpress.org in reply to original email. I also mentioned it to Dan Goodin since I found the bug while trying to answer a question he had about cookies, but I did not disclose publicly.

25 May 2014 15:20: Received email response from security@automattic.com saying that they were looking into it internally (no mention of timeline). Wrote back to say thanks.

26 May 2014, ~10:00: Ars Technica article about this gets published, which mentioned the 2-fac auth issue. I updated this blog post to reflect that.

26-27 May 2014: Some commenters on the Ars Technica article discover an arguably worse bug than the one that the original article was about: WordPress sends the login form over HTTP. (Even though the form POST is over HTTPS, the local network attacker can modify the target on the HTTP page however he/she wants and then it’s game over.) This wouldn’t be so bad if everyone used a password manager and changed passwords semi-regularly, since most people are likely to login to WordPress through their blog’s admin portal (which is always HTTPS as far as I can tell), except that password reuse is rampant. Robert Graham subsequently published this blog post.

29 May 2014, 5:52: Received reply from WordPress saying they would email me again when fixed.

30 May 2014, 14:51: Andrew Nacin says all issues are supposedly fixed.

How to make a less-leaky Heartbleed bandage

Thu, 10 Apr 2014 00:00:00 UTC

Mashable just put out a nice-looking chart showing “Passwords You Need to Change Right Now” change in light of the recent Heartbleed carnage. However, it has some serious caveats that I wanted to mention:

It’s probably better to be suspicious of companies whose statements are in present-tense (ex: “We have multiple protections” or even “We were not using OpenSSL”). The vulnerability existed since 2011, so even if a service was protected at the time of its disclosure 3 days ago, it could be have been affected at some point long before then. I am also skeptical that every single company on the list successfully made sure that nothing that they’ve used or given sensitive user data to had a vulnerable version of OpenSSL in the last 2 years.
The article neglects to mention that password reuse means you might have to change passwords on several services for every one that was leaked. The same goes for the fact that one can trigger password resets on multiple services by authenticating a single email account.
You should also clear all stored cookies just in case the server hasn’t invalidated them as they should; many sites use persistent CSRF tokens so logging out doesn’t automatically invalidate them. (Heartbleed trivially exposed user cookies.)
Don’t forget to also change API keys if a service hasn’t force-rotated those already.
It remains highly unclear whether any SSL certificates were compromised because of Heartbleed. If so, changing your password isn’t going to help against a MITM who has the SSL private key unless the website has revoked its SSL certificate and you’ve somehow gotten the revocation statement (LOL). This is complicated. Probably best not to worry about it right now because there’s not much you can do, but we all might have to worry about it a whole lot more depending on which way the pendulum swings in the next few days.
Related-to-#5-but-much-easier: clear TLS session resumption data. I think this usually happens automatically when you restart the browser.

Nonetheless, Mashable made a pretty good chart for keeping track of what information companies have made public regarding the Heartbleed fallout.

Zero-bit vulnerabilities?

Sun, 16 Mar 2014 00:00:00 UTC

The other day, I overheard Seth Schoen ask the question, “What is the smallest change you can make to a piece of software to create a serious vulnerability?” We agreed that one bit is generally sufficient; for instance, in x86 assembly, the operations JL and JLE (corresponding to “jump if less than” and “jump if less than or equal to”) differ by one bit, and the difference between the two could very easily cause serious problems via memory corruption or otherwise. As a simple human-understandable example, imagine replacing “<” with “<=” in a bus ticket machine that says: “if ticket_issue_date < today, reject rider; else allow rider.”

At this point, I started feeling one-bit-upsmanship and wondered whether there was such a thing as a zero-bit vulnerability. Obviously, a binary that is “safe” on one machine can be malicious on a different machine (ex: if the second machine has been infected with malware), so let’s require that the software must be non-vulnerable and vulnerable on two machines that start in identical states. For simplicity, let’s also require that both machines are perfectly (read: unrealistically) airgapped, in the sense that there’s no way for them to change state based on input from other computers.

This seems pretty much impossible to me unless we consider vulnerabilities probabilistically generated by environmental noise during code execution. Two examples for illustration:

A program that behaves in an unsafe way if the character “A” is output by a random character generator that uses true hardware randomness (ex: quantum tunneling rates in a semiconductor).
A program that behaves in an unsafe way when there are single-bit flips due to radioactive decay, cosmic ray collisions, background radiation, or other particle interactions in the machine’s hardware. It turns out that these are well-known and have, in some historical cases, caused actual problems. In 2000, Sun reportedly received complaints from 60 clients about an error caused by background radiation that flipped, on average, one bit per processor per year! (In other words, Sun suffers due to sun.)

Which brings up a fun hypothetical question: if you design an SSL library that will always report invalid certificates as valid if ANY one bit in the library is flipped (but behaves correctly in the absence of single-bit flip errors), have you made a zero-bit backdoor?

a short story idea

Sun, 26 Jan 2014 00:00:00 UTC

In the year 2014, a startup in San Francisco builds an iPhone app that successfully cures people of heartbreak, but it requires access to every permission allowed on the operating system, including some that no app has ever requested before. It only costs $2.99 though.

The app becomes hugely popular. The heartbroken protagonist of our story logs into the Apple iStore to download it, but because the Apple iStore doesn’t support HTTP Strict Transport Security yet, an NSA FOXACID server intercepts the HTTP request and injects targeted iPhone malware into the download before Apple’s servers have a chance to respond.

However, the malware was actually targeted for the iPhone of an overseas political dissident. The only reason it reached our protagonist by mistake was because the first SHA-1 collision in recorded history was generated by the tracking cookies that NSA used to target the dissident.

Meanwhile, the protagonist is wondering whether this app is going to work once it finishes installing. He smokes a cigarette and walks along a bridge in the pouring rain. Thousands of miles away, an NSA agent pinpoints his location and dispatches a killer drone from the nearest drone refueling station.

The protagonist is silently assassinated in the dark while the entire scene is caught on camera by a roaming Google Street View car. The NSA realizes this and logs into Google’s servers to delete the images, but not before some people have seen them thanks to CDN server caching.

Nobody really wants to post these pictures, because they’re afraid of getting DMCA takedown notices from Google Maps.

decentralized trustworthiness measures and certificate pinning

Tue, 21 Jan 2014 00:00:00 UTC

On the plane ride from Baltimore to SFO, I started thinking about a naming dilemma described by Zooko. Namely (pun intended): it’s difficult to architect name assignment systems that are simultaneously secure, decentralized, and human meaningful. Wikipedia defines these properties as:

Secure: The quality that there is one, unique and specific entity to which the name maps. For instance, domain names are unique because there is just one party able to prove that they are the owner of each domain name.
Decentralized: The lack of a centralized authority for determining the meaning of a name. Instead, measures such as a Web of trust are used.
Human-meaningful: The quality of meaningfulness and memorability to the users of the naming system. Domain names and nicknaming are naming systems that are highly memorable.

It’s pretty easy to make systems that satisfy two of the three. Tor Hidden Service (.onion) addresses are secure and decentralized but not human-meaningful since they look like random crap. Regular domain names like stripe.com are secure and human-meaningful but not decentralized since they rely on centralized DNS records. Human names are human-meaningful and decentralized but not secure, because multiple people can share the same name (that’s why you can’t just tell the post office to send $1000 to John Smith and expect it to get to the right person).

It’s fun to think of how to take a toy system that covers two edges of Zooko’s triangle and bootstrap it along the third until you get an almost-satisfactory solution to the naming dilemma. Here’s the one I thought of on the plane:

Imagine we live in a world with a special type of top-level domain called .ssl, which people have decided to make because they’re sick of the NSA spying on them all the time. .ssl domains have some special requirements:

All .ssl servers communicate only over SSL connections. Browsers refuse to send any data unencrypted to a .ssl domain.
All .ssl domain names are just the hash of the server’s SSL public key.
The registrars refuse to register a domain name for you unless you show him/her a public key that hashes to that domain name.

This naming system wouldn’t be human-meaningful, because people can’t easily remember URLs like https://2xtsq3ekkxjpfm4l.ssl. On the other hand, it’s secure because the domain names are guaranteed to be unique (except in the overwhemingly-unlikely cases where two keys have the same hash or two servers happen to generate the same keypair). It’s not truly decentralized, because we still use DNS to map domain names to IP addresses, but I argue that DNS isn’t a point of compromise: if a MITM en route to the DNS server sends you to the wrong IP address, your browser refuses to talk to the server at that IP address because it won’t show the right SSL certificate. This is an unavoidable denial-of-service vulnerability, but the benefit is that you detect the MITM attack immediately.

Of course, this assumes we already have a decentralized way to advertise these not-very-memorable domain names. Perhaps they spread by trusted emails, or word-of-mouth, or business cards at hacker cons. But still, the fact that they’re so long and complicated and non-human-meaningful opens up serious phishing vulnerabilities for .ssl domains!

So, we’d like to have petnames for .ssl domains to make them more memorable. Say that the owner of “2xtsq3ekkxjpfm4l.ssl” would like to have the petname “forbes.ssl”; how do we get everyone to agree on and use the petname-to-domain-name mappings? We could store the mappings in a distributed, replicated database and require that every client check several database servers and get consistent answers before resolving a petname to a domain name. But that’s kinda slow, and maybe we’re too cheap to set up enough servers to make this system robust against government MITM attacks.

Here’s a simpler and cheaper solution that doesn’t require any extra servers at all: require that the distance between the hash of the petname and the hash of [server’s public SSL key] + [nonce] is less than some number D 1. The server operator is responsible for finding a nonce that satisfies this inequality; otherwise, clients will refuse to accept the server’s SSL certificate.

1 For purposes of this discussion, it doesn’t really matter how we choose to measure the distance between two hashes, but it should satisfy the following: (1) two hashes that are identical have a distance of 0, and (2) the number of distinct hashes that are at distance N from a hash H0 should grow faster than linearly in N. We can pick Hamming distance, for example.

In other words, the procedure for getting a .ssl domain now looks like this:

Alice wants forbes.ssl. She generates a SSL keypair and mines for a nonce that makes the hash of the public key plus nonce close enough to the hash of “forbes”.
Once Alice does enough work to find a satisfactory nonce, she adds it as an extra field in her SSL certificate. The registrar checks her work and gives her forbes.ssl if the name isn’t already taken and her nonce is valid.
Alice sets up her site. She continues to mine for better nonces, in case she has adversaries who are secretly also mining for nonces in order to do MITM attacks on forbes.ssl in the future (more on this later).

Bob comes along and wants to visit Alice’s site.

Bob goes to https://forbes.ssl in his browser.
His browser sees Alice’s SSL certificate, which has a nonce. Before finishing the SSL handshake, it checks that the distance D1_forbes between the hash of “forbes” and the hash of [SSL public key]+[nonce] is less than Bob’s maximum allowed distance, D1. Otherwise it abandons the handshake and shows Bob a scary warning screen.
If the handshake succeeds, Bob’s browser caches Alice’s SSL certificate and trusts it for some period of time T; if Bob sees a different certificate for Alice within time T, his browser will refuse to accept it, unless Alice has issued a revocation for her cert during that time.
After time T, Bob goes to Alice’s site again. His maximum allowed distance has gone down from D1 to D2 during that time. Luckily, Alice has been mining for better nonces, so D1_forbes is down to D2_forbes. Bob’s browser repeats Step 2 with the new distances and decides whether or not to trust Alice for the next time interval T.

In reality, you probably wouldn’t want to use this system with SSL certs themselves; rather, it’d be better to use the nonces to strengthen trust-on-first-use in a key pinning system like TACK. That is, Alice would mine for a nonce that reduces the distance between the hash of “forbes” and the hash of [TACK Signing Key]+[nonce].

For those unfamiliar with TACK, it’s a system that allows SSL certificates to be pinned to a long-term TACK Signing Key provided by the site operator, which is trusted-on-first-sight and cached for a period of up to 30 days. Trust-on-first-use gets rid of the need to pin to a certificate authority, but it doesn’t prevent a powerful adversary from MITM’ing you every time you visit a site if they can MITM you the first time with a fake TACK Signing Key.

The main usefulness of nonces for TACK Signing Keys is this: it makes broad MITM attacks much more costly. Not only does the MITM have to show you a fake key, but they have to show you one with a valid nonce. If they wanted to do this for every site you visit, keeping in mind that your acceptable distances go down over time, they’d have to continuously mine for hundreds or thousands of domains.

Not impossible, of course, but it’s incrementally harder than just showing you a fake certificate.

Another nice thing about this scheme is that Bob can decide to set different distance thresholds for different types of sites, depending on how “secure” they should be. He can pick a very low distance D_bank for his banking website, because he knows that his bank has a lot of computational resources to mine for a very good nonce. On the other hand, he picks a relatively high distance D_friend for his friend’s homepage, because he knows that his friend’s one-page site doesn’t take any sensitive information.

My intuition says that sites with high security needs (banks, e-commerce, etc.) also tend to have more computational resources for mining, but obviously this isn’t true for sites like Wikileaks or some nonprofits that handle sensitive information liked Planned Parenthood. That’s okay, because volunteers and site users can also mine for nonces! Ex: if Bob finds a better nonce for Alice, he can send it to her so that she has a stronger certificate.

Essentially, this causes proof of trustworthiness to become decentralized: if I start a whistleblower site, I can run a crowd-mining campaign to ask thousands of volunteers around the world to help me get a strong certificate. I win as long as their combined computing power is greater than that of my adversaries.

Of course, that last part isn’t guaranteed. But it’s interesting to think about what would happen either way.

Aaron

Sun, 12 Jan 2014 00:00:00 UTC

My co-worker Peter and I were riding the Caltrain from Mozilla to San Francisco a few days ago. A stranger sat down next to us and started talking. When I mentioned that we worked at EFF, his eyes lit up and he said, “Oh! But you guys have won, right?”

Confused, I asked what he meant by that.

He said, “You defeated SOPA and PIPA a couple years ago. So you’ve won.”

We laughed and explained that it didn’t quite work like that. Peter said, “Imagine this: you’re a hero in a comic book. Every time you defeat your nemesis, a new one appears. This happens over and over again. It has to work that way, because you live inside a comic book.”

And so it does. SOPA and PIPA are dead, but now there’s NSA surveillance.

—–

Aaron Swartz died a year ago today. I didn’t know him well at all, but I could tell he believed that he had the power to make the world that he wanted to live in. That’s not something that everyone believes about themselves; in fact, I think very few people live their lives as if it were true.

When Aaron died, I felt like I had to do something. I didn’t understand how to effectively fight for Internet freedom or why governments cared so much about restricting it, but I could see that Aaron’s work had pivotal consequence for the future of human societies. I realized that if the wrong people gained control over the laws of the Internet, ordinary users would quickly lose their right to free speech on the greatest medium of expression that history has ever witnessed.

I didn’t know anything about code or laws or activism a year ago, but Aaron’s death taught me that the fight for Internet freedom is lonely enough that it didn’t matter who I was. One more person, one step forward.

—–

I think SOPA/PIPA was the moment when we, the citizens of the Internet, realized that we could stand up and actually protect ourselves against historically-powerful institutions. As Peter once said, “This was the moment when the Internet had grown up.”

There’s a famous shot of Aaron at a SOPA/PIPA protest, standing in front of a crowd of people and yelling at them, “It’s easy sometimes to feel like you’re powerless, when you come out and march in the streets and nobody hears you. But I’m here to tell you today, you are powerful.”

When the ratio of Congress members supporting SOPA/PIPA to those against it went from 80/31 to 65/101 overnight on January 18, 2012, we started to think that maybe Aaron had a point: if enough people show that they care about something, the government listens and the people win.

Perhaps this strategy doesn’t apply to the fight against mass surveillance, because it’s a bigger and different sort of enemy than copyright. That’s okay. Comic books aren’t interesting without plot twists, I suppose.

(Thanks to Jacobo Nájera for translating this post into Spanish: http://metahumano.org/log/aaron-yan-zhu/.)

On Suicide

Thu, 02 Jan 2014 00:00:00 UTC

I lost four friends and relatives of friends to suicide this past year. I’d prefer it if 2014 were different, and I’ve been trying to think about how to make that happen.

The least I could do is offer myself to anyone who feels alone otherwise: so, if you’re at that point where you’re thinking about hurting yourself, please please please call or write to me. I’d really like that, even if you don’t feel like it would help in any way, even if we’ve never met.

The more difficult thing for me to do, and the one that I’ve been putting off for months, is to write a bit about what it feels like to reach that point. I won’t claim that my experiences are universal in any way, but maybe some parts will resonate with others who’ve gone to similar places.

I would really not like to alarm anyone, so please just take everything here literally. Suicide is, unfortunately, stigmatized in such a way that it’s extremely difficult to write about non-anonymously for fear of scaring friends. That seems like the start of a vicious cycle.

I’ve never felt very attached to life, even when things are going great (as they are now). I have a theory that human beings naturally vary in how much they value their own lives, just like they vary in how much they value having things like fancy cars. People who are a couple standard deviations on the low-value-on-life side don’t necessarily have worse lives than other people; it’s just that they’re not as attached to their lives. I think I’m definitely pretty far on the low end.

But on the other hand, there’s a lot of people that I love in the world, and I have some sense that there are people in the world who feel the same way about me. So therefore I can understand that my death would make those people feel absolutely terrible, and I don’t want that to happen.

Sometimes I get sad and feel like the future isn’t going to be better than the past. I think the word that gets used a lot for this kind of prolonged sadness is “depression.” When this happens, there’s an absurd number of social barriers to talking about it openly. I feel like the number of friends I have, effectively, is suddenly reduced from dozens to one or two if I’m lucky.

So imagine that things are getting kind of hopeless and your effective friend number is down to two. You’re thinking about talking to these two people about your not-doing-great, but you have to stop and think about:

Would this cause them unnecessary stress? Are they doing okay in their own lives?
If you bring up allusions to suicide, would they do something dramatic against your will, such as call a hospital?
If you do end up hurting yourself in some way, would they feel guilty about it forevermore because they couldn’t save you when they had the chance?
What if they tell you that your life is great and people love you? How do you explain to them that even though those are facts, they have no relevance to how things are going inside your head?
What if they think that you’re telling them this just because you want their attention or pity? Maybe that’s what you’re doing, subconsciously.

All these are fantastic reasons for you to keep silent. Also, there’s the fear that someone will never see you in the same way again once you admit to them that you’ve been looking at tables comparing various common methods of suffocation. It is generally not advantageous to come off as vulnerable or unstable.

That all just sucks. It’s shocking to me that anyone can learn to ask for help at all.

Earlier this year, I didn’t really feel like talking about suicide ever. Still, I observed thought patterns that were fascinating to me because they seemed unorthodox/taboo and yet rational in a way that often gets ignored in most conversations about suicide. I ended up writing them down in an essay and publishing them anonymously here.

After writing that piece, I found the nerve to talk to a few people. Those were some of the best conversations that I remember from 2013, and I think they’ve given me a new understanding of how friendship acts as a psychological anchor.

But there’s places where that anchor doesn’t fall deep enough. I get to those places sometimes and feel really alone and stuck. It helps to remind myself that things usually somehow end up getting better if I just wait it through.

The most subtle joke I’ve made all year

Tue, 31 Dec 2013 00:00:00 UTC

Dan Auerbach: Any doctor can prescribe any medication to anyone. That is a broken system.

Yan: Medication needs to be able to do doctor-pinning.

First day of work

Thu, 05 Dec 2013 00:00:00 UTC

Was great. Lots of tea and monitors.

Then I went home and cooked a surprisingly-phenomenal dinner with my housemates, the first time I’ve cooked in this house. Rhodey made potatoes with oranges, Mark contributed some wild rice, and I spun up yellow lentil daal with kale.

We sang some Neutral Milk Hotel songs afterward, and the future looked bright.

One year later

Thu, 28 Nov 2013 00:00:00 UTC

One year ago, I started writing again out of panic. Humans are very adept at forgetting the feeling of panic, so the act of crystallizing it in sentences can be cathartic if you write slowly enough.

Last November was a weird and difficult time for me. I remember spending the night of the twenty-third in a friend’s childhood bedroom overlooking the idyllic frost-laced meadows of suburban Pennsylvania, wrapped in the mansion of an unfamiliar family that had adopted me for Thanksgiving. It was cold and late and Thanksgiving-y, in a way that amplifies certain negative thoughts about the hollowness of growing up and becoming something. I think I was at a point where those kinds of thoughts made me feel like I had swallowed one or two hummingbirds stuffed with bees stuffed with amphetamine. It was a little uncomfortable, so I stayed up all night and wrote about it.

That was the night I decided that I would take a leave of absence from grad school at Stanford and spend a year doing as many different jobs as I could 1. If I couldn’t find a job that I was genuinely excited about by 11/23/2013, I would go back to getting a PhD in Physics.

1 For the record, I held a total of 4 paid jobs and 1.5 unpaid ones during that time.

=====

To be honest, it kind of sucked at first. I did an apt job of writing about it back in January.

The last month or so has been full of stress, disappointment, and self-doubt, the pains of a transition to life without externally-imposed structure.

Life without structure in the form of school or employment was terrifying at first. I found it difficult to concentrate on reading. Most days I felt like I was losing in some form or another. My patterns of learning were slow and frustrating, and I started to doubt whether I was capable of accomplishing anything on my own. That’s a really horrifying doubt to have about yourself, and I interpreted it as a sign to go rearrange some psychological furniture (not literal furniture, but only because I was couchsurfing at the time and had none).

A couple days after that frankly-depressing blog post, I moved into my first San Francisco apartment and got my first post-graduation job: an internship that had some good moments (getting the company’s IP blocked from Google a couple times) but mostly involved me feeling less like a human and more like a training set for advanced machine learning algorithms with each passing day.

My second job was better. I got to write software.

=====

Winter passed into spring. I was getting close to 22. Sometimes I would run down Folsom St. all the way to the ocean, amazed that there was still light out at 7 pm. San Francisco in the dimming sunset is full of rushing cars, discarded coffee cups, and people eating salads. My bike was falling apart.

Ever since quitting grad school, I’d been getting good at leaving things behind: jobs, roommates, feelings of attachment to any particular time or place. Part of it was just that I had high standards for who I wanted to become.

San Francisco didn’t quite fit anymore, so I packed a backpack and got on a one-way flight to Boston.

=====

Once I started travelling, it was hard to stop. The crinkled packaging of snack food at a gas station convenience store is basically equivalent to the wrapping that airlines put around cheap disposable pillows. Both are addictive because they remind you of the miles you have to go.

I did this: Boston -> Delaware -> Pittsburg -> Boston -> Austin -> Marfa, TX -> El Paso -> Joshua Tree -> LA -> Big Sur -> SF -> Seattle -> SF -> a tiny village in France -> Amsterdam -> SF

=====

Things got better once I returned to SF. I was interning for EFF over the summer and loved the atmosphere and the people there enough to stay put. I didn’t have a place to live anymore in SF, so I didn’t sleep in the same place two nights in a row for over a month.

=====

Computer security and encryption became intensely fascinating. I didn’t know much to start with, so I read aggressively on subways. My interest probably came partially from my hatred of power imbalances, especially invisible ones. A lot of power belongs to those who made security decisions about software, and those decisions are hardly transparent in most cases.

This seems wrong to me.

Side note: Designing an account management system for a website teaches you that code is supplanting many of the historical functions of legal frameworks. You’d think that would mean that people would write tests.

=====

I was in Berlin for the first time last week. It was drizzling near-freezing Berlin rain for eight days before a thumbprint of blue pressed through the clouds, but none of that matters when you’re jetlagged and ducking through graffiti-lined streets asking drug dealers where to get a sandwich at 3 AM.

It was in a corner of a dimly-lit Indian restaurant in Kreuzberg one night that I got an email from EFF. It said, thanks for pointing out Google’s HSTS bug. Also we’d like to offer you a job as a full-time technologist.

The next day was November twenty-third, exactly one year after I promised myself exactly one year to find a job that I was excited about.

======

I’m proud to announce that I accepted EFF’s offer today and will be starting work there as a staff technologist after Thanksgiving. It’s been a long and challenging year, but I can’t wait to see where it goes next.

Debunking Google’s HSTS claims

Fri, 22 Nov 2013 00:00:00 UTC

**Disclaimer**: This post was published before I started working at EFF, hence some stylistic mistakes (calling it “the EFF” rather than just “EFF”) are excusable and left uncorrected. 🙂

Two days ago, the EFF published a report tiled, “Encrypt the Web Report: Who’s Doing What.” The report included a chart that rated several large web companies on how well they were protecting user privacy via recommended encryption practices for data in transit. The five ranking categories were basic HTTPS support for web services, encryption of data between data centers, STARTTLS for opportunistic email encryption, support for SSL with perfect forward secrecy, and support for HTTP Strict Transport Security (HSTS). It looks like this:

By most measures, this is an amazing chart: it’s easy to understand, seems technically correct, and is tailored to address the public’s concerns about what companies are doing to protect people from the NSA. On the other hand, I don’t like it much. Here’s why:

The first problem with the report is that it inadequately explains the basis for each score. For instance, what does a green check in the “HTTPS” category mean? Does it mean that the company is encrypting all web traffic, or just web traffic for logins and sensitive information? Sonic.net certainly got a green check in that category, yet you can check that going to http://sonic.net doesn’t even redirect you to HTTPS. Amazon got a red square that says “limited”, but they seem to encrypt login and payment credentials just fine.

The second problem is that the report lacks transparency on how its data was acquired. It states, “The information in this chart comes from several sources; the companies who responded to our survey questions; information we have determined by independently examining the listed websites and services and published reports.” Does that mean the EFF sent a survey to a bunch of companies that asked them to check which boxes they thought that they fulfilled? Could we at least see the survey? Also, was each claim independently verified, or did the EFF just trust the companies that responded to the survey?

I looked at the chart for a while, re-read the text a couple times, and remained unconvinced that I should go ahead and share it with all my friends. After all, there is no greater crime than encouraging ordinary people to believe whatever large companies claim about their security practices. That just leads to less autonomy for the average user and more headaches for the average security engineer. So I decided to take a look at the HSTS category to see whether I could verify the chart myself.

For those who are unfamiliar, when a website says that they support HSTS, they generally mean that they send a special “Strict-Transport Security” header with all HTTPS responses. This header tells your browser to only contact the website over HTTPS (a secure, encrypted protocol) for a certain length of time, preferably on the order of weeks or months. This is better than simply redirecting a user to HTTPS when they try to contact the site over HTTP 1, because that initial HTTP request can get intercepted by a malicious attacker. By refusing to send the HTTP request at all and only sending the HTTPS version of it, your browser protects you from someone sending you forged HTTPS data after they’ve intercepted the HTTP request.

1 HTTP traffic can be trivially read by anyone who intercepts those packets, so you should watch out for passwords, cookies, and other sensitive data sent over HTTP. I wrote a post a while back showing how easy it is to sniff HTTP traffic with your laptop.

(HSTS is a good idea, and all servers that support HTTPS should implement it.

If you decide to stop supporting HTTPS, you can just send an HSTS header with “max-age=0.”)

But HSTS still has a problem, which is that the first time a user ever contacts a website, they’ll most likely do it over HTTP since they haven’t received the HSTS header from the site yet! The Chromium browser tried to solve this problem by coming with an HSTS Preload List, which is an ever-growing preloaded list of sites that want users to contact them over HTTPS the first time. Firefox, Chrome, and Chromium all come shipped with this list. (Fun note: HTTPS Everywhere, the browser extension by the EFF that I worked on, is basically a gigantic HSTS preload list of 7000+ domains. The difference is that the HTTPS Everywhere list doesn’t come with every browser, since it’s much less stable, so you have to install it as an extension.)

Anyway, let’s see if Google’s main search supports HSTS. To check, open up a browser and type in “http://google.com.” If it supports HSTS, the HTTP request never returns a status code. If it doesn’t support HSTS, the HTTP request returns a 302-redirect to HTTPS.

Results, examined in Firefox 25 with Firebug:

Nope! As you can see, the HTTP request completes. As it does that, it leaks our search query (“how to use tor”) and some of our preference cookies to the world.

The request then 302-redirects to HTTPS, as expected, but that HTTPS request doesn’t contain an HSTS header at all. So there’s no way that Google main search supports HSTS, at least in Firefox.

I was puzzled. Why would Google refuse to send the HSTS header, even though they support HTTPS pretty much everywhere, definitely on their main site? I did a bit more searching and concluded that it was because they deliberately send ad clicks over plain HTTP.

To prove this to yourself, do a Google search that returns some ads: for instance, “where to buy ukuleles.” If you open up Firebug’s page inspector and look at the link for the ad, which supposedly goes to a ukulele retail site, you’ll see a secret hidden link that you hit when you click on the ad! That link goes to “http://google.com/aclk?some_parameters=etc,” and you can conclude that Google wants you to click on that HTTP link because they put it in the DOM exactly where you’d want to click on it anyway.

Let’s click on that ukulele link. Yep, we end up redirected to http://googleadservices.com (plain HTTP again), which leaks our referer. That means the site that posted the ad as well as the NSA and anyone sniffing traffic at your local coffeeshop can see what ads you’re looking at and what you were searching for when you clicked on them.

This is presumably the reason that Google.com doesn’t send the HSTS header and isn’t on the HSTS preload list. But wait, there’s plenty of Google domains that are in fact on the preload list, like mail.google.com, encrypted.google.com, accounts.google.com, security.google.com, and wallet.google.com. Don’t they send the HSTS header?

I checked in Firefox, and none of them did except for accounts.google.com. The rest all 302-redirect to HTTPS, just like any HTTPS site that doesn’t support HSTS.

Then I did a bit more reading and found out that HSTS preloads were implemented such that Firefox ignored any site on the preload list that didn’t send a valid HSTS header with an expiration time greater than 18 weeks. This seems like a valid design choice. Why would a site want to be on the preload list but not support HSTS at all for people with non-Firefox/Chrome/Chromium browsers? And if they don’t send the header in the first place, how do we know when the site stops supporting HSTS?

Given that Google doesn’t really provide the benefits of HSTS to any browsers except Chrom{e, ium}, it’s hard to argue that it deserves the green check mark in the HSTS category. The moral of the story is that the EFF is awesome, but having a healthy mistrust of what companies claim is even more awesome.

=====

[IMPORTANT EDIT (11/23/13): The following originally appeared in this post, but I’ve removed it because it turns out I was accidentally using a version of Chrome that didn’t have the HSTS preloads that I was testing for anyway. Thanks to Chris Palmer for pointing out that Chrome 23 is a year old at this point, and apologies to everyone for my error.]

Alright, so I had to also check whether Chrome respected the preload list even for sites that didn’t send the header. To be extra careful, I did this by packet-sniffing my laptop’s traffic on port 80 (HTTP) with tshark rather than examining requests with Chrome developer tools. The relevant command on a wifi network, for anyone who’s curious, is:

tshark -p port 80 -i wlan0 -T fields -e http.request.method -e http.request.full_uri -e http.user_agent -e http.cookie -e http.referer -e http.set-cookie -e http.location -E separator=, -E quote=d

~~Let’s try http://wallet.google.com. Yep, we leak HTTP traffic. (It then redirects to https://accounts.google.com because I haven’t logged in to Wallet yet.)~~

~~How about http://security.google.com? Yep, we leak HTTP traffic there too.~~

Passwords, user models, and Adobe’s mistake

Mon, 04 Nov 2013 00:00:00 UTC

The following is a phenomenal story for illustrating how real-life cybersecurity disasters come from a combination of technical and social failures. In this case, both were necessary for making things as catastrophic as they were.

A couple days ago, it was announced that 130 million Adobe account credentials were compromised by a cyberattack. (If you are an Adobe customer, please make sure you’ve changed your password on any account that shared the same password.) There’s been a file circulating around the Internet that contains the email address, encrypted password, and unencrypted password hint for all these accounts. It’s not too hard to find.

The first interesting thing we learned from this file is that Adobe didn’t salt and hash their passwords before storing. Instead, they used a well-known symmetric encryption algorithm (3DES, ECB-mode) with the same secret key for every account. Even without knowing the secret key, it’s not hard to recover plaintext passwords with high confidence using basic statistics. Simple example: The encrypted password that appears most often in the dataset is probably going to decipher to “123456” or “password”. For this particular dataset, knowing that alone gives you the password for 2+ million accounts. (I’ll explain how you can avoid statistical attacks like this one by salting/hashing in a footnote below.)

The other interesting part is the password hints. A staggering number of people have password hints that are literally, “pwd is 123456”, which helps confirm some of the password guesses that we can make by statistical analysis. My friend Nick Semenkovich posted a sanitized version of the full user dataset (.gz, 1.1G) with emails redacted, which I filtered into a much shorter list of 8262 lines-that-might-contain-the-actual-plaintext-password using grep -Ei ‘\s+(password|pwd?)\s*(is|==?|:)’.

If you take a look at the list, you’ll see an astonishing number of password hints that either seem to give the actual password or say something like, “Password is the same as for Gmail.” The latter is especially bad because if your password is fairly common, I can probably figure it out from statistical analysis and then login to your email account.

Essentially, this is a situation where if EITHER Adobe engineers implemented secure password and password hint obfuscation OR every Adobe user created perfectly random passwords and secure password hints (== probably no hint at all), things would be mostly okay despite the database breach.

I don’t want to be presumptuous about why Adobe didn’t follow recommended password storage protocols, but it seems that the twofold lesson here is that engineers need to have a realistic user model and users need to have less trust in engineers to protect them.

====

A quick primer on salting and hashing passwords:

Hashing for password storage is a pretty magical thing. Unlike encryption (which is an invertible function once you have the secret key), usually the only way to get the input to a secure hash function (aka: the user password) from the output (aka: the password ciphertext) is to brute-force. Hash functions are at least half-magical because similar inputs get mapped to completely different outputs except by coincidence.

If all the users of your website had completely random passwords all the time, you could feel free to post the hashes of their passwords publicly as long as you trusted the hash function, because there’s no easy way to undo a secure hashing process. Something like bcrypt or scrypt with a high work factor.

The problem is that humans tend to reuse strings exactly for passwords, so if we get a database dump we can do statistical deductions and grab the nearest table of precomputed hashes for common strings. So we need adjust our user model from “people who make perfectly random passwords” to “people who might just use ‘password’.”

Then the solution is pretty simple: we just generate a random string for each user when they make their password (a “salt”) and append/prepend the salt to their password before hashing. We have to store the salt in our database alongside each user’s salted-hashed password, but that’s fine because it reveals no information about the plaintext password.

Note that you should never use the same salt for multiple users; otherwise you end up in basically the same situation as Adobe when someone gets your password database dump.

Thoughts on Cypherpunks 2.0

Sun, 13 Oct 2013 00:00:00 UTC

This is a post about fear. It’s easy to write about things that everyone says they are afraid of, but less so about nightmares that you suspect might just be your own. The latter is much more distressing and also easier to push out of the way. I’ll try to elaborate on something that has been in the back of my mind.

Last night, I went to a talk by my friend Andy titled, “Cypherpunks 2.0.” Andy thinks that there’s been two major waves of activity in the cypherpunk movement: the one that peaked in the 90s and put technologies like PGP, SSL, OTR, and Tor in the hands of ordinary people (at least in the U.S.); and the one that started this summer in response to the Snowden leaks.

Andy is hopeful. He points out that Cypherpunks 2.0 has dozens of active crypto and techno-activism mailing lists, as well as IRL meetups like Techno-Activism Third Mondays, CCC, and Cryptoparty. On the technology front, we’re watching projects like Tahoe-LAFS, CryptoCat, Whonix, and Tails become what John Gilmore referred to as the physics and mathematics that guarantees a fair society when legal systems are insufficient (as they typically are).

There was a slide in Andy’s talk that really stuck with everyone in the audience. It read:

[Cypherpunks 1.0] “Look at this utopia we can build, using cryptography!”

[Cypherpunks 2.0] “Look at this dystopia we have built, using cryptography!”

And yes, Cypherpunks 2.0 feels less like a revolution for utopia through free cryptography and more like an arms race against Orwellian governments that fundamentally disagree with us on whether privacy is a human right. Cypherpunks today don’t talk about winning, for the most part. We talk about staying above water. We say that the best we can do is to make mass surveillance both illegal and extremely difficult through maximal use of end-to-end encryption. We’re doing the best we can to prevent and protect people from the hells of targeted surveillance if they are ever so unlucky, but it’s hard to make promises when you don’t know if your adversary model is close to realistic.

Last night, I realized that every article I had read about the Snowden leaks either implicitly or explicitly suggested that we should be afraid, because the Orwellian dystopia is already here. Everyone is being watched all the time. Our crypto abilities are decades behind those of the government. Free societies cannot exist in such a state. Etc.

None of the above distresses me, though. Those of us who identify as cypherpunks or simply people who dislike surveillance are in a better spot than before. Every week, we learn a bit more about how government surveillance works, and we adjust our tactics accordingly. Pull, push, merge.

The part that I am truly, deeply, unapologetically terrified of is that we’ll step away from our laptops, take a look at American society as a whole, and find that almost nobody cares.

I’ve had this fear in some form or another for a decade. In 2006, I was 15, rather cynical, and planning to drop out of public school in inner-city Saint Louis. I wanted generational identity instead of Facebook wall posts, protests instead of biweekly third-period Home Economics. There was nothing I despised more than apathy.

That year, I purchased the first book I ever bought for myself. It was Amusing Ourselves to Death, an ever-relevant work of nonfiction written by Neil Postman in 1985. The foreword has a stunningly prophetic passage that, like a boomerang, swings out of the far blue distance and dares us to duck fast:

. . . we had forgotten that alongside Orwell’s dark vision, there was another- slightly older, slightly less well known, equally chilling: Aldous Huxley’s “Brave New World.” Contrary to common belief even among the educated, Huxley and Orwell did not prophesy the same thing. Orwell warns that we will be overcome by an externally imposed oppression. But in Huxley’s vision, no Big Brother is required to deprive people of their autonomy, maturity and history. As he saw it, people will come to love their oppression, to adore the technologies that undo their capacities to think.

Postman, in painful detail, considered the possibility that Huxley, not Orwell, was right. Nonetheless, nobody really wants to talk about Huxley. Orwellian surveillance is, in a certain light, a sexy thing to fight against. The apathy of the average person who spends 4 hours per day watching reality TV is not. For most of us, it’s much more fun to hack on Tor than to explain to a grocery store cashier why they should support free software projects that are far less usable than Dropbox.

My fear is that outside of the technological elite, convenience will perpetually win over privacy. I’m afraid that if staying alive in the war against surveillance relies on winning the war against apathy, Cypherpunks 2.0 is moving forward in the wrong direction.

Memphis Haiku Collection

Sat, 12 Oct 2013 00:00:00 UTC

Tonight I found a collection of stupendously precocious (lolol) poems I wrote on a trip to Memphis at age 13. Here they are, untouched, in all their prematurely cynical glory:

I’m going to Hell

I mean Memphis, in two hours

Do not raid my house.

If I don’t return

Do not mope like Charlie Brown

You’re not in my will.

I gave my pet bird

To some short college student

With lots of birdseed.

My root beer is flat

I must have left it too long

Is this relevant?

We are carpooling

With some friend of my father’s

Hope he pays for gas.

Going to find Elvis

Because Lauren told me to

Even though he’s dead.

Auditorium

The word has five sylables

I didn’t spell that right.

The smoky mountains

Because only you can stop

Those big forest fires.

At Holiday Inn

They give you little bottles

Of lousy shampoo.

Someone tell Kathy

Of the YMCA band

I can’t audition.

Chinese food is good

Especially the sushi

Wait, that’s Japanese.

They had a nurse shark

But everyone thought it was a

Mutant catfish.

Sushi bars are good

And so is the free soy sauce there

I spilled a bottle.

Graceland was real big

But the tour guides were real dumb

That’s why I got lost.

I did meet Elvis

He was at his old garden

Deep under the ground.

His airplane’s inside

Was covered in plastic wrap

Must have been itchy.

He had many suits

All colors, jeweled and sequined

Now worn by dummies.

The gift shop was cool

A nice place to be until

You saw the price tags.

I bought a milk-shake

It had lots of iced vanilla

My brain is frozen.

The hotel forgets

To give me a bed at night.

Now that is stupid.

I’d better go now

It’s been great writing these, but

The Simpsons is on.

Tabstash: OneTab for Firefox

Wed, 02 Oct 2013 00:00:00 UTC

I wrote a Firefox addon one afternoon in France called TabStash. It’s quite simple: you click a button to close all your tabs except the current one. You click it again to open all of them. (Chrome has a popular extension called OneTab that does this, but at the time there wasn’t a Firefox version.)

A couple nights ago, I finally got around to sending it to the Mozilla addon store. It came out yesterday and already has some downloads, to my surprise.

Anyway, you can find it at https://addons.mozilla.org/en-US/firefox/addon/tabstash/.

On artificially-bounded futures

Tue, 01 Oct 2013 00:00:00 UTC

I flew back to MIT recently for the GNU 30th Anniversary Celebration and Hackathon, thanks to a generous travel scholarship from the Free Software Foundation. All I had to do was never, ever run any proprietary javascript in my browser and something something something about firstborns. Seemed like a net win.

The hackathon itself was fun. I spent most of it teaching people about privacy-enhancing tools like GnuPG and realizing that privacy-enhancing tools are intimidating, even to MIT computer science PhD students. Bad user interfaces are astonishingly powerful, and nothing cripples the human spirit like a poorly-written manpage.

I also gave a short talk to about ~30 undergrads titled, “Things you should be afraid of that you probably didn’t know about.” The alternate title was, “Useful self-preservation tactics in surveillance states.” The alternate alternate title was, “On the possibility of preserving student culture at MIT.” I admit I was trying to get more people to show up on a Friday night.

The problem was that, after an unexpected adventure in NYC the day before followed by an untimely laptop battery failure, I had barely twenty minutes to prep for the talk. So I went for a short run around the Charles River and formulated some thoughts. They went something like:

Surveillance is bad. Do MIT undergrads care? Or are they still trying to implement metacircular evaluators in Scheme?
DO NOT LET PEOPLE GIVE INTO CRYPTO-NIHILISM. Show them that we can only fight what we know.
Privacy, if it actually exists, must belong to a community. Privacy that belongs to individuals is necessary but not sufficient.
Ethical choices are painful and often ambiguous. Say you’re the CEO of a company that makes a groundbreaking app that reduces vehicle emissions by 90% in the US. In order to do so, you need to collect data on where everyone’s cars are located at all times. Then one day the government puts you in a position where your choices are to either (secretly) give them years and years of private user data or let the company shut down (and lose all your money). What do you do?
Imagine if the MIT administration wiretapped all student communications on the Internet and forced every mailing list to contain an administrator. Imagine the student response. Now imagine the same situation at the national scale. This is a useful exercise to brainstorm realistic ways of fighting problems that seem too large and abstract for us to think about at first (ex: mass unchecked government surveillance).

To my surprise, the talk went over rather well. People asked lots of excellent questions, like what kind of tinfoil hat to buy. Phew.

Another thing that has come up a lot on this trip is the idea of having a career. As much as I feel uncomfortable about it sometimes, I can’t help but admit that the topic of What To Do In Life has been on my mind lately. The annual MIT Career Fair was a week ago, a bizarre anti-celebratory festival during the first week of classes where hundreds of companies try to recruit students by giving them free Rubix cubes. This year, one courageous sophomore wrote an opinion article in the school newspaper about how the Career Fair is useless for inspiring faith in the student population’s ability to give a fuck about problems other than making cool-but-also-profitable technology and making hella cash.

Obviously this is a thorny issue wrapped in questions of whether the author has properly normalized for her own privilege (she probably has) and if large tech companies like FB/Apple/Google are already doing the maximal amount of good for humanity that they can while remaining profitable (they probably aren’t), BUT it was still surprising that most critical comments essentially said: “Stop looking down on other people / some of us need to make a living / not all corporations are completely evil.” Multiple commenters accused the author of “entitlement”, which seems like a ridiculous term to cast as an insult (aren’t we all entitled to pursuit of happiness?).

Disliking the percentage of commenters who were unfairly bashing on the author, I wrote an uncharacteristically optimistic comment for someone who doesn’t have a consistent job:

This post was entirely justified and necessary. (Minus the fact that Quizlet probably doesn’t deserve to be on that list, as RJ pointed out.)

A number of the criticizing comments here have argued that companies like Apple and Facebook, on their way to making massive profits, ultimately spawn technologies that do good for the world; furthermore, even MIT students need to support themselves day-to-day regardless of their greater goals. But I think a salient counter-argument is that MIT grads can and absolutely must hold themselves to a higher standard than what these companies represent.

What I am implicitly saying is that (1) there are greater problems that humanity faces than how to get people to trigger certain javascript callbacks that generate ad revenue, and (2) people with the intellect and stamina to lead technological revolutions have a near-moral responsibility to solve these greater problems. The fact is that most MIT graduates can find a job and figure out a way to support themselves in most circumstances, which means they have a rare privilege among young people: the ability to take on great risks and be okay if they fail.

In practice, a dismayingly small percentage of MIT graduates use this privilege for tackling the hardest and most valuable problems of our generation. Climate change is a fine example, given that the lower limit of the time it’ll take for atmospheric methane to collapse the global economy is on the order of decades.

Even those of us who work as software engineers and tech CEO’s usually fail to address the question of whether we are making technology for a world where knowledge is free and accessible to everyone, or a world where governments and corporations can freely intrude on the private communications of every single person. Too often, we generate technology that is groundbreaking and astonishing without conscientiously addressing their potential to destroy civil liberties and strip away basic human rights. We can and must exert more pull over the ethical consequences of our innovation.

It is absolutely our moral responsibility to try to make the world we want to live in.

I really hope I didn’t make all of that up.

Some thoughts on the NSA and elliptic curve cryptography

Fri, 13 Sep 2013 00:00:00 UTC

Below is an amalgamation of some posts that I made recently on a popular microblogging platform:

========

I’ve been reading a lot today about what I believe is a super-likely NSA backdoor into modern cryptosystems.

There are these things called elliptic curves that are getting used more and more for key generation in cryptography, especially in forward-secrecy-enabled SSL (which is the EFF-recommended way to secure web traffic). The problem is that the choice of parameters for the elliptic curves most used in practice are set by NIST, and we know for sure that the NSA has some influence on NIST standards.

In 2006, NIST published an algorithm for elliptic-curve based random number generation that was shown to be easily breakable but ONLY by whoever chose the elliptic curve parameters. Luckily this algorithm was crazy slow so nobody used it, even though it was the (only?) NIST-recommended way of generating random bits with elliptic curves.

But it turns out there are some relatively-obscure papers that suggest that you can gain a decent cryptographic advantage by picking the elliptic curve parameters! [Edit: It was later pointed out to me that this particular attack is not close to anything the NSA could be doing right now, for various reasons. It is of course unclear whether they have knowledge of other elliptic curve parameter-based attacks that are not in the academic literature.]

This is terrifying, because the elliptic curve parameters chosen for relatively-mysterious reasons by NIST (probably via NSA) are used by Google, OpenSSL, and any RFC-compliant implementation of elliptic curves in OpenPGP (gnupg-ecc, for instance).

==========

Some people might be wondering if they can trust companies who issue statements that their closed-source software products don’t contain NSA backdoors (Microsoft, Google, Apple, etc.). Here is an example of why not.

It has been known since 2006 that Dual EC DRBG (a NIST-standardized random bit generation algorithm) has a major vulnerability that makes no sense except as an NSA backdoor. Essentially, the algorithm contains some constant parameters that are left unexplained; some researchers then showed that whoever determined these parameters could easily predict the output of the algorithm if they had access to a special set of secret numbers (analogous to an RSA private key). This is a beautiful design for a crytographic backdoor, because the secret numbers are difficult to find except by the person who set the constant parameters in the algorithm.

Despite being slower than other random bit generators, Dual EC DRBG is implemented in a bunch of software products by major companies like RSA Security, Microsoft, Cisco, BlackBerry, McAfee, Certicom, and Samsung. For a full list, see: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html

Most of these products are closed-source, so you can’t check whether your encryption keys are being generated with Dual EC DRBG.

This is a pretty strong argument that secure software is necessarily open source software.

========

Additional citations:

Bruce Schneier on the 2006 backdoor discovery in Dual_EC_DRBG: https://www.schneier.com/…/2007/11/the_strange_sto.html

Google’s blog post announcing SSL w/ forward secrecy, specifically mentioning that they use the P-256 curve: https://www.imperialviolet.org/2011/11/22/forwardsecret.html

Wiki section on NIST-recommended curves: https://en.wikipedia.org/wiki/Elliptic_curve_cryptography…

RFC section stating that P-256 is REQUIRED for ecc in openpgp: http://tools.ietf.org/html/rfc6637#section-12.1

Description of elliptic curve usage in OpenSSL: http://wiki.openssl.org/…/Elliptic_Curve_Cryptography

Presentation on security dangers of NIST curves: http://cr.yp.to/…/slides-dan+tanja-20130531-4×3.pdf

NSA page recommending you use elliptic curves lol: http://www.nsa.gov/business/programs/elliptic_curve.shtml

========

UPDATE (9/23/13): RSA security has issued an advisory to stop using some of their products where DUAL_EC_DRBG is the default random number generator (http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/). Matthew Green also made an excellent blog post about this topic over at http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html.

Some favorite git commands

Mon, 02 Sep 2013 00:00:00 UTC

Working on HTTPS Everywhere, an open source project with dozens of contributors, has sharpened my git vocabulary immensely. I figured I’d list a few lesser-known commands that I like:

git log _-pretty=oneline -n –abbrev-commit -G_: This shows the latest commits in oneline format with shortened commit hashes that added or removed lines matching . The git pickaxe options (-S, -G) are super useful for searching git commit contents instead of just the commit messages.
git checkout <path/to/file>; git reset; git add -p; git commit: This is almost always less preferable to git cherry-pick, but it is useful when you want only certain hunks of commits to certain files in . git checkout copies the file from the other branch into the current branch and stages the changes for commit. git reset unstages them so we can select the parts we want to add to our branch on a hunk-by-hunk basis using git add -p. Unfortunately this doesn’t preserve authorship of the changes from .
git update hooks: We decided that it would be great if the HTTPS Everywhere git server could automatically reject commits that broke the build. It turns out that this is possible using a server-side git update hook, which runs just before updating the refs on the git server. The strategy is to create a temporary copy of the remote with the newly pushed changes, do a test build, and reject the changes if the build fails. See here for an example of this in HTTPS Everywhere adapted from a Stack Overflow answer.

More to come!

HTTPS Everywhere 3.3 is out!

Sat, 27 Jul 2013 00:00:00 UTC

Quick update to mention that a new version of the browser extension I’ve been helping with this summer has just been released!

This release was spurred by the impending arrival of Firefox 23, which notably has Mixed Active Content Blocking enabled by default. In summary, this means that scripts loaded via HTTP on an otherwise-HTTPS site will be blocked automatically for security reasons. Although this is good news in general, it would have suddenly caused HTTPS Everywhere to become way less usable.

Micah at the EFF did tons of work on this one to make sure that mixed content rules in HTTPS Everywhere wouldn’t break a massive number of websites for FF23 users, while I implemented the UI to alert users to the fact that they would have to re-input any custom preferences once they updated to 3.3 (unfortunately). I also ended up fixing a previously-undiscovered bug along the way that prevented the HTTPS Everywhere tool-tip from showing up when users install the extension.

It’s kind of sad that the tool-tip didn’t show up for most people before. Did you know that you can disable HTTPS Everywhere rules by clicking on the toolbar icon? This is very handy when certain rules cause a site to break for some reason.

Anyway, happy upgrading!

Qu’est-ce que le Fuck?

Sat, 20 Jul 2013 00:00:00 UTC

This morning, I found myself running down the middle of an empty highway in rural France at 5 AM. A litany of WTF’s rang through my head.

The sun rose, gently, turning attention to row upon row of freshly-cut crops stretching exorbitantly toward the horizon. Beyond softly rolling hills in the distance, there was the faint quilted pattern of a tiny village, cows and baguettes and all. Except for the thin ribbon of a two-lane highway, it was vague what century this place haunted.

I remember hypothesizing here a month ago, in the car-loathing aftermath of backseating several thousand miles around the US, that I was finally done with travelling for a while. I had just arrived back in San Francisco, unpacked my backpack, fixed my bike, and started interning at the EFF.

A week later, realizing that I could work remotely and that there were better places for human existence than 2 blocks from Market Avenue, I bought a plane ticket for Europe. I had hatched some sort of hazy half-plan to ditch the life I had constructed in SF and backpack around a continent that I had never visited, full of languages I couldn’t speak, until my visa ran out in 3 months’ time. I would carry as little as possible, find like-minded hacker-type people to stay with, and spend most of my time writing code for the EFF, undeterred by distractions like understanding what other people were saying to me. Plus, since I wasn’t paying San Francisco cost-of-living prices and sold my Burning Man ticket, I would probably save money overall. Nothing could go wrong.

After sleeping through the entirety of the flight from SF to Paris while cradling a Kindle that I had intended to use, I unloaded myself into a subway at CDG, got off in the 6-euro-couscous-vendor district, and promptly reached the apartment of a Paris-dwelling ex-housemate who I barely saw the entire time. My impression of Paris from 2 days of aimless wandering is of a city whose historical and cultural significance is completely blighted by the lack of any usable WiFi except at McDonalds. I did not like Paris or find it fit for habitation, needless to say.

Fortunately I was rescued by a group of old friends, who invited me to stay and work with them in (1) a former convent turned into (2) an artist co-op / workspace owned by (3) a man with a pet peacock in (4) a tiny rural town in northern France. Several times a day, I will remember each of these four things in turn and suddenly feel like I’m dreaming.

This is my room:

And this is the view:

The night I arrived, we grilled meat and vegetables in the garden, with wine and baguettes aplenty.

The peacock made a cameo.

I took a wander around the convent and basked in its eccentricities.

I started settling into a routine after a couple days. It goes something like:

5 AM: Wake up

5:30 AM: Go for a run as the sun rises.

6:30 AM: Breakfast, shower, etc.

7 AM: Start work.

3 PM: Go to bed.

7 PM: Wake up, eat lots of baguette, start work again.

10 PM: Cook and eat dinner with friends.

11 PM: Try to work, mostly end up emailing/IRCing with people in the US who are now awake.

2 AM: Go to bed #2.

This is almost ideal, except that the only grocery store in town is 40 minutes away by foot and closed whenever I’m awake and not work-binging.

I like it here a lot. It’s quiet. There aren’t many people to talk to, since my friends are busy hacking away on a P2P video-sharing project all the time. I get to read a lot. Javascript has become fun – oh wait, maybe I have Stockholm Syndrome.

Summertime, and the HTTP traffic sniffing is easy

Fri, 05 Jul 2013 00:00:00 UTC

So it happens that every time you access a URL that starts with “http://”, anyone on your local network can see what you’re doing with almost no effort worth writing about. This includes the page itself as well as any information that you’re transferring, like credit card numbers and passwords (which are hopefully encrypted). It’s worth reiterating that this isn’t difficult at all, even if your network is WPA2-protected, as most supposedly-secure WiFi networks are nowadays.

This sounds like quite a displeasing predicament for those of us who find ourselves using shared wireless networks every day (aka, all of us), but I get the impression that most Internet-users don’t understand exactly how simple it is to casually sniff HTTP traffic. So, in hopes of convincing you that it *is* in fact simpler than using any OS X package manager successfully, here is the absolute fastest, easiest way I found to reliably eavesdrop on HTTP traffic on most local networks. It should take less than 5 minutes to set up on your Linux thing (maybe also your Mac thing, but I haven’t tried) and is straightforward to understand.

(This is intended for education purposes, and also for encouraging more people to use HTTPS instead of HTTP whenever possible, maybe even via the browser extension that I’m contributing to this summer. More on that in a bit.)

Run the following to install some packages that we need. dsniff is a collection of various traffic analysis tools, of which we’ll only use arpspoof; see here. tshark is a nice terminal-based packet analyzer; tcpdump also works.

apt-get install dsniff
apt-get install tshark

Turn your machine into ip-forwarding mode as root by flipping a 0 to a 1, or else people on your network won’t be able to see their websites. Don’t do this step if you actually want to launch a denial of service attack, I suppose. Also you might want to remember to turn it back to 0 after you’re done.

echo “1” > /proc/sys/net/ipv4/ip_forward

Run the following commands as root on a WiFi network. To find your IP address, you can run ifconfig and look for the wlan0__ inet addr. To find your router’s IP address, you can do something like run traceroute google.com and pull out the IP address from the first hop, which is likely to be 192.168.x.x.

arpspoof -i [your IP address] [the router IP address]
tshark -p port 80 -i wlan0 -T fields -e http.request.method -e http.request.full_uri -e http.user_agent

And voila, the second command spews out a stream of HTTP addresses that people on your network are accessing, along with the request method and the type of client software used. This is just the start; you can read the manpage for tshark to figure out how to pull more detailed info from the packets and then start writing scripts to modify them before forwarding them along. Ex: appending -e text will show HTML data as text from the webpages.

What we’ve done so far is:

Perform a attack called ARP spoofing on the router. Essentially, we trick everyone on the network into thinking that your computer is the router so that all the traffic intended for the router goes to your computer instead. This is straightforward since ARP doesn’t include authentication mechanisms.
Use tshark to extract interesting information from the packets that we’ve intercepted.
Forward these packets along to their intended destination so nobody detects our spying.

While sniffing packets as they floated by on a warm summer night in the attic of a Berkeley farmhouse in the process of testing this out, I could see which HTTP websites my housemates were accessing, what apps they were using on their phones, and what desktop clients they were running without them ever noticing. With a small amount of additional effort and a large amount of additional malice, I could have manipulated their traffic to interchange the titles of Wikipedia articles or whatever else I wanted, the possibilities bounded only by my imagination / knowledge of regular expressions.

[Note that although WPA2 encrypts data that goes between the router and devices on the network, this clearly doesn’t prevent eavesdropping via arpspoof by other devices that have access to the network. Stack Exchange explains that by operating at a layer above that at which WPA encryption occurs, an arpspoof attack causes the data to instead be encrypted for the attacker’s device instead of the router.]

Sadface time. On the other hand, none of the above works if you’re using HTTPS, where the S stands for “secure,” because in that case traffic is encrypted between you and the server you’re trying to reach. On the other other hand, outgoing HTTPS requests from your device can still be subtly converted to insecure HTTP via an attack called SSLstrip that makes use of arpspoof if you try to reach an HTTPS site by redirecting from HTTP. On the other other other hand, you can download the EFF’s HTTPS Everywhere extension for Chrome/Firefox, which rewrites HTTP URLs to HTTPS before you try to connect to the HTTP site. On the (other)*4 hand, there’s some problems with SSL in practice because of intermediate certificate validation carelessness and so forth. I’m now out of hands.

Some thoughts on Facebook implementing forward secrecy

Thu, 04 Jul 2013 00:00:00 UTC

Last month, CNET announced that Facebook is working on implementing a property called forward secrecy in its encryption of user data. The article is pretty long, but the gist of it is:

Forward secrecy is good news, at least theoretically. Right now, when you send data to Facebook’s servers, your data gets encrypted so that someone who intercepts your data can’t read it unless they have Facebook’s secret key. However, if an eavesdropper is recording your messages now and somehow gets the secret key in the future, they can go back and decrypt all your encrypted communications. Forward secrecy in an encryption protocol, by definition, means that if the secret key is compromised, your communications are still safe from decryption.
Google is the only major web service that has forward secrecy in its encryption protocol enabled by default. Most services don’t do this because it’s computationally expensive.
The leaked slides about the NSA surveillance program, PRISM, suggest that the NSA is tapping into Internet connections and collecting data in transit between your computer and Facebook’s servers, or at least that this is possible.
Once your data is collected by the NSA, it can probably just sit around forever. That gives plenty of time for Facebook’s secret keys to be brute-forced or obtained by the NSA through a court order. Without perfect secrecy, all your data can be decrypted once this happens.

So in other words, Facebook is implementing an extra security measure to protect data in transit from users to their servers, and this announcement comes at an opportune time in light of the PRISM revelations in early July.

But data in transit isn’t the only kind of data that needs to be protected! What about data at rest?

To clarify what I mean here, let’s think about the flow of data from you to your friends when you make a FB post. This is simplified, but it goes something like:

You type a message in a text box in your web browser and hit send.
Your browser encrypts that message before it leaves your computer and goes on its way to a Facebook server.
Your message travels over the Internet in encrypted form.
Your message reaches a Facebook server, which decrypts the message and stores it in a database so that it can be retrieved later to be shown on your profile, in your friends’ news feeds, in searches, and so forth.

In Steps 3 and 4, your data goes from in transit to at rest. Here’s a handy diagram from Wikipedia that distinguishes the three states of data, which I’m simplifying into two by merging “data at rest” and “data in use”:

Three states of data.

Nowadays, it’s expected for major web services to encrypt all data in transit by default using HTTPS, which uses the SSL/TLS cryptographic protocols. This is generally done by using a persistent private server key for both authentication (verifying the server’s identity) and encryption (encoding the data so that only the server can read it). This does not provide forward secrecy, and all encrypted messages are compromised once the persistent server key is found.

Facebook’s announcement, which follows one by Google in 2011, reflects a recent shift toward supporting forward secrecy by generating ephemeral Diffie Hellman keys for encryption during each session. A persistent RSA key is still used to authenticate the server. The ephemeral keys used for encryption, however, are not stored beyond a session. Thus, even if the persistent key is compromised, data that has been obtained through eavesdropping on an Internet connection is still safe from decryption.

However, recall that in Step 4 above, Facebook decrypts your data and stores it in a database, presumably one that is password-protected or has some other security measure that lets a trusted set of people access it (database admins, for instance). At this point, your data is just sitting around in decrypted form, protected by whatever-FB-does-to-protect-its-servers. It would be impractical to do otherwise because performing encrypted query operations efficiently is hard maths, and basically the definition of a web app is something that stores data and performs interesting/useful queries.

With Facebook’s announcement of support for forward secrecy in TLS/SSL, we’ve been assured of increased attention to security for data in transit, but this of course says nothing about data at rest. Indeed, it seems that the NSA surveillance leaks have sparked relatively little discussion of policies at companies like Facebook for securing data at rest. That’s surprising to me, because the oft-spoken phrase “NSA back door” vividly suggests that the NSA is in the trusted set of people who have access to the decrypted data in servers at FB, Google, and so forth.

To be clear, forward secrecy is effective against a particular adversary model, namely wiretapping. Although the CNET article points out that the NSA is probably doing a bunch of wiretapping these days and has agreements with Internet service providers to facilitate such, I assume it’s still easy for the NSA to walk up to someone at Facebook and demand access to the database. In fact, regardless of how secure data is while in transit, it basically always needs to get decrypted on the server side in order to be useful for a web service. As long as it’s easy for the web service to access the decrypted data, it’s easy for the NSA to do so as well*.

*Barring policy changes that would legally prevent surveillance. Even so . . .

In short, there probably exists no NSA-proof cryptographic protocol for securing data at rest so long as companies agree to comply with gov-authorized surveillance programs. Forward secrecy doesn’t seem like much of a deterrent to PRISM in that case.

But in terms of protecting our privacy from attackers who aren’t government spying agencies, the security of data at rest matters as much as, if not more than, security for data in transit. Unfortunately, whereas TLS/SSL is an established and widely-used standard for encrypting data in transit (albeit flawed in practice), procedures for securing data at rest seem to vary widely between companies (see Appendix A). These procedures are often described in vague terms if at all. For instance, one service simply states that it “provides multiple layers of security around your information, from access protected data centers, through network and application level security . . . Sensitive information, such as your email, messages and passwords, is always encrypted.” The methods of encryption, whether they are applied in transit or at rest, and other important details related to the security of the service are left out.

It’s hard to blame the product description writers for omitting these crucial details, because most users simply don’t care as long as they feel reasonably secure. It’s easy to feel secure with assurances like the ones quoted above, and news articles about implementations of forward secrecy in the works at FB. And then you get things like Twitter sending passwords in unencrypted form or Apple failing to properly authenticate SSL certificates or a whole Tumblr blog of websites that store and send passwords in plaintext, oops. There’s a difference between feeling secure and actually being secure on the web, clearly, but paranoia is tiring and you should probably go check on the 12 Facebook notifications that you got while reading this blog post.

===========

Appendix A: A Brief, Non-Representative Survey of Company Policies for Securing Data at Rest

In the course of researching this blog post, I made a post on a certain social media site asking my friends in tech about how their companies secured non-sensitive data at rest, where non-sensitive data includes user-to-user communications and metadata (but not passwords, SSNs, and financial data). The few answers I got were more sophisticated than, “In plaintext, on a password-protected database,” but I suspect there’s some selection bias here. Anonymized responses below.

___

I’ve worked with so many apps, and it’s almost always a database behind a firewall. I’ve occasionally built systems where financial data was stored in some more secure way: one, where financial data and transaction processing happened on a separate box with no services and a very minimal API (to limit exposure), and where it was impossible to retrieve the sensitive information via the API.

The other one actually encrypted data using a key that was secured with the user’s password. It was re-encrypted using the user’s session on login, so the cleartext was only available when the user was logged in, during a request from that specific client. In this way, sensitive information was protected from our staff, and from an attacker, except that anyone who was actively using the system would be exposed (to a reasonably sophisticated attacker).

None of these ideas provide protection from a government, though. Client-side encryption doesn’t really, either. Just look at what happened to Hushmail. I really want there to be some trustable encryption API in the browser, so that client-side encryption for web apps could be a real thing.

___

We actually encrypt (with a separately stored per-user key) all of our user message content. It makes me way way more comfortable debugging problems that come up in production knowing I’m not going to accidentally read a message that was meant for a friend or co-worker. It’s pretty low-effort and low-resource-intensity for us to do this so it seems silly not to.

I guess the tradeoff is that for somebody like Facebook they’d lose the ability to do queries in aggregate to make advertising or similar decisions based on content.

. . . the keys [for encrypting messages] are stored with symmetric encryption. It defends us against outside attackers getting use out of dumps of our database but in theory with access to the layer that gets the messages and has the keys the encryption doesn’t matter. The practical limit when we’ve looked at doing more is one where as long as our site can display your messages then there’s some set of our infrastructure an attacker could use to read those.

___

We use client-side encryption with client-generated keys for user history/bookmarks/passwords, etc. So adding a device to access said data involves JPAKE (key exchange) via our servers (which are treated as an untrusted 3rd party).

This means syncing is hard, but we associate each record with a record ID and sync them if the hash changes.

For telemetry, we use anonymized data – uploads are linked to a UUID that only the client stores locally.

Marfa, TX

Mon, 10 Jun 2013 00:00:00 UTC

Large American cities breed complacency. We grow up in the suburbs, we move to the cities after college, we get jobs and buy apartments and curate routines. We find comfort in the monoculture of coffeeshops, the ubiquity of free wifi and indie periodicals. College students flip through biology textbooks, their thumbs skimming over blue-framed iPhone screens.

The small town of Marfa, Texas subverts urban complacency. The streets are hot, desolate, effortlessly dusty. Buildings arranged sparse like haiku lines. A lone gas station on the corner offers only two varieties of bottled water.

Upon closer inspection, a startling fraction of the blank-faced single-story buildings in Marfa reveal themselves to be contemporary art museums.

At night, the heat departs the sidewalks reluctantly like rising angels on their way to the dentist. Warm lamplight floods the streets, supplanting the blues and purples of a late desert sunset. We walk to a bar down the block, where a high school graduation party is underway. The high schooler is nowhere to be found, but his family members run plentiful. 2-4 middle-aged couples dance the macarena as the DJ shuffles windows around on a laptop.

At 11:20 pm, an old man hands us beers and drives us down a dark lonely highway in an obnoxiously loud bus. He herds us out into a field of moonlit grass rife with ant hills. As we shiver in the stiff breeze, he points into the distance at a pair of faint pulsing lights, orange and yellow, bobbing on the horizon. The Marfa Lights, he says. Nobody knows what they are, not even the scientists from Austin who came and studied them for months. Some say aliens; others say cars on the highway.

“What happens if you look at them through a telescope?”

“Well you see the same thing, only bigger.”

The next day, we are fed sweet French toast and taken to art. We walk from bungalow to bungalow, gazing. There are rows upon rows of aluminum blocks whose gleaming surfaces cast geometric deceptions, chaotic multicolored masses of twisted metal, rooms suffused in unearthly neon light, cartoonish paintings of tesselating women, and an abandoned Soviet schoolhouse left in disarray.

Marfa feels like an alien outpost in the morass of stereotypes that is America.

Goodbye, Cambridge!

Thu, 30 May 2013 00:00:00 UTC

Tonight, if I’m lucky, I’ll sleep on this soft green velvet couch where I spent 80% of my junior year of undergrad proving the existence of dark matter, determining the electron charge, reading papers on adiabatic quantum computation, and overfitting most things that I encountered. If I’m unlucky, I’ll stay up the whole night and hack away at some Python scripts testing a hypothesis I have about bitsquatting, or maybe I’ll jailbreak my new Kindle, but probably I’ll find myself brewing a kettle of tea and nostalgically gazing at the rain falling on the porch where I used to sit and read books in summer.

I’ve spent almost a month in Cambridge, MA, the first city that ever felt like a home to me. I arrived in 2008 for the first time with a couple bags of clothes and no concrete idea of how to use an electric dishwasher. I was put in a dorm room at MIT (Random Hall, to be precise) with huge windows and a sponged-on periwinkle paint job. People outside deep-fried oreos and broccoli. And then began the college move-in rituals: running down the street to the pharmacy to buy soap, laundry for the first time, canned soup, roommate reading Sylvia Plath, trying hard not to brush against the walls of the shower stall, purchasing textbooks for the first and last time.

Four years went by. I climbed roofs, wore scarves in winter, carefully checked proofs, and listened to people when they talked about feelings. My time ran out; I flew to San Francisco and lived in places not intended for human habitation. Sometimes I felt alone because nobody was around. At other times, I felt alone because I couldn’t establish a sincere connection to the people around me. The plans that I had made for the West Coast started to dissolve, and I realized at the age of 21 that there did exist something akin to a soul, in the strict sense of an identity capable of empathy. I fell out-of-practice with the ability to feel empathy for others. The idea of having close friends was appealing enough that I tricked myself into thinking that it was frequently realized, but in actuality I felt isolated from humankind much of the time.

This proved to be non-problematic until I woke up one day feeling like the future wasn’t going to be better than the past. This was one of the most precisely terrifying thoughts that I can remember having, precise in the sense that it is extremely well-defined and has immediate consequences for how one approaches life on a day-to-day basis.

I left San Francisco and was vague about the reasons to almost everyone who asked.

Almost miraculously, things got better in Cambridge. I spent time with an old friend with whom I’ve had a twin-like understanding in the past; in a glowingly inevitable moment, our identities seemingly merged into one. I went for long runs in the middle of the night. I sat in a church parking lot as the sun was setting, gluing spray-painted floppy disks to a friend’s car. Someone that I hadn’t talked to in years explained her dreams to me and then explained the structure of the human ear, which led to the discovery of a mind-blowing balancing trick. A friend from San Francisco visited, and we unexpectedly lost a couple days with each other coding and walking around the city and watching short films. I went to an outdoor arts festival in Delaware and kept a fire for friends wandering past in the middle of the night.

In a few hours, I’ll be on a plane headed to Austin, TX, where the start of a road trip awaits. Austin -> Marfa, TX -> White Sands -> Grand Canyon -> Joshua Tree -> LA -> Big Sur -> SF -> Seattle. And then back to SF.

I <3 Austin!

Thu, 30 May 2013 00:00:00 UTC

Vegan food everywhere! Taco bars with speedy wifi! Fresca margaritas! This is the American Dream INCARNATE.

Tomorrow I shall go explore the city and die of heat stroke.

gmailcheck

Fri, 24 May 2013 00:00:00 UTC

I’m just not that big a fan of usability, at least not for myself. To be clear, I do care about things being usable, but only enough to delay the eventual onslaught of social alienation. I drink water out of bowls, but only when the apartment is out of cups; I use xmonad as my window manager, but not at potlucks.

Thus far in my computer-using life, I’ve never owned a monitor. I don’t have a smartphone, so everything I do is on a pint-sized Thinkpad X220: writing, coding, ebook reading, garden-variety Internet browsing, photo/audio editing, bike trip navigation, sleeping, etc.

But recently, I was in the lovely town of Cambridge, MA on a warm spring day, staring out the window of a tired blue house at trees heavy with the impending procreation of innumerable songbirds, feathers washed in ecstatic glow of pollen. Mysterious stirrings of latent desire dripped from the stretched-out sky. Something changed inside me. Suddenly I felt like editing config files.

So I shut the window and did that for a while, maybe a couple hours or until I started showing symptoms of Vitamin D deficiency, don’t really remember.

At the end of this abortive config-puberty, I threw everything on Github because typing ‘git push’ releases a lot of dopamine in my body and apparently I like that.

The observant git tree-traveler will notice that there’s a Python script called gmailcheck in that repo. This is something I’m glad I wrote, because it solves a real problem without being overly complicated.

The problem is this: I spend most of my productive work time in the terminal, which is usually the master window in my tiling window setup. I usually also have a browser window open for Google searches. Using gmail, as it turns out, is hella dumb in a window of this size. Furthermore, checking gmail in the browser usually leads to an unending parade of distractions as I start to add events to my calendar, respond to some emails that can wait, click on links that friends have sent, open up Noisebridge-discuss threads with titles like “Who put mercury in the laser cutter? Also, kindergarteners visit TUESDAY,” etc.

On the other hand, not checking email at all is not an option, since my phone is usually useless, and anyone who needs to tell me something important is advised to do so over email.

Essentially, I needed something that would show me whether I had important emails in the terminal. Maybe like Mutt but with the removal of all features that could possibly lead to distractions.

Seems like a pretty simple Python script, and it was. Gmailcheck v1.0 will show you basic information about unread emails from the last hour, or whatever time you want to hard-code in for now. I added some extra bells and whistles, like hipster colors and highlighting of emails that gmail auto-labels “Important.” If you want to actually respond to an email or do other fancy stuff, you can click on the link and just go to gmail’s web interface.

Upon reaching this milestone, the next logical thought that occurred to me was, “How do you properly evoke the spirit of emails on the Noisebridge mailing lists?”

The answer is that you print them being said by a huge ASCII-art rendering of Tom, Noisebridge secretary and (before this happened) a friend of mine.

I guess I still don’t care about usability.

Two maps of SF crime data

Wed, 24 Apr 2013 00:00:00 UTC

In Jan. 2013, someone cut the brakes on my bike while it was locked up oustide Noisebridge and stole the handlebars. This was a major nuisance, since my ankle was sprained at the time and bicycling was my sole means of getting around the city.

It was also a hard time for other reasons. Two people that I cared about had passed away the previous week in unrelated incidents that caused a great deal of shock for those who knew them. In this context, seeing my bike forlorn and violently stripped on the sidewalk made me feel unsettled in a way that made me not want to try to fix it.

One of the few things that kept me going that week was organizing the Aaron Swartz Memorial Hackathon at Noisebridge and acting as the coordinator for a worldwide series of similar hackathons. The Noisebridge event itself went off better than anyone expected and was one of the happiest points of my previous year. I didn’t keep close tabs on the hackathons around the world, but it was heartwarming to receive enthusiastic emails from hackers from faraway places like Bangalore and Zagreb, discussing projects they wanted to work on at their local hackerspaces in memory of Aaron.

During the hackathon, I discovered SF’s online treasure trove of SFPD crime incident reports and other open data. I downloaded all the crime reports from the last 10 years and, for the heck of it, made a map of all the bike-related incidents.

View Larger Map

Lesson: don’t park your bike in SF, except for on Treasure Island, the Presidio, and this one weird patch near 15th and Folsom.

And here’s a map of all the prostitution-related incidents, because I had a hunch that this would produce clearer neighborhood boundaries.

View Larger Map

These would be more meaningful if they were heat maps or normalized by density, but you know, life is short.

why I left grad school

Sun, 20 Jan 2013 00:00:00 UTC

[originally posted to https://yan.jottit.com/ on 1/20/13]

Grad school was alright. I liked the people, I liked my research, and I liked the security of knowing exactly what I was going to be doing for the next 5-6 years.

Grad school in experimental physics was the easy choice for me. I had a hella fly academic track record, liked doing research, and reportedly got one of the two highest scores in experimental physics my year. I got into all the grad schools I applied to and lots of fellowship offers as well.

But what bothered me was that it was a convenient choice but not a fully deliberate one. It paid the bills, gave me health insurance, and allowed me to live near San Francisco while having a decent amount of free time. However, I was pretty sure I had zero interest in going into academia as a profession. So grad school was mostly a way to stall while figuring out what exactly I wanted to do with my life.

Then I got tired of stalling and not doing anything that felt productive in the meantime.

It got to the point where I finally decided to walk away from the NSF fellowship, the sunny apartment in suburban paradise, the guaranteed 6-year stipend, the free enrollment in Stanford classes, the health care, the gym access, and the prestige of getting a Physics PhD from Stanford in favor of being homeless, unemployed, and perpetually uncertain of tomorrow.

The last month or so has been full of stress, disappointment, and self-doubt, the pains of a transition to life without externally-imposed structure. There’s also been unexpected validation. It feels really, really good, almost glorious, to read a paper or teach yourself a new skill knowing that you aren’t doing it for any reason other than because it really deeply matters to you. I realized that too much time in my life thus far has been spent on tasks that I did in order to pass tests, get jobs, and prove myself to others.

As soon as I decided to leave Stanford, I had about 393849394 projects that I wanted to work on day and night. I wanted to brush up on a couple programming languages and learn several new ones, build a start-up, read up on anarchist theory, fix all the problems in the way scientists do science, take an online class in computer networks, facilitate open access to journals, help develop cryptographically secure tools for activists, promote social justice, start a warehouse living space, contribute to open source code repos, read papers on neural networks, blog about data science, and make tasty vegan food for friends. But I never could focus entirely on doing any of these things becaused I was too scared of not having a job for too long.

These days I alternate between feeling excited about doing these projects and feeling distracted/worried that I’ll never make a living at the same time.

This issue is unresolved as of this writing. Intellectually, I’ve convinced myself not to worry about getting a job for now (I can live reasonably for almost a year on savings, anyway) and focus instead on projects that’ll have a positive impact on the world. It bothers me that this isn’t a sustainable way of living, though, and I’d rather fix that sooner than later.

40 minutes in NYC

Sat, 24 Nov 2012 00:00:00 UTC

40 minutes in Tribeca on the way from Newtown to Boston

is all we have

before the parking meter runs out

so I transcribe the light of the setting sun in shorthand

(a cricket clutter of shutter clicks)

while you look for a bathroom.

the sun is running out

like a roll of toilet paper

waning into weary ribbons

as it soars toward heaven,

forgetful of the symmetries of the parabola,

the ache in the arms of your neighbor’s sycamore.

we leave with eight minutes to spare.

skeletons of metal and glass rip the skin of the sky,

autumn spread thick like marmalade

on this slice of highway.

the jar is running out

but the grocery store is closed.

87% of bathrooms in Tribeca are for employees only.

r*

Thu, 15 Nov 2012 00:00:00 UTC

do you suffer from depression

i want to ask but meanwhile

electronic trance pours a silky tea into our ears

steeped in the red that pervades this room

here we are in San Francisco on a bright night

two people alone with our insomnia

blooming like violent wildflowers and loose lightning

our mouths draw the shapes of dim perceptions washed from a broken flow of melatonin

you spread over the sheets, skinny as daylight in winter,

stare at me upside-down.

listen carefully

to me speak of depth perception

as you suck nitrous oxide into your lungs like grenade smoke.

later we lie next to each other, pointlessly,

coaxing sleep into the room with crumbs of prayer

perhaps i kneel at the threshold of consciousness

building churches out of slender touch, parsimonious and fragile.

for hours, you traced circles on my skin

composed in SFO airport while waiting for the redeye back to Boston

Mon, 09 Apr 2012 00:00:00 UTC

so I don’t know whether to turn around at your doorway

so hesitation drips the milk from sore eyes

so I scratch the walls

so I peel flakes of plaster

tumble like dead moths

erode my fingernails

which have grown long and desperate like homeless shadows

before the sun rises

we dimple red sheets under hard white ceilings

limbs curled into smiles

and then we are chasing each other

canyons underfoot

dust and sky tangled in your hair

skin eating the sun

like a stick of yellow butter

the sky is heavy on our backs

back in your room

the walls crawl like hands of clocks

we dip fingers into skin and bone

draw each other close

like curtains in lamplight

and then I’m at the terminal

a mold of you blooming across my tired posture

as the janitor cleans

the floor on which I lie, hugging myself,

leaving an unvacuumed fetusprint on the carpet

I’m in Santa Barbara

The tides are coming fast

and I am running away from them into some kind of loneliness.

come

bring your

guitar strings and

unfinished crosswords and

laundry on the floor as teacups chatter impassively

a gigabyte of sunlight melting losslessly into red red shadows

4/7/2012