[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:                       |
-------------------------------------+-------------------------------------

Comment (by mikeperry):

 Replying to [comment:28 cypherpunks]:
 > 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.

 Uh, that's exactly why I was so reluctant to do anything about this.
 Because this issue does *not* violate any of our design requirements.

 > So technically there are potentially three defects here--a defect in the
 requirements, once fixed, triggers defect in the design, and then the
 code.  Potentially three defects.  How does your design cover the new
 requirement/vunlerability class?  Does this trigger a re-design of
 something?
 >
 > And then you can track 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.

 Wow, you are indeed a rigid process wonk. I suppose RUP is your bible?
 Waterfall is the One True and Only Way? Do you like to sing the IBM
 company song before you get into bed? ;)

 I maintain this is not a design defect. Indeed, the requirements section
 is deliberately generalized, because it is meant to specify the minimal
 set of requirements for a browser to adhere to in Private Browsing Mode to
 such that we would consider that browser's Private Browsing Mode suitable
 for Tor. In fact, the requirements state exactly this.

 > >So no, having two pieces of paper instead of just one would not have
 saved us from this argument.
 >
 > With each ticket, you ask, is this an enhancement or defect?  You check
 the requirements.  If you cannot determine by checking the requirements,
 and it does not add new functionality, then there is a defect in the
 requirements.  This does not add new functionality, and the requirements
 are mute on this, so it is a defect.  In particular, the defect is that
 the security requirements are overly vague, and hence the designer did not
 catch this. "Is this a bug in requirements, design, or
 code/implementation?"

 This is not a bug. This is an enhancement in the implementation, if that.
 I have not yet heard a solid argument from *anyone* why this is a
 violation of our design requirements, let alone a bug.

 > You may have other projects that are more "Agile" like atlas, but Tor
 Browser is not one of them.  This is all a bit of an art form, and some
 people are great coders but suck at this.  Yet when you look at the
 figures, this stuff saves exponential time==$$.  Know your limitations and
 hire someone that knows what they are doing.
 >
 > You then get the benifit of determining which designs cover which
 requirements, which component, and which code covers which requirements,
 and eventually can track bugs easier, and determine responsible
 developers.
 >
 > Finally, you can get community feedback easier on requirements, then you
 can on a patch.
 >
 > 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).  The factors are usually the
 same for time fixing defects--so are you sure this fixes it?

 It was also realized in the late 90s and early 2000s that designing too
 much up front and expecting your foresight to be perfect can cause costly
 delays and lost release cycles. But again, we're not arguing about a
 design defect here. The requirements we specified are still fully valid.

 > 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.

 I am not fixing the design document. Please see
 https://www.torproject.org/projects/torbrowser/design/#DesignRequirements.
 This issue violates none of those. In fact, it doesn't even violate our
 philosophical guidelines.

 > [This puts me +100000XP which bumps me up to level 25 Bureaucrat btw. I
 am thinking of multi-classing.]

 You mean you're not already a full time bureaucrat? ;)

 I think we're actually on the same page here, more or less. You just want
 two pages, and you think this is a design defect. I think it is not a
 design defect, and therefore did not warrant Tor Project development time.

 Again, always happy to accept patches, though.

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