I monitor the issue tracker and explore the source code from time to time. The developer posts on HN and seems to be committed to the project and everything it stands for.

I'm not sure if builds are reproducible though. I don't think the author would allow the extensions to be hijacked by malicious actors but it'd still be nice to be able to verify a packaged extension was built from a given git commit.

Reproducible builds for extensions is a good idea that I hadn't considered before.

Most browser extensions these days are just some JS zipped up with some metadata and maybe a few assets, right?

There might be trouble with minified JS, but I'd assume most optimizers/minifiers are either deterministic or could be configured that way.

For me it's honest author. I don't trust code, I trust people.

I used to trust the authors of unlock, adblock, adblock origins. But they all sold out. Why do you think this time it's different?

Gorhill isn't doing it for money, he's doing it because he believes in an internet where "user agent" means something. He engages in numerous ways with the community. You're sort of asking "How can I trust Gorhill?", and I guess my answer is "How can you trust _anyone_?" I trust Gorhill with this task more than I trust Mozilla, Google, Brave, or any extension put out by a company. Whether that level of trust exceeds a particular individual's thershold is a personal choice, naturally. To echo the sentiment above, I trust a person, but not code, and not companies. This approach is certainly not bulletproof, but it's the best I've found.

I can't be sure about that, of course. It works for now and that's all that matters. Someone might fork it if that would happen.

I feel it dreadful to think uBlock Origin might not be trustworthy after all.

But I can’t find any other reason why I don’t think that that isn’t the case.

There could always be more trust. But if you compare it to browsers from ad companies...

the number of eyes looking at it all the time.

How many people are looking at the code ? The github commits show only one active contributor.

I use uBlock Origin myself but I sometimes question the faith we place on open-source. We assume someone else is looking at the code.

It would be awesome if there was a volunteer financed code review group to review popular open source projects. I think I’m not the only one who would happily donate money to such a group for code reviews for various OSS projects. Initial code reviews would require a lot of effort, unless somehow automated, but after that it would be fairly easy to monitor and verify updates and changes to the code.

I wonder if EFF or somebody could issue a "verified" badge that apps could apply for, with a small fee to finance the devs doing the audits?

A prerequisite of that type of badge that I really wish existed is a standardized, interoperable protocol for curation. Instead of trying to solve the problem of malicious software with a walled garden app store, anyone should be able to publish their own curated list of software (or any type of project?). The core component is a crypto-signed statement like:

    { "curator": {
         name="Alice",
         pubkey="...",
         url="..."
      },
      "artifact": {
         type="software",
         name="Bob's App",
         version="1.2.3",
         published_file="bobapp-1.2.3.zip",
         published_file_sha256="...",
         published_file_url="..."
      },
      "statements": [
         { "type": "member_of_collection",
           "name": "Recommended Apps" },
         { "type": "attestation",
           "name": "Passed Audit FOO",
           ...audit info... }
       ]
    }

Publish lists of these (maybe RSS-ish style?), with sort of browsable/searchable/app-store-ish UI.

A key feature is verification. A user should be able to easily inspect the known "curator statements" for an app for the curators the subscribe to, and be able to run a "git fsck"-style validation that proves "this app really is the version that: passed the EFF's 'No Tracking' audit, is on reviewer Carol's 'Recommended' list, was rated "Teen" by the ESRB, and is on my friend Dave's 'Cool stuff you should try' list.

With such a system, anyone can perform an audit, and people can make their own decisions about what they want to trust.

Would this verification feature be similar to how keybase works? You post a "fingerprint" message to a host of public web sites (ie. Twitter, Facebook, GitHub Gist, etc.) that anyone use to verify your identity. The idea is that even if someone tried to impersonate you, they would have to take over all of your accounts in order to do so.

I like this idea and think it would be a great addition to the development world.

I love this idea and could get behind contributing.

Maybe on top of existing practice? Debian packages some addons [1], I don't know do they perform audit [2] on them.

[1] https://packages.debian.org/search?suite=default&section=all...

[2] https://www.debian.org/security/audit/auditing

Would be good training for apprentices too. Reading code is probably one of the best ways to learn. Granted, it could include a sophisticated and obfuscated backdoor, but I think it would still be caught.

I wouldn't be so sure that it's an inevitability that things would be caught.

The "underhanded C contest" [1] is a good example of this and something I like to point people to. From their about page:

>The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should perform some specific underhanded task that will not be detected by examining the source code.

If you go look around the hall of fame on that site, or just take a look at the contest winners, it's absolutely insane how subtle some of those exploits are. And shockingly (to me anyway) many of the exploits don't require C or use some quirk of C, they would work in many different languages, the first contest winner is a perfect example of that [2].

I can honestly say that for some of them, even if you told me there was an exploit in the code, I wouldn't be able to find them on my own.

And the scariest part is that almost all of the submissions to that contest have plausible deniability. They look like innocent bugs, typos, or small logic mistakes. Some even layer multiple small subtle changes which each on their own are completely fine but when all run together reveal big exploits.

[1] http://underhanded-c.org/

[2] http://underhanded-c.org/_page_id_14.html

Ok, those might indeed not be found. Only fair that they could take something from my wallet then.

That is an awesome site, thanks. Sadly the contest seems to have stopped in 2014.