On 29/11/2009 18:28, Adam Barth wrote:
On Sat, Nov 28, 2009 at 11:51 PM, Kálmán „KAMI” Szalai
<kami...@gmail.com> wrote:
Adam Barth írta:
It's important to separate two concerns:
1) Malicious extensions
2) Honest extensions that have vulnerabilities (benign-but-buggy)
I agree that the malicious extension problem is somewhat intractable
because of the above concerns. However, than news article is
complaining about vulnerabilities in honest extensions.
And How can we avoid the Malicious extensions problems'.
I'm not sure. That's a hard problem, but we can still make progress
on the benign-but-buggy case.
there are two popular ways to deal with this:
* beforehand - review
* afterwards - punishment
The good thind thing about "beforehand - review" is that it is
understandable. The bad thing is that it doesn't scale very well, and
when it comes to user code, there aren't that many people who want to go
trawling through looking for yet more bugs in someone else's code. "I'd
rather write it myself." Or, at the best, the work falls on some, the
benefits on others (e.g., see over on the policy group for their review
process, where the tiniest operators pay for the reviews of the largest
operators).
In contrast, the notion of "afterwards - punishment" is a lot less
understandable. There appear to be two popular ways: reputation and
the long reach of the law. Reputation can be used to damn a developer.
The law can either lock him up or charge him all his profits.
It is this part that is often wrapped up in the so-called identity or
trust business. If you know the guy's name, so the concept goes, you
can be safe, because if something goes wrong, you pass his name to the
Feds or the Mounties (they always get their man). Or, you damn him to
all time on the mailing lists.
But this is specious. For a start, he might be outside the Feds
location, and we know how they never ever break the rules and cross the
borders. Or he might be a she, and the Mounties are stumped. Or it
might be a false name. Or or or....
It does have one advantage: You can collect these names far more
efficiently than you can review code. And, the cost falls on the
developer not someone else. So we could say that the system scales very
well, as long as it rarely needs to be called upon.
So what to do? One thing that does look better than either path is a
mixture of both. A small amount of identity and a small amount of
review. That is, once you've got your small identity handle, and it
relates to a small amount of review, another vista opens up: Alice
can't get her code reviewed, it's not even allowed in the Queue ...
until she's reviewed Bob's code. Or some metric.
Beyond spreading the load of the review, it also gives the review teeth.
If the reviewee's code turns out to be bad, the reviewer's reputation
could suffer. Which also points the bone of fear at the reviewer's own
code.
This method is called the web of trust. The word trust there is a
misnomer ... we all think of trust as good, so putting it in there is a
standard marketing trick to make us think this is good. But no matter
that; the WoT allows the work of several people to relate to the work
of other people. In a way that is shared, cheap, scaleable, and
community. Developers working for developers; hey, isn't that what
it's about?
iang
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
