2 ms·

> reverse bounties and when it turns out someone missed a bug they lose their stake, etc That's a really good insight into the sort of implementation that's ne

> reverse bounties and when it turns out someone missed a bug they lose their stake, etc That's a really good insight into the sort of implementation that's needed. I'm wondering how we would design the incentive structure, and maybe gamify things, to encourage positive participation. For example, would we need people whose job it is to deliberately inject underhanded code to try catching out / testing the reviewers? These pen-testers would need a way to pre-commit to the fact that they were trying this (so an attacker couldn't turn around and say "just testing!" when they got caught), and a way to guarantee the underhanded code doesn't reach production even if the reviewers don't catch it. I still think the distributed reputation system is the hardest part (and would be one of the most useful things to happen to the web since TLS), but there definitely seems to be other hard problems ahead after that.

pas 5y ago
I think first we should simply try the good old altruistic build it and they'll come approach. Simply build a transparent, simple, easy to use system and get an agreeable group of people to start using it. I mean authors/contributors of top 1000 of npm packages. We already very explicitly trust them. (Sure not exactly for this kind of thing, but if there were a yarn/npm plugin that shows relevant GitHub code review comments, people might start writing those code review comments somewhere.) cargo-crev is very barebones, a bit hard to use, but the concept seems solid. https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/ > For example, would we need people whose job it is to deliberately inject underhanded code to try catching out / testing the reviewers? That seems ethically iffy. (Reminds me of the university study (from last year?) when they tried to push bugs into the Linux kernel on purpose to test this.) I guess life creates enough natural experiments for us anyway, so there's enough variance that allows for fishing for a signal. But of course with consent of the involved, sure, why not. It'd be a nice high-high-high level addition to the Simian Army. > doesn't reach production even if the reviewers don't catch it I think that's the hard part. If they commit to introducing a vulnerability, it has to be a vulnerability for the test to make sense, and ... at that point there's going to be a time window where it's present in the codebase. Of course it might make sense for projects that have a known release cadence and/or some kind of security policy which allows for notifying the maintainers and potentially all downstream affected, etc. > I still think the distributed reputation system is the hardest part (and would be one of the most useful things to happen to the web since TLS), but there definitely seems to be other hard problems ahead after that. Agreed :)

pas 5y ago

I think first we should simply try the good old altruistic build it and they'll come approach. Simply build a transparent, simple, easy to use system and get an agreeable group of people to start using it. I mean authors/contributors of top 1000 of npm packages. We already very explicitly trust them. (Sure not exactly for this kind of thing, but if there were a yarn/npm plugin that shows relevant GitHub code review comments, people might start writing those code review comments somewhere.) cargo-crev is very barebones, a bit hard to use, but the concept seems solid. https://web.crev.dev/rust-reviews/ https://web.crev.dev/rust-reviews/ > For example, would we need people whose job it is to deliberately inject underhanded code to try catching out / testing the reviewers? That seems ethically iffy. (Reminds me of the university study (from last year?) when they tried to push bugs into the Linux kernel on purpose to test this.) I guess life creates enough natural experiments for us anyway, so there's enough variance that allows for fishing for a signal. But of course with consent of the involved, sure, why not. It'd be a nice high-high-high level addition to the Simian Army. > doesn't reach production even if the reviewers don't catch it I think that's the hard part. If they commit to introducing a vulnerability, it has to be a vulnerability for the test to make sense, and ... at that point there's going to be a time window where it's present in the codebase. Of course it might make sense for projects that have a known release cadence and/or some kind of security policy which allows for notifying the maintainers and potentially all downstream affected, etc. > I still think the distributed reputation system is the hardest part (and would be one of the most useful things to happen to the web since TLS), but there definitely seems to be other hard problems ahead after that. Agreed :)