complacency.

so, this is a post that's been rolling around in my brain for a while.  it doesn't mean it's any more organized for all that.

the whole NSA-spying-Edward-Snowden-RSA thing has been intriguing to me because i worked in cryptography for several years.  i've used the BSafe library, of which one method of generating keys was compromised (or not, depending who you listen to).  but i wasn't working in security research or anything, i was working for a company that did security for banks.  this was straight-up, applied-in-the-so-called-real-world cryptography.

and one thing i learned is that a lot of these conversations hit a wall when you're talking about how much money and time things cost.  but not only that, people vastly overestimate what cryptography can accomplish.  and even more so, the combination of "good enough" and overestimation leads to a lot of misunderstandings.

here is a perfect example.  i am connected to blogger.com using an https connection.  this means, in the words of firefox's page info

The page you are viewing was encrypted before being transmitted over the internet.

Encryption makes it very difficult for unauthorized people to view information traveling between computers. It is therefore very unlikely that anyone rad this page as it traveled across the network.

one major problem with this statement:  also according to the page info, this is encrypted with "High-grade Encryption" which is a whole 128-bit key.

128 bits is not a high-grade encryption key.  at least not anymore.

here's the problem with encryption:  with enough computing power, you can brute-force anything.  bigger keys just make the time it would take to brute-force the encryption astronomically inconvenient. 

and here's another problem:  as far as i can tell, most encryption standards solidified with the wide expansion of the internet back in the late '90s to early '00s.  i remember setting up my laptop in my dorm room in 1997 and my dad telling me to set netscape not to allow 40-bit SSL keys but to insist on 128-bit keys.

128 bits is the same length that google is still using in their SSL encryption today in 2014.

i was really hoping that i had read that wrong and it was 128 bytes, which would make a lot more sense almost 20 years later, but no.  128 bits.  bits.  (i assume you know this, but just in case:  there are 8 bits to a byte.  because of how encryption works, key lengths are almost always measured in bits).

my 1997 laptop had a processor that was clocked at a whole 150mhz (yes, i still remember this) and was a 32-bit processor.  my current laptop that i am typing this post on is clocked at 2.7ghz, has 2 cores, and is 64-bit.  while this one laptop alone probably would take a while to brute-force the SSL encryption of this connection, a whole lot of these tied together wouldn't, and hey, nowadays we have botnets and AWS and have also made significant advances in distributed computing models. 

and if you think the NSA doesn't have a whole lot of processors somewhere dedicated to breaking encryption if they need to then you are not nearly paranoid enough about the NSA.

so really, it doesn't matter a whole lot if the NSA compromised one of the key generating algorithms in RSA's BSafe library.  most commercial applications of encryption aren't using large enough keys to make that matter anyway.  it's great that google has moved to using "https everywhere" but since they're not using even the smallest practical 1024-bit key, i don't really feel they're doing a whole lot to stop the NSA reading my email.

if we're really serious about our privacy, then we'll stop demanding "encryption" and start demanding encryption that has changed with the increased processing power that Moore's law continues to make available to us.  we'll demand updated protocols that insist on asymmetric instead of symmetric encryption.  and we'll demand serious investment in implementing individual encryption certificates for email that can work not only with 3rd party mail clients, but also with the web apps and mobile apps.

oh, and stay away from people with wrenches.

A woman's take on GitHub: it's structural sexism.

A good example of structural sexism is going on in the tech world right now.  This story, if largely true as told (do note that GitHub has so far refused to comment), is not an example of much overt sexism.  Coming from a female perspective, and also as someone who has studied philosophy and sociology, it doesn't read like overt, obvious sexism.  But it is full of structural sexism.  What is sexism?  Generally, it's dealing with people differently based on their gender, or dealing with them based on stereotypes about gender rather then on them as an individual person.

What this story is more, however, is the story of immature people in circumstances they can't deal with, bad management, and boundless egos.  Both of these things, by the way, are very common in "the startup culture."

My husband, who is also a developer, said I should blog about it because he didn't see any sexism at all in the story until I pointed it out to him.  So I am.

First let's point out the only overtly sexist action in the story: the rockstar programmer refusing to be romantically rejected and the company not calling him out on it.  His sexual ego has been hurt and he punishes the woman who hurt him, and the other men don't really see a problem with this.

This, by the way, is one of the key assumptions of "rape culture."  If you are attracted to someone, there is this expectation that this objectified person has some kind of obligation to attempt to reciprocate the attraction or allow you to gratify it.  They do not.  If attraction is not mutual, then it just isn't.  Rejection hurts, go have a beer with a good friend and cry on their shoulder (this advice is for both you men and women), talk it over with your therapist, and deal.  There is no obligation put on the object of your attraction, except maybe to be polite in rejection and acknowledge the pain they are causing.

Anyway.  First point of structural sexism:  wife of founder has a role in the company, but it is undefined and she is not formally employed by the company.  This is sexism, pure and simple.  Because of her relationship and gender, she is excluded from a formal role in her husband's company, but is still expected to "support" him.  It's also the decision of a bad manager:  never, ever allow someone to have an undefined and unofficial role in your company.

Second point:  the unofficial wife (ok, that's not quite what I meant :) is sent to deal with the unhappy female employee over drinks.  Would the founder have sent his wife to deal with a male employee over drinks?  I'm going to guess there's a 95% chance that he wouldn't, not even if the male employee was gay (although he might have.  There's a reason discussion about women often overlaps with discussions about queer people).  But he sends a woman to deal with a woman.  This is structural sexism because it treats women differently from men based on assumptions about gender stereotypes. 

This is a big point in the story.  The female programmer is treated the way she is partly because the people involved obviously have no idea how to handle any kind of internal dispute, and partly because of her gender.  Assumptions about how to manager her are being dictated by gender, not by her or anyone else's role in the company.  When I pointed this out to my husband, he said now he could see the sexism.  He had not seen anything but bad management and a clash of egos until I pointed these aspects out to him.

But he's right, it's also a tale of egos.  This programmer thought she could "fix GitHub."  That has nothing to do with gender and everything to do with ego.  Her ego is identical to the men's egos in this story and they are clashing.  In a culture that rewards the biggest ego, the best self-seller, the loudest voice, situations like this are inevitable.  The sexism is in how this programmer specifically was dealt with.

It's wrong to say this is a story about sexism only.  But it's equally wrong to say she was not treated in a sexist manner simply because there is barely any overt sexism.  Structural discrimination is just as damaging as overt discrimination, and it's made even worse because it's invisible to the people it benefits even when they disagree and would never condone overt discrimination.