[tor-bugs] #10280 [Firefox Patch Issues]: Torbrowser shouldn't load flash into the process space by default

[Tor Bug Tracker & Wiki]

#10280: Torbrowser shouldn't load flash into the process space by default
-------------------------------------+-------------------------------------
     Reporter:  mikeperry            |      Owner:
         Type:  defect               |     Status:  needs_review
     Priority:  normal               |  Milestone:
    Component:  Firefox Patch        |    Version:
  Issues                             |   Keywords:  tbb-testcase,
   Resolution:                       |  MikePerry201402R
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+-------------------------------------
Changes (by cypherpunks):

 * type:  enhancement => defect


Comment:

 Replying to [comment:27 mikeperry]:
 > Replying to [comment:25 cypherpunks]:

 > In all seriousness though, I actually don't believe your claims to be
 the case at all. If these documents were separate (really they already
 nearly are - the requirements and implementation already are in separate
 sections), we *still* would not have had a requirement that plugins not
 have been loaded into the address space, ...

 Yes, this is correct.  A discussion would have happened still.  But the
 discussion at then point is more clear:  should we add this requirement,
 and how shall we word it?  Once that is done, then this automatically
 becomes a functional defect--no further discussion necessary.

 And then you can tract these things.  You can track that you had either:
 1. A defect in the requirements.
 2. A defect in the design.
 3. A defect in the code.

 Lower number means harder to fix.  Higher number, easier.

 This is a defect in the requirements, because you did not have a
 requirement that restricted this class of vulnerabilities, yet these are
 realistic vulnerabilities.

 >So no, having two pieces of paper instead of just one would not have
 saved us from this argument.

 Buy putting them in the same document, you make tracking changes in that
 document more complicated.  The documents should be revisioned and
 versioned--and in source control.  It should be clear who made what
 change.  This gets complicated if you obviously have diagrams and so on,
 and formatting, in the documents.  People use special software just for
 this--you could get by with a text file, or simply multiple versions on
 the file name, with text annotations of changes in the documents and in
 the commit summaries.

 Once that is done, a lot of things get easier.  You can read a slew of
 papers on this stuff.  For the most part, you will benifit in your
 projects with this approach because it is possible to completely spec
 everything out before hand--you are not like a startup needing "Agile"
 crap, because you have 10 clients that are all marketing people that don't
 know what they want, and keep calling you each day with requirements
 changes.  We know exactly what we want Tor Browser to do.  How it does it,
 is design.  Requirements changes should only be necessary in cases like
 this, where someone finds need for a new requirement based on an increased
 understanding of vulnerability surface, or because some new plugin or
 change to firefox comes out, or html5 comes out, or stuff like that.  Then
 you know where these requirements are coming from, and can document that.

 You then get the benifit of determining which designs cover which
 requirements, which code covers which requirements, and eventually can
 track bugs easier.

 It was calculated in the 1970's and 80's that every hour spent on
 requirements equals 100 hours less coding, and every hour on design, 10
 hours less coding.  (or something like that).

 So in one sentance (or so) please explain what this new requirement is,
 and add it to the requirements document (once you fix that up).  Thanks.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10280#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online