Thursday, November 17, 2016

Schrodinger's cat and getting through law school as a programmer



This is a "wouldn't fit in 140 characters" overflow blogpost from a twitter discussion of software developers learning in law school. I'll attempt to explain just why law school, and thinking about legal "balancing" and "multi factor" tests can be so frustrating when you're trained as a software developer.

Computer science trains developers to expect logical proofs, and compilers give you a definitive immediate feedback of "yes this is at least one kind of correct because it compiles," which is something you can't do in a legal world. But it's more than that. Programming is a step by small step process, where the computer takes you literally. You're probably saying "yes, I know that," but I mean that quite literally, the computer does exactly what you tell it to do. A programming language is a set of tools you can use to construct a solution to a problem that you've broken down into tiny manageable steps. My first time I figured out that there's a logical system to solving problems, where being at state "A" meant you applied one of a known set of possible next steps, and again and it would lead you to a solution, was amazing. It was relaxing and exhilarating  and fun all at the same time to process the problems and to see how the logical next step at each stage would get you to the answer. To realize that divide, conquer, apply next step from this toolchain, and repeat would get you somewhere, and it would be fun to do so, is addictive.

In college computer science classes we learned not just a particular language, but that any programming language was just "syntactic sugar" and any non-NP complete problem could have a solution written if you just attacked the problem the right way. It taught us to, again, break down an issue into discrete steps, apply the tools of the programming language, and end up with a working piece of code. A developer becomes pretty good at trying to fit problems into recognizable boxes that are sort of like previous problems, and applying the same pattern of solution to them.

Debugging also teaches developers to be incredibly detail oriented and literal. The computer does not do what you meant, does not do what you thought you typed in, but only explicitly and completely and totally exactly what you actually typed in. The compiler is going to follow the directions you gave it, and execute those, and the outcome is always the same for that same set of directions.

So our software developer who decides to go to law school realizes that law school isn't like software development. Sure, there is no legal compiler. Gotcha, outcomes vary and these are more heuristics. But this is still a brain that's been trained to fit problems into boxes, to be literal about what rules apply, and to follow logical deduction chains. The law usually says one thing, but hey, not in this case- the mental model I've built of what the law says now has an exception to it. The logic branches under this condition. I update my mental model to account for that exception and move on. But I'm still, even if subconsciously, constructing a big logical flowchart in my head that's going to handle all these curve balls in judicial opinions.

Until it doesn't work anymore. My first breakdown came over two torts cases that, to my mind, came out in logically inconsistent ways. My email to my professor was pretty much trying to expand my rules to handle this inconsistency: "How should we reconcile these?  Is it just that under battery, particulate matter is considered one way and under the other tort it has a different nature?... The engineer in me is having a bit of trouble with particulate matter being a Schrodinger's cat here, both enough for a tort but not enough for a tort."

The thing is, developers are pretty good at tackling incredibly complex problems and writing up solutions, and so the first curve ball isn't really going to stress your worldview that much. You just add an exception to your mental model and handle it. At some point, this mental model gets stretched too far. It won't handle another contradictory result. Multifactor tests that judges apply come out all over the place, briefs claim to be arguing logically and deducing one part of the argument from the previous one but they're making leaps in inferences, and your poor developer brain will just decide the whole thing is insane.

I had a series of mental freakouts one L year. It's not that the tools you learn in programming are useless in legal analysis; they're actually really helpful. Reading an opinion and constructing a mental model of the relevant law, finding the holding and following how that was applied in this instance are helped by the mental toolkit a developer has. Trying to make peace with the logical-but-not-really logical fuzzy mess of legal reasoning and how the common law really works is kind of a process. Pretty sure my subconscious is still building that exception laden tree, working off "fuzzy logic" precepts now.



Tuesday, August 02, 2016

Becoming an infosec con speaker, Part 2

Back April, I wrote about speaking at my first BSides, the BSides Charm conference in Baltimore. In there, I discussed getting selected for the awesome BSidesLV Proving Ground program, which pairs newbie speakers with mentors.

My BSidesLV talk was just this afternoon, so while it's still fresh in my mind I wanted to write up a little bit about how the talk came together.  My submission was on the same general topic as the BSides Charm, so we started with that slide deck as a starting point.


Security Vulnerabilities, the Current State of Consumer Protection Law, & how IOT Might Change It





For this one, though, I'd put in "I think IOT will change software liability" and so we chose to really push that more than the vulnerability disclosure/failure to warn angle.

The experience of having another person to work through a talk with was incredibly helpful, and I can't recommend this enough. Being able to get feedback on questions like "I don't know what to do with my hands during the talk" to tips like "no full sentences on the slides" (if you view my slides you'll see I actually ended up breaking this one). Here are some notes from one of our discussion:

* front load more of the idea? Start with a story…. get comfortable with delivery
* no full sentences in the presenter notes

1. print out slides, write one or two things on the slide to refer
  * distill what to get out of the slide
2.  imagine the situation, and what would happen?
** context setting


Looking at this now, some of this seems obvious, but it helped to make me realize I wasn't doing those obvious things, and helped to frame the talk. Starting with a story... I was like yes, I have done that in almost every legal paper I've written. Why aren't I doing that here?

The big point in developing the talk for me came in mid-July. I had a set of slides that I was mostly OK with. I did a dry run over Hangouts, and I got... stuck about 3/4 of the way through the talk. I had to restart. It wasn't flowing, I wasn't setting up points I wanted to make later, I meandered. It was painful.

So I enlisted a stuffed animal. I pulled up those slides & tried to give the talk again and again, to my little stuffed fox:



I got stuck, again. So I pulled out a paper notebook, and made a bubble flow chart of what the big ideas should be, and how they would flow. This was really, really, really, really hard. I was sitting there going "I don't know what I'm doing as a speaker and why won't this work."

I started thinking of the spots I got stuck as pivot points, where the talk had to transition into a new idea. My problem was that I wasn't realizing that I had to do those pivots, didn't think about setting up the next section of the talk until I landed on a slide, and had to pick up the threads.

Here is where mentors are awesome: my mentor had pointed out that I needed to signal these transition points, and we had sort of talked about showing it on the slides. On powerpoint's presentation view (which is fabulous!) you can see the next slide coming up. So I made a slide with very little text for each transition and I colored those transition point slides solid purple, so that it would be visible in my peripheral vision when I glanced down at the screen. Just having that solid purple coming up was a reminder that I had to start framing the next section. That one change made the talk flow so much better.

Since this was a legal talk for an infosec audience, trying to get the right level of legal terminology explained without descending into jargon was important, as was getting across the background information. This audience wouldn't have a 1L law school background. Tort law and strict liability are important to software liability, but mean nothing to someone without a legal education. Having a mentor remind me to figure out how to explain those concepts in one sentence was really helpful.

My slides are online now; the talk was recorded, but I'm not sure when it will be online. I actually don't remember much about giving it- I do sort of remember missing some things that I'd wanted to say, but since each time through was slightly different, that was really just going to happen. I don't think that I could give an overly rehearsed talk, because I'd just be reading off the speaker notes, and it would probably be kind of flat. I had phrases in my speaker notes that were "big idea to get across here" but I didn't look at them as much as I thought I was going to.

So, that was how my talk came together. It was really fun, and I'm so grateful for the opportunity to work with a mentor on this talk, and for the chance to come to Las Vegas in August and speak at one of these conferences. Last August was my first time attending, when I got an academic sponsorship to Black Hat. Never in a million years did I think I'd be back the next year as a speaker. Thank you BSides Proving Ground for that chance!


Sunday, April 24, 2016

Becoming an infosec con speaker


In 2006, I attended my first infosec conference- HOPE in NYC, July 2006. And then yesterday I spoke at an infosec con -- BSides Charm 2016, something I seriously still have trouble wrapping my head around.

My talk was "Failure to Warn You Might get Pwned: Vulnerability Disclosure and Products Liability in Software" on how products liability law might someday apply to software (maybe - a lot of the talk is on why it doesn't apply now). It's a topic I've been interested in for a while; I wrote about it after the BlackHat keynote this summer.

I don't particularly have any qualifications to give this talk. I took a Products Liability law class in lawschool last year. I know a little bit about vulnerability disclosure from working in the software industry. The specific idea for this talk came out of hearing two different people, in different contexts, say that they thought that failure to warn and vulnerability disclosure might be worth looking at. And so I did. At the same time, Shmoo was opening their CFP, and encouraging newbie speakers to submit.

Let me jump back a few years- at the 2012 OSCON in Portland, I got into a conversation that made me decide that I should apply to lawschool. But also at that con, I spent some hallwaycon time sitting at the "women in tech" table and talking with Suzanne Axtell. She was trying to encourage all of us sitting at the table to submit to conferences. At the time, I was working at a company with a pretty restrictive public speaking policy, so my take was mostly "I don't know anything interesting to talk about, I don't know how to get a talk accepted, and even if some miracle happened and I did have one accepted, my company wouldn't let me speak." So I forgot about it, and went off to school the next year. At some point, I subscribed to the Technically Speaking email list, mostly because the two women who run it are really smart & say interesting stuff about a pet cause of mine, boosting the numbers of women in tech.

And then I saw the Shmoo tweets, and realized that the "my company wouldn't let me" excuse didn't apply to someone unemployed. So I submitted. And was rejected, but I got a ticket registration, which for Shmoo is pretty amazing. Then there was a lot of chatter on Twitter about encouraging women to speak.


 Shmoo Firetalks CFP went out shortly after. I think my thought process was "well, I have a proposal written, I'll just submit it and nothing will happen but whatever I submitted."  And then it was accepted for Firetalks, and I had to actually get up and give this talk- but it was "Firetalks," aka "not real" and it actually turned out to be a lot of fun.

Shortly after, the BSides Charm CFP opened, and... I think my thought process there was "huh, people actually told me at Shmoo that they found my fire talk interesting, maybe I'll tweak and submit."  Then this:

Then, and who knows why, I got the crazy idea that I should submit to the BSidesLV Proving Ground program, where newbie speakers are paired with mentors. Then the crazy stuff happened, and both  talks were accepted. (what?!?!) At which point I'm fairly sure I had a few days believing that I was dreaming or something and I'd wake up to reality shortly. But no, I had to write (or really modify) a talk.

This talk was a little hard since there was a lot of legal background to explain, and then a lot of speculation, and so I thought I'd try frontloading the legal theory this time. Not sure it worked so well. But, well, it was an approach.  My biggest problem prepping this time was that I love this legal area, and I have *too* *many* *thoughts* and it all feels important. Trying to pare back the amount of information, but still get across the key points, was hard. Not sure I came close to succeeding.

I wish I talked more about risk-utility balancing, because that makes all of products liability so interesting. And then that leads into social/policy goals of having it serve an insurance function, and... it all quickly spirals out into a lot of somewhat extraneous ideas.

I freaked out a lot about timing, and decided that using Power Point's presenter view, and knowing roughly what slide I wanted to be on at what point, was the way to go.  And then... somehow it was Saturday at 2 PM, and I was standing on a stage at an infosec con and talking to a room that was crazily not empty. For starting out feeling pretty confident, I was a nervous wreck by the end.

The firetalks were, well, very different- I ended that one feeling pretty pumped, but there was more audience interaction, and the back and forth with the judges right on stage. At BSides Charm, the lack of a clip mike kind of threw me (I should write some time about my first run in with clip mikes....), and how tall the podium was.

So, that was my experience with my first real conference talk. I'll try to blog along the way to BSidesLV, although there is also going to be bar prep going on this summer, so.... I'll have to frame blogging as "study procrastination" perhaps.