Talk:Student Projects:Most Secure Platform

From CSEP590TU
Jump to: navigation, search

Jesse Ruderman: I am evidence that open-source attracts "eyeballs" to find security holes: I have found over 60 security holes in Mozilla and Firefox. Ironically, I find most holes by trying to break binaries, not by inspecting source code.

[[User::Ericvan]]: Prof. Maurer clarifies who our audience will be:

The model is a white paper for government policy makers -- presidents and congressmen -- who are smart college grads without any particular tech background. Your audience has the patience to read plain English explanations carefully, but won't bother with jargon or technical details that amuse tech folk. They don't want to be lobbied, but if there incontrovertible facts (not "everybody thinks" but "it can be shown . . .") then they want to know them. And of course they want to know their options and the benefits/drawbacks associated with each.

If you try to write such a treatment, you'll find that the exercise in trying to speak plainly forces you re-think and learn about what you have to say. As Einstein said, "Everything should be made as simple as possible but no simpler." Or as Richard Feynman once said,"We must not really understand the subject -- I tried to prepare a freshman lecture and couldn't."

If you want to see models, look at any of the thousands of reports of www.nas.edu or the American Physical Society home page.

BTW, writing these papers is a time-honored way for making tech decisions in our society.

smm

--El-Gammal 15:44, 7 Nov 2004 (PST) Given that the target audience might not be immediately familiar with subject, I suggest we beef-up the introduction section with a brief description of OSS and contrast it to IP based, and add an abstract section at the beginning. So it could look something like this:

  1. Abstract
  2. Introduction
    1. History of Security
      1. Software applicability
      2. User perspective changes
    2. Why s/w security matters?
      1. Economics
      2. Homeland Security
      3. Other
    3. s/w vulnerability life cycle
    4. Open Source software
      1. History
      2. who makes it
      3. How it is developed
      4. who uses it
    5. Problems and limitations in evaluating s/w security