rc3.org

Strong opinions, weakly held

Page 10 of 989

How to report on information security

Today the New York Times has another Edward Snowden story, this one by David Sanger and Eric Schmitt. It discusses the means he used to harvest millions of documents from the NSA’s internal network, and runs under the headline Snowden Used Low-Cost Tool to Best NSA. Good security reporting focuses on the conflicting goals come into play when designing secure systems, rather than retreating into counterfactual thinking.

Here’s the sort of counterfactual thinking I’m talking about:

Mr. Snowden’s “insider attack,” by contrast, was hardly sophisticated and should have been easily detected, investigators found.

And:

Agency officials insist that if Mr. Snowden had been working from N.S.A. headquarters at Fort Meade, Md., which was equipped with monitors designed to detect when a huge volume of data was being accessed and downloaded, he almost certainly would have been caught.

And:

Officials say web crawlers are almost never used on the N.S.A.’s internal systems, making it all the more inexplicable that the one used by Mr. Snowden did not set off alarms as it copied intelligence and military documents stored in the N.S.A.’s systems and linked through the agency’s internal equivalent of Wikipedia.

When telling a story about security, or any system, there are three aspects that are involved – the intended functionality, security (and safety in general), and cost. Here’s the only sentence from the story that even hints at these tradeoffs:

But he was also aided by a culture within the N.S.A., officials say, that “compartmented” relatively little information.

The NSA built a system for sharing information internally out of off the shelf Web technology (which almost certainly lowered costs substantially), and provided broad access to it for the same reason that any organization tries to improve communcation through transparency. They wound up with a system that was no doubt difficult to secure from people like Edward Snowden.

While the crawler Snowden used might possibly have been easy to detect, writing a crawler that is difficult to detect is not particularly challenging. A Web crawler is pretty straightforward. It downloads a Web page, extracts all of the links, and then follows the links and repeats the process. It recursively finds every Web page reachable from the page where it starts. On the real Internet, crawlers identify themselves and follow the robot exclusion standard, a voluntary code of conduct for people who write programs to crawl the Web. There’s no reason it has to be that way, though. Browsers (or crawlers) identify themselves with a user agent, and when you request a Web page, you can use any user agent you want.

The point is that there’s nothing any specific request from a crawler that would make it easy to detect. Secondarily, there’s the nature of the traffic. The recursive nature of the requests from the crawler might also be suspicious, but detecting that sort of thing is a lot more difficult, and those patterns could be obfuscated as well. If you have months to work, there are a lot of options for disguising your Web crawling activity.

Finally, there’s the sheer volume of data Snowden downloaded. Snowden literally requested millions of URLs from within the NSA. Again, there are ways to hide this as well, especially if you can run the crawler from multiple systems, but if you’re going to download over a million pages, it’s difficult to disguise the fact that you have done so. Detecting such activity would still require some system to monitor traffic volumes.

Somehow Snowden also managed to take the information his crawler gathered out of the NSA. That seems like another interesting breakdown in the NSA’s security protocols.

The article has plenty of discussion of why Snowden should have been detected, but very little about why he wasn’t, and even less about how the desire to secure the system is at odds with the other goals for it. The thing is, the journalists involved didn’t need to rely on the NSA to give them any of this information. Anyone familiar with these sorts of systems could have walked them through the issues.

Any article about security (or safety) should focus on the conflicts that make building a secure system challenging. The only way to learn from these kinds of incidents is by understanding those conflicts. One thing I do agree with in the story is that Snowden’s approach wasn’t novel or innovative. That’s why the story of the tradeoffs inherent in the system is the only interesting story to tell.

Yes, you should do what you love

When I mentioned seeking out people who are intrinsically motivated to work with a few weeks ago, my friend Jason commented with a link to Miya Tokumitsu’s essay In the Name of Love in Jacobin magazine. It has since been picked up by Slate. Here’s her take on “Do What You Love”:

By keeping us focused on ourselves and our individual happiness, DWYL distracts us from the working conditions of others while validating our own choices and relieving us from obligations to all who labor, whether or not they love it. It is the secret handshake of the privileged and a worldview that disguises its elitism as noble self-betterment. According to this way of thinking, labor is not something one does for compensation, but an act of self-love. If profit doesn’t happen to follow, it is because the worker’s passion and determination were insufficient. Its real achievement is making workers believe their labor serves the self and not the marketplace.

I agree that DWYL is not a valid policy prescription. If we could magically sort everyone so that they could earn a living wage pursuing the activity that they love most, we would not have a functioning society, much less a functioning economy. So we have to accept the reality that for many people, perhaps the large majority of people, a job is just a job.

Given that, we need labor policy that does not assume that work is its own reward. Work week regulations, paid vacations, parental leave, and other policies are all intended to provide respite to workers from exploitative employers. Minimum wage laws put some floor on how much you must pay workers, regardless of how much they love their jobs.

For those of us who are managers, it’s important not to exploit the fact that some people love their jobs and will work all the time if you let them. It’s important for people to keep a healthy schedule and take their vacation time, even if they would prefer not to. Not only is overwork unsustainable, but it creates a dynamic in which people who would prefer to maintain something resembling a balanced life wind up working too much because they’re afraid to fall behind in a perceived competition with their less restrained coworkers.

An enthusiastic manager who works 70 hours a week sends a message to even the least enthused person that working lots of hours is expected. This oblivious manager may just assume that everyone on the team is happy to work those hours, given that they’re doing so without even being asked.

As a matter of government or corporate policy, we’ve got to take these factors into account.

However, if I am talking to an individual, rather than talking policy, my advice will always to be to do what you love (or, do what you can’t not do) if you can get away with it. We spend at least 2,000 hours a year at work. If it’s up to me, I’ll spend that time doing work that I enjoy. I want other people to do work they enjoy as well. To the extent that I have influence over who I work with, I seek out people who also find joy and fulfillment in their day to day work.

It seems to me that a discussion of labor policy is ideally suited to analysis from behind John Rawls’ veil of ignorance. We should think about these matters from the perspective of someone who has no idea whether they will like their job or hate it, or whether it may be at a desk or in a coal mine or tomato field. At the same time, when you’re looking for a job, try to find one you’ll enjoy and find fulfilling, and be thankful if you manage to do so. It’s not that common.

Describing my ideal dotfile installer

One of my goals is to perfect my dotfile setup. I suppose this means that I’m not quite all in as a manager yet. Every self-respecting developer has their dotfiles in a public repository on GitHub, but I have a couple of requirements beyond just being able to clone my dotfiles on any machine. They are:

  • I have some dotfile information that can go into a public repository, and some configuration and preferences that must live behind the firewall for use on work computers. I’d like for the behind the firewall stuff to be a supplement to my public dotfile information. For example, my .vimrc should be the same everywhere. My .bashrc should be mostly the same, with a few additions of stuff for work. I may also have some dotfiles that are exclusive to my work environment. Any setup should understand how to clone files first from my public repo, and then apply the dotfiles from the private repository.
  • Homebrew can be bootstrapped using a single shell command. (Check it out under the Install Homebrew heading on the Homebrew page.) I’d like to have something similar for my dotfiles. Not only would it be cool, but it would also be useful at work. All of our servers at work are managed using Chef. It’s possible to check your dotfiles into our Chef repository and have them deployed automatically on all of our servers, so that when you log into a new server, it already has your preferred environment set up. I have two issues with just putting my dotfiles into Chef. The first is that I don’t want to clutter up the Chef repo with my junk. If everyone does that, our Chef runs will slow down. The second is that I don’t want to have to update them in two places whenever I make changes. If I have a bootstap command that pulls all of my dotfiles from their regular location, I can just put that into Chef.

I’m going to start hacking away on creating a dotfile installer that meets both of these requirements and blogging about my progress. My public dotfiles are in a GitHub repo. I’ll let you know how it goes.

Ten years later, those freedoms are still embedded in every copy of WordPress downloaded, including the 9.2 million downloaded in the past month …

WordPress creator Matt Mullenweg writes about The Four Freedoms, Richard Stallman’s software bill of rights.

Peter Seibel on code reading

Code is not literature

Interesting thoughts on code reading and how we should educate ourselves by exploring code that we didn’t write, from Peter Seibel.

The New Yorker: Who Killed Net Neutrality?

Who Killed Net Neutrality?

This is the most important tech story of the week, and everybody has chosen to write about it. This just happens to be the one I’m linking to. It’s by Tim Wu on the New Yorker’s Elements blog.

Looking for an audience and finding interlocutors

Former New York Times executive editor (and current columnist) criticized a straw man version of cancer patient Lisa Adams, arguing that she is:

… the standard-bearer for an approach to cancer that honors the warrior, that may raise false hopes, and that, implicitly, seems to peg patients like my father-in-law as failures.

He then added:

Steven Goodman, an associate dean of the Stanford University School of Medicine, said he cringes at the combat metaphor, because it suggests that those who choose not to spend their final days in battle, using every weapon in the high-tech medical arsenal, lack character or willpower.

As it turns out, it’s not Lisa Adams who introduced the combat metaphor, but rather Keller himself. Here’s what Adams said about combat metaphors on her blog in 2012:

When I die don’t say I ‘fought a battle.’ Or ‘lost a battle.’ Or ‘succumbed.’ Don’t make it sound like I didn’t try hard enough, or have the right attitude, or that I simply gave up.

Straw man.

After people started calling Keller on it, he responded to a question from the paper’s public editor thusly:

I think some readers have misread my point, and some – the most vociferous – seem to believe that anything short of an unqualified “right on, Lisa!” is inhumane or sacrilegious.

I have no doubt that he did get some responses like that, but choosing to dismiss those responses rather than engaging with more substantive critiques was lazy and evasive.

Plenty of people have written excellent pieces explaining why Keller is simply wrong on the facts and in his conclusions. For example, you should definitely read Zeynep Tufekci’s post Social Media Is a Conversation, Not a Press Release. What I want to write about is Keller’s lack of preparedness to opine in the age of social media.

One thing we do on the Internet is argue. A lot. Some of us have been arguing with people on the Internet for decades, and many of us have internalized the big list of fallacies and are just waiting for an opportunity to recognize their use and shove your argument back in your face. It doesn’t matter whether you’re arguing about text editors, the baseball Hall of Fame, or how cancer patients ought to use social media, the Internet knows more than you do about it. In the open source world, they say that given enough eyes, all bugs are shallow. It’s also true that given enough participants in an argument, all errors of fact and fallacious arguments are exposed.

It’s times like these when the old media really shows its age. In the good old days, you could pronounce and pontificate with relative impunity. The worst thing they faced were letters to the editor. These days, by publishing, you are making an argument, and you can expect for people online to argue back. The second a column goes up, people start dissecting it on Twitter. Then come the blog posts. And finally, other publications, or even your own, start running think pieces about the online reaction to your crappy column. If you’re David Brooks, the Internet will probably skewer you with top notch satire as well. The old guard is going to have to harden up.

Update: Really nice post by Linda Holmes for NPR about how Bill Keller uses language to diminish Lisa Adams and her readers.

What should the technology industry be famous for?

I had one of those “reading your own obituary” moments this morning when I picked up the New York Times. In an article about how banks are trying to change the customs that coerce junior employees to work nights and weekends, the writers bring up the increased competition from the technology industry. Here’s how they put it:

Though the prospect of a large salary and experience in finance still draws many college graduates to the industry, some ambitious students are considering other career paths, including those in the technology industry, famous for its employee perks like free oil changes or staff masseuses.

It irritates me to see that the industry in which I’ve spent my entire career is defined to outsiders by the perks offered, and not just because I’ve never gotten a free oil change or a massage at the office. I have plenty of friends who work in industries full of people who are motivated by compensation, perks, prestige, and everything but the work itself. Most of them are eagerly looking forward to retirement.

Weeding out those sorts of people is probably my number one goal in the interview process. As I said when I reviewed The Soul of a New Machine, for me, the work is the reward. If you don’t see it that way, you should consider the opportunities available in finance.

Tim Bray sums up the state of the art

Tim Bray: Software in 2014

Solid summary of where things stand right now.

Update: Sam Ruby follows up.

How to hire a superhero

University of Rochester computer science professor Philip Guo has written a great post, shining a light on the bias in the computer industry in favor of people who look like him (or me). In it, he explains how he has gotten the benefit of the doubt in situations simply because he looks like what people expect a computer programmer to look like. It’s a first-hand account of what John Scalzi talked about when he wrote about straight white males playing the game of life on easy mode.

Here’s a bit from the post, Silent Technical Privilege:

… people who look like me can just kinda do programming for work if we want, or not do it, or switch into it later, or out of it again, or work quietly, or nerd-rant on how Ruby sucks or rocks or whatever, or name-drop monads. And nobody will make remarks about our appearance, about whether we’re truly dedicated hackers, or how our behavior might reflect badly on “our kind” of people. That’s silent technical privilege.

He contrasts that with the challenges placed before people who are outside the demographic sweet spot that so many people associate with being a computer programmer. As he says, you don’t have to be a superhero to succeed in software development, and we shouldn’t demand that people who don’t enjoy these privileges be superheros to make it in this business.

This leads me to the theory that if you want to hire superheros, you should ditch your biases and expand your hiring pool. The people who have persisted and succeeded in this industry in the face of the inequeties that Philip documents are much likelier to be superheros than your run of the mill bro who shows up to the inteview in his GitHub T-shirt with a cool story about making money in high school by creating Web sites for local businesses. There are plenty of superheros that fall into the privileged category, but they already have good jobs because they will never, ever be overlooked in the hiring process. The awesome programmer who also seems like they’d be super fun to have around the office? They get a job offer every single time.

The enterprising hiring manager has to think outside the box a bit. You know the feeling. The person seems like they’d be great at the job, but is different enough from everyone else that you wonder a bit how hiring them would affect team chemistry. I’m not talking about personality here, but demographics. (I’d never recommend that a non-competitor hire brilliant jerks.) The hypothetical candidate I’m talking about here has to deal with these unspoken questions every single time they apply for a job. That’s not fair, and it’s incumbent on our industry to change, but in the meantime, it’s possible to exploit these widespread biases to hire the superheros that most companies won’t even consider. At least that’s the theory.

« Older posts Newer posts »

© 2024 rc3.org

Theme by Anders NorenUp ↑