[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10280 [Firefox Patch Issues]: Torbrowser shouldn't load flash into the process space by default
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs