Talk:One page write-up of project

cmbenner: I made changes throughout this overview to make it even simpler and more straightforward for policy-makers who have little time and little patience.

cmbenner Thanks for the write-up, Andrew. Not sure the best way to edit this so I just added my edits to Andrew's version and said where I did this below. Main thing: I think we should tell the policy-makers right off the bat what we're doing (our goal is to offer them solutions for improving security) and make the overview sort of dummy-proof. So I did that, take a look. Also, I think that Andrew's chapter should be #2 and following threats simply because it seems funny to me to explain the problem (threats) and then jump into a specific subset of solutions (Technical--Jack) and then back up to a higher level and overview the concept of responsibility for defense (Andrew) then go back into the nitty-grittier level of another subset of defense option, John's chapter, so I reordered them. Also, Andrew's chapter seems to be a nice introduction to more specific discussions of specific defenses. Feel free to disagree. apardoe Yes, my chapter might be a good "second introduction" chapter. Moving Jack's to third makes sense. I added references focusing on American laws w.r.t. legal liability of software vendors.[/apardoe]

User:JSpaith Another possible arragenment of chapters would be Santu->Jack->John->Caroline->Andrew. I think we're agreed Santu makes the most sense going first. My thought with putting Jack/John next are that we address solutions to this the problem from a technical standpoint. Then Caroline would address fixing the problem with regards to user education/process. So we'd be organized along threat->3 solutions to threat->responsibility if Jack/John/Caroline's ideas still aren't enough, rather than having possible solutions not in order.

cmbenner Other notes: (not all totally relevant to the one pager, but I figure, why make you jump elsewhere right now?) 1. To answer Santu's question, my chapter will be on an economic defense--would some sort of measuring system for judging software security, like the Common Criteria, help consumers understand it and therefore demand it. As much technical detail as I will attempt will be a simple explanation in layman's terms of what a set of measuring criteria like the Common Criteria actually measure to approximate security, what computer scientists think of their attempt to measure security, and why you can't definitely tell whether a piece of software is actually secure. I plan to talk to economists to understand why the Common Criteria aren't widely used as a way to for consumers to understand security and whether if they were, consumers would use them to chose security, and also talk to computer scientists to ask what they think of the Common Criteria.

2. I see potential for overlap here which I think we should keep in mind. For example John, Andrew and I want to talk about market incentives for companies to produce secure software I plan to focus specifically on consumer demand and how you create it. Does that overlap with what you have in mind Andrew or is yours more of a general overview of incentives? How about you John, are you looking at market incentives only as an alternative to licensing? Also, Andrew and John want to talk about liability issues--any overlap there? We can work out overlap in editing each other's pieces but the more we do now, the better, to avoid serious overlap with just a little bit of time to fix it at the end. I'll start a new page, called "writing the paper--discussion"--where we can keep each other updated on what we're saying, work out things like this, ask each other questions.

User:JSpaith I'm a natural candidate (my chapter more technical in nature) for avoiding market forces/enforcement issues so I'll leave this topic alone completely. The anti-licensing arguments get into software being a new field and us needing innovation, lack of best practices, and (not as strong to policy maker at least) that software engineers resent this.

3. Chapter length: aim for max 8 pages each give or take? 12 pt. Times New Roman?

4. A thought on Maurer's note from Friday on avoiding being too technical--I'm probably a good litmus test for you guys writing technical chapters since I only have general knowledge of CS. For example, I can only explain a buffer overflow in detail because someone told me about it recently (prior knowledge was simply I knew it was a means of entry for attackers into a program which is probably all a policy-maker knows and cares about.) To continue on that track, I don't know what integer overflows/underflows are and I'd guess algorithmic flaws are a bad choice of algorithm for accomplishing a particular task or badly designed algorithms. So now you have a sense of what sort of general knowledge policy-maker would have. So one thing that jumps out at me now is Santtu's discussion of the purely technical class of vulnerabilities: I'd suggest while writing this--and you were probably planning on thinking this way, but I'll just throw it out there--asking yourself each time: how much does a policy maker really need to know about how this particular vulnerablity works in order to make a sound policy decision (sound policy decisions being: require that engineers be licensed, or mandate that certain checks be done each time software is released, etc). As Maurer said, they care almost nothing for being educated about CS--they want to know only what they need to know to make decisions and they have no patience for detailed technical stuff or terms they don't understand unless they are explained well and briefly. Writing policy briefs can be tough in my experience!

Santtu -- Yeah, I took note of Maurer's comment and I'm planning on keeping technical details down -- I won't get into the nitty-gritty about the differences between stack and heap based buffer overruns for example. :) I was thinking more along the lines of using this progress of new technical vulnerabilities to point out that we can't just sit idle, even though we could at somepoint claim that we've conquerred all buffer overflows, there are new things to worry about.

5. A thought on the licensing chapter: will you consider the middle ground between licensing all software engineers vs. only those who make, say, commercial software, or some specific subset of all the software out there? i.e., I don't need to be licensed to build a bridge in my backyard for my kid to play on but I do to build the Golden Gate.

6. Deadline for roughs for us to turn into each other? Right before TG to read on the plane to Grandma's, say Wed. the 24th, which gives us 2.5 weeks? I'd say right after TG on Monday the 29th but that only gives us until that Friday, the 3rd, no weekends, to comment on each other's stuff and make fixes.

Santtu -- The 24th works for me. Less pressure for TG weekend!

7. Anyone up for writing a quick intro to trace a security exploit in 2014, as I think that would be a great way to start. Is that part of your idea Santtu for starting your chapter, or if not, would it be easy for someone to do? I'd volunteer, but I'm not the person to do this.

[[User::Santtu|Santtu]] -- Yeah, I think I'll start off with this. It should be a nice lead-in to talking about both the technical and non-technical threats, along the lines of "Story of an Attack: From a Technical Flaw to Thai PM's Heat-Stroke."

8. I added a quick note on my sources.

9. Possible title: I like something like what we have now: "Attack, Defense and Responsibility: Improving Cybersecurity before 2014."