LWN.net Weekly Edition for April 30, 2015

Easier and more secure browsing in Tor Browser 4.5

The Tor project released a new version of the Tor Browser on April 27, updating many of the browser's built-in tools and improving the network-security layer. Tor Browser provides a more convenient way for users to use the anonymity and privacy of a Tor connection for their web browsing: the browser bundle is a portable application that can be run from anywhere and does not require a working Tor software installation to be installed on the host machine.

The Tor Browser, as always, is derived from Mozilla Firefox. The 4.5 release is based on Firefox 31.6 with several later patches backported—most notably, certificate-pinning improvements from Firefox 32 and 33. It also includes the Firefox extensions NoScript (version 2.6.9.22) and HTTPS Everywhere (version 5.0.3), and it bundles in the Tor client (version 0.2.6.7) and several of Tor's pluggable transport modules. These transports are plugins that obfuscate the traffic between a Tor client and the entrance node to a Tor circuit, thus making it more difficult for censors to block Tor usage. Downloads are available in a variety of language and locale options for most major operating systems.

The binaries available for download are verifiable builds; signed hashes of each binary are provided, which can be used to verify that independent builds produce the same hash. Any builder can follow the build instructions and check that their build's hash matches the official packages, and users can compare signed hashes from a number of developers' keys. This feature was introduced in the Tor Browser 3.0 series; 4.5 takes the verifiable-build concept a bit further by introducing verifiable incremental-update files as well. There are Mozilla Archive (MAR) files available for updating most 4.0-series Tor Browser binaries to 4.5, and those update files now include hash signatures as well.

Quite a bit of work has clearly gone into making Tor Browser 4.5 better on the usability front. This starts with the wrapper script used to start the browser itself. Because Tor Browser is a self-contained bundle, previous releases tended to fare rather poorly on system integration—the package was not available in the "Applications" menu, for instance, and users were left to create their own launcher scripts if they wanted the browser to appear in their PATH. As of 4.5, when Tor Browser is run for the first time, it is through a "setup" wrapper that correctly configures the user's Tor connection and, on Linux, customizes a .desktop application launcher file. This launcher can be called from any Freedesktop.org-compliant menu system or panel, run from the file manager, or even executed from the command line.

Another new usability feature is a revamped "onion menu" in the browser's main toolbar. This menu provides access to Tor- and security-related settings and features. Clicking on the menu's icon now displays status information about the Tor circuit in use for the current connection—akin to the SSL/TLS site-certificate information that Firefox displays when clicking on the location bar's lock icon. The menu also allows the user to initiate a new Tor circuit for the current page.

The settings accessible from the onion menu include a new "security slider" that allows the user to adjust the browser's overall security settings with one action. The "Low" setting (which is the default) provides basic anonymity and privacy via Tor, but does not disable any general-purpose browser features. The "Medium Low" setting turns all HTML5 video and audio content into click-to-play elements, blocks remote Java applets, disables MathML support, and disables some JavaScript performance-optimization techniques (specifically, the IonMonkey just-in-time (JIT) compiler, type inference, and asm.js) with NoScript.

In addition to the other settings, "Medium High" also disables the Baseline JavaScript JIT, disables SVG OpenType rendering and Graphite font-rendering, and disables all JavaScript on non-HTTPS sites. The "High" setting additionally disables JavaScript on HTTPS sites (although it can be re-enabled on a site-by-site basis), disables SVG rendering, and disables CSS web fonts.

Some of the features disabled with the security slider have clear security risks (such as executing remote Java applets), while others are disabled because the techniques involved have a high incidence of historical security vulnerabilities. The announcement notes that the project gleans such historical vulnerability information from research by iSEC Partners.

Under the hood, Tor Browser 4.5 offers some key improvements to the way site traffic is managed. All requests initiated in a tab will be restricted to the same Tor circuit. That should prevent problems like having a site's language suddenly change because one HTTP request is sent over a Tor circuit different than the one used a few minutes earlier.

The browser also isolates sites from one another by ensuring that different pages' requests travel over different circuits, even when those requests are to third-party sites. This ensures that embedded elements like the pervasive "like" buttons placed by social-media services cannot track the user between pages loaded in different tabs. Furthermore, the URL.createObjectURL() method from the W3C File API (a method that can be used by JavaScript code to create a new URL reference) is restricted to the same circuit as the page that called it and the SharedWorker API has been disabled entirely. Both methods could be abused to enable cross-site communication and, thus, to allow sites to track the user across multiple web sites.

Other privacy enhancements include the disabling of the W3C Sensor API and the Mozilla video statistics API (both of which enable a site to record information about the browser's behavior) and a new default search engine. The new search engine, Disconnect, is a privacy-conscious search redirector that is maintained by a privately funded US security start-up; it sends the user's search queries to popular search engines like Google, both anonymizing the request and sanitizing the results returned by the downstream search provider.

Last but not least, the new browser release includes rewritten transport modules and introduces a new transport called obfs4. The obfs4 transport is designed to better resist deep-packet inspection (DPI); the 4.5 release announcement notes that obfs4 currently enables Tor access from within China. Recent Tor releases include obfs4 (so it is running on up-to-date bridge nodes), but clients need to have the package, too, in order to use it as a transport.

If censors learn the IP address of a Tor bridge node, they can block access to that node, but it is believed that an obfs4-powered node cannot be discovered through any known automated traffic-scanning techniques. For such a bridge node to be revealed, it would have to be discovered and reported through some other means.

On the whole, the changes in Tor Browser 4.5 make for an easier-to-configure browsing experience, which is critical for convincing users to give it a chance. The lower-level improvements like better circuit isolation and improved transports may not be visible to the casual user, but are certainly critical. Given that the state of the art changes so rapidly on the web, it is encouraging to see Tor Browser keeping pace.

Comments (none posted)

The programming talent myth

Jacob Kaplan-Moss is known for his work on Django but, as he would describe in his PyCon 2015 keynote, many think he had more to do with its creation than he actually did. While his talk ranged quite a bit, the theme covered something that software development organizations—and open source projects—may be grappling with: a myth about developer performance and how it impacts the industry. It was a thought-provoking talk that was frequently punctuated by applause; these are the kinds of issues that the Python community tries to confront head on, so the talk was aimed well.

Some background

Kaplan-Moss began by noting that he is a contributor to Django and the director of security at Heroku. He is a longtime PyCon attendee (eleven years) as well as a regular speaker at the conference (ten years). The Python community means "more to me than anything in tech" and giving a keynote at PyCon is "the highlight of my career", he said.

His first PyCon talk was in 2005 about a utility for bridging Python and AppleScript. At the same PyCon, which was held in Washington, DC, Adrian Holovaty gave a tech demo of some tools that were being used to build web sites at the newspaper in Lawrence, Kansas where they both worked. Those tools are what became Django. Now Django is ten years old and is used around the world, he said. He has watched PyCon go from 300 people to nearly 3000 and the community explode with new people and growing diversity. So "I really mean it" that the keynote is "the apex of my professional career".

On the other hand, though, his main emotion there on the stage was insecurity. There is a voice that is telling him he does not belong on the stage with the others he has shared it with; that he doesn't deserve the success he has had. There is "a little hater" (in the words of Jay Smooth from a video clip that Kaplan-Moss played) in the back of his head telling him these things.

The "really insidious thing" about the little hater is that a little bit of what he says is right. That is not a "humble brag" or false modesty on his part, he said, and there are things he has done that he is "incredibly proud of". In fact, there are things that he has done that do make him feel qualified to be on that stage, but they are probably not the things that the audience is thinking about.

Many probably think he is giving a keynote because he is the "inventor of Django", but that isn't at all the case. Those who know a bit more about how Django came to be might think of him as the "co-creator of Django", but even that overstates things significantly. He was actually hired to work at the newspaper a year after Holovaty and Simon Willison invented and co-created Django. "Really, I'm the guy who got hired to work on the thing a year after it was already made", he said with a grin.

People assume that he is somehow responsible for the creation of Django because he is an "incredible programmer"; that he is a "rock star" or a "ninja" programmer—or "whatever it is that recruiters are calling it these days". People believe that he is successful because of his programming skill. But that simply isn't true: "I am, at best, an average programmer", he said (with a slide that read "Hi, I'm Jacob, and I'm a mediocre programmer.").

Running

He switched gears a bit, putting up a picture of ultramarathon runner Ann Trason, who is the most accomplished competitor in the history of that sport. Ultramarathons are runs that are longer than the 26 miles of a marathon; typically they are run on trails requiring stream crossings and the hardest races can take multiple days of continuous running to complete. Distances for races are generally 50-160km. Trason has set multiple course records that still stand 10 or 20 years later. No one has come within an hour of some of her records, he said. It is hard to overstate how dominant and how exceptional Trason has been in that sport. He was talking about that because he recently finished his first 50km race, which means he can call himself an ultra runner too.

He is, however, not anywhere close to Trason's league, but he does get to wear the same label. He is a mediocre runner, finishing 535th out of around 1000. There are lots of numbers that can be used to quantify his performance: his pace, the distance and elevation change of the course, and so on. There is a site that calculates a "runner's score" that estimates how close a runner's time will be to that of the winner of the race. He is around 68% (which overstates things, he said), while Trason is 98.58% ("in other words, she usually wins").

That gap is not particularly surprising. If you plot a histogram of times in a race (or runner's scores, etc.), you get a familiar curve: the bell curve or the normal distribution. Most people are average, while there are a few that are either exceptionally good or bad in "the skinny ends of the curve". Almost every skill that we know how to measure ends up showing a distribution that looks like that curve.

Mediocrity

When he said that he was a mediocre programmer, some in the audience probably didn't believe him, he said. Why is that? The vast majority of those in the audience have never actually worked with Kaplan-Moss, so why would they assume his coding ability is exceptional? In the absence of any other data, people should assume that he is solidly in the middle of the curve. Part of the problem there is the lack of a way to even measure coding ability. "We are infants in figuring out how to measure our ability to produce software", he said. What are our metrics? Lines of code—what does that measure? Story points? "What even is a story point?", he wondered.

Programmers like to think they work in a field that is logical and analytical, but the truth is that there is no way to even talk about programming ability in a systematic way. When humans don't have any data, they make up stories, but those stories are simplistic and stereotyped. So, we say that people "suck at programming" or that they "rock at programming", without leaving any room for those in between. Everyone is either an amazing programmer or "a worthless use of a seat".

But that would mean that programming skill is somehow distributed on a U-shaped curve. Most people are at one end or the other, which doesn't make much sense. Presumably, people learn throughout their careers, so how would they go from absolutely terrible to wonderful without traversing the middle ground? Since there are only two narratives possible, that is why most people would place him in the "amazing programmer" bucket. He is associated with Django, which makes the crappy programmer label unlikely, so people naturally choose the other.

But, if you could measure programming ability somehow, its curve would look like the normal distribution. Most people are average at most things. This is not Lake Wobegon, most people are not above average, he said.

A dangerous myth

This belief that programming ability fits into a bi-modal distribution (i.e. U-shaped) is both "dangerous and a myth". This myth sets up a world where you can only program if you are a rock star or a ninja. It is actively harmful in that is keeping people from learning programming, driving people out of programming, and it is preventing "most of the growth and the improvement we'd like to see", he said to a big round of applause.

The US Bureau of Labor Statistics estimates that by 2020 there will be a 1.5 million programming job gap, which means there will be that many jobs unfilled. That's in five years. The EU has published similar numbers, 1.2 million in 2018—three years. That means we need to be doing something to get more people into our industry. But the myth is a filter that prevents people from even considering programming as a career. The myth is aided by the belief that programming is an innate talent that people are born with. Those who do not know how to write software and who believe in the myth fall into a trap: thinking that their age has reached "30 or 20 or 15" (or even 40 or 60, he added later) and, because they haven't written any code yet, that means that they never can or will.

If the only options are to be amazing or terrible, it leads people to believe they must be passionate about their career, that they must think about programming every waking moment of their life. If they take their eye off the ball even for a minute, they will slide right from amazing to terrible again. That leads people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.

But we don't believe these things about other activities. Over half a million people ran a marathon last year—did all of them have an innate talent for running? Kaplan-Moss doubts that they did; he didn't. Most of those people ran their marathon rather badly, but a tiny fraction ran theirs very fast. To be a runner, though, all it takes is a pair of shoes. We don't even believe that you have to particularly like running to be a runner.

Someone asked him what the best part of running the 50km race was; "finishing" was his answer. Running a marathon is difficult; it takes lots of training and requires commitment and focus. Is writing software—writing Python—harder than running a marathon? "Why aren't there half a million people here today?", he asked. We tell ourselves different stories about one skill, coding, than we do for another, running.

He then gave an example of what this narrative can do to people. At the University of Kansas's geographic information system (GIS) day a few years ago, he sat in on a "fantastic presentation" about predicting seasonal floods on the Kansas River. The student had used tools that should be familiar to many of those at PyCon: Amazon Web Services, Linux, PostgreSQL, Python, Django, GeoDjango, and so on. Kaplan-Moss was hiring at the time, and she (the student) had just written thousands of lines of Python, so he asked if she wanted to interview for his company. Her response was that she couldn't do that, because she "was not really a programmer". That came from a woman who had just invented her own distributed GIS data processing pipeline, he said—but she's not really a programmer. That's because "programming is something you are in this myth, not something you do".

Just skills to be learned

The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned. Programming isn't even one thing, though he had been talking about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed. Also, "we need to have at least one person who understands Unicode", he said to laughter.

There are multiple independent skills, but we tend to assume that someone is the minimum of their skill set. Sure, you might be a good designer, speak and write well, and be a great project manager, but you don't know how a linked list works, so "get out of the building". Like any other skill, you can program professionally, occasionally, or as a hobby, as a part-time job or a full-time job. You can program badly, program well, or, most likely, be an average programmer.

If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers. If the bar for success is set "at okay, rather than exceptional", the bar seems a lot easier to clear for those new to the community. Even once we get people into the community, the talent myth can haunt them—it can actively drive people out of tech.

The tech industry is rife with sexism, racism, homophobia, and discrimination. It is a multi-faceted problem, and there isn't a single cause, but the talent myth is part of the problem. In our industry, we recast the talent myth as "the myth of the brilliant asshole", he said. This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic. In reality, given the normal distribution, it's likely that these people aren't actually exceptional, but even if you grant that they are, how many developers does a 10x programmer have to drive away before it is a wash?

At that point, he added the famous picture of Linus Torvalds flipping off NVIDIA under the "brilliant asshole" label in his slide. While some might argue the context, it certainly struck a chord for the people at the keynote as it was met with laughter and applause.

"Real programmers"

Kaplan-Moss then asked what a 10x programmer looked like and put up a series of pictures of "Mark Zuckerberg". The first was actually the actor who played Zuckerberg in The Social Network movie, while the second was the Saturday Night Live cast member who satirized the actor in the movie. The third actually was Zuckerberg. All three were young white men, which is the archetype of a "real programmer", he said.

When we see someone who does not look like one of those three men, we assume they are not a real programmer, he said. Almost all of the women he knows in the industry have a story about someone assuming they aren't a programmer. He talked to multiple women attending PyCon 2015 who were asked which guy they are there with—the only reason they would come is because their partner, the man, is the programmer. "If you're a dude, has anyone ever asked you that?"

On the other hand, when he got up on stage, he did look like those guys. "So you probably assumed I was a real programmer." These sorts of assumptions contribute to the attrition of marginalized people in tech, he said.

He presented some numbers from the National Center for Women & Information Technology (NCWIT). Half of women with Computer Science degrees are not using those degrees as part of their employment. 40% of women leave technology within ten years, while only 17% of men do. Over half of women leave the industry at the mid-point of their careers.

There are certainly other causes, he said, and wasn't implying that there is only one root cause. But imagine how frustrating it must be to be a woman with a decade of experience and have someone assume that she doesn't know what she is talking about. It is going to take a serious effort to overcome the diversity problem. We are never going to get there if we can't come up with a more nuanced way to think about what a programmer is—and what programming skills really are.

There are all kinds of runners—sprinters, distance runners, marathoners, etc.—of all shapes, sizes, genders, ages, and races. All of them have different metrics for success and all are capable of being successful by their own metrics. "We have got to find such a nuanced, shaded, interesting way of thinking about skill in tech," he said.

A conversation with Lynn Root at PyCon a number of years ago was the genesis for his talk. Root is a programmer, a founder of the San Francisco chapter of PyLadies, a Python Software Foundation board member, and has "been in and around this community for a while". PyLadies was fairly new at the time of the conversation and he was excited about the energy, excitement, people, and skills that the group was bringing to the table. To Root he said "it's so great to see all of these bad-ass women programmers". She agreed, but noted: "We'll know we've been really successful when there are a whole bunch of average women programmers". That too, was met with big applause.

The talent myth sets an "impossibly high bar for entry", he said, and the fact that any of us are here at all "is kind of shocking given this myth". It needs to be dismantled and a community that recognizes that "average is actually pretty awesome" should be be built in its place. He is a mediocre programmer and he invited others to join him; "together we can do our jobs perfectly adequately". Attendees gave Kaplan-Moss a standing ovation for the keynote.

After that, he took questions, but he requested that people actually ask questions, rather than to use the microphone as a way to "share their opinion or to pontificate on what the speaker has said". He said that he is personally quite interested to hear those opinions, but that it should be done in email or on Twitter, because sitting in the audience during these "non-questions" leads to "frustration and anger". Based on the applause for that, he is not the only one to be annoyed by that behavior.

Several questioners also admitted to mediocrity in programming. Questions ranged from whether the security field is different with regard to the talent myth (short answer, it is "even worse", which makes it that much harder for people to enter that field), myths around the depth vs. breadth of knowledge (it is part of the myth that people have to "impossibly know everything about everything", there are roles for both specialists and generalists), and how to get mediocre programmers to get the courage to apply for these jobs ("I wish I knew the answer to that").

Perhaps the question he spent the most time answering was how to get these ideas into the heads of the recruiters, venture capitalists, and others who are actually determining who gets brought into the community. It is a difficult question to answer, he said. Part of it has to do with the "crazy 60-hour weeks" that have come to be expected. Companies need to respect the idea of a work-life balance, with work weeks of 40 or 35 hours, and it is up to those who are in prominent positions to push their companies to recognize that. People should be able to do their jobs well, adequately, that is, and be commended for that. The same goes for working a healthy schedule—it should be commended as well. With a 1.5 million job gap looming, companies that don't do so may find themselves unable to fill the positions that they have.

[A YouTube video of the keynote is available.]

Comments (146 posted)