Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only trustworthy extensions are uBlock Origin and EFF's Privacy Badger. Everything else is best viewed as potential malware, no different than random downloadable executables.

Honestly, uBlock Origin and Privacy Badger are so important at this point they should just become part of the browser itself. They're already in a league of their own.



I trust both of these extensions far more as extensions than I would if they were part of Chrome.


and that is why they will eventually be removed one way or another imo.


AFAIK Chrome will change ad blocking API and uBlock Origin won't follow it. So switch to Firefox.


These API changes are actually perfectly reasonable. The new API lets extensions tell the browser what to do to the page in a declarative manner. This eliminates the need to pass private user data to the extension code and reduces the potential for abuse. This is a massive improvement compared to just letting random extensions see everything on the page.

uBlock Origin just happens to be so important and trusted by the community that it shouldn't be subjected to these restrictions. It's a special case.


What makes uBlock Origin a trustworthy extension ? because it is open-source ?


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.


There are often other extensions that we find too precious to delete them, however we need them only at specific occasions. For those, I came up with a “meta-extension” to easily disable or enable them:

https://chrome.google.com/webstore/detail/extension-manager/...


This is great! But it is minified and there is no link to source. Why?


For those who like uBlock origin, you owe it to yourself to also checkout uMatrix. I use both.


Why not just use ublock origin in medium mode[0] (or hard mode[1] if you're so inclined)?

[0]https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...

[1]https://github.com/gorhill/uBlock/wiki/Blocking-mode:-hard-m...


I find it easier to understand what application wants looking at numbers. And to toggle on 1st party cookies. My setup in between hard mode and nightmare:

    * * * block
    * * frame block
    * 1st-party css allow
    * 1st-party frame allow
    * 1st-party image allow


I use both, and it's amazing what origin night let through that i can granularly stop with matrix.


> The only trustworthy extensions are uBlock Origin and EFF's Privacy Badger. Everything else is best viewed as potential malware, no different than random downloadable executables.

What about Ghostery?


They weren't always cool: https://www.businessinsider.com/evidon-sells-ghostery-data-t...

As far as I know this changed later on, but still.


I think it's "safe". They are not going to put a malware on their extension as you installing the extension is how they make money. But as the company has a business model around collecting your browsing data and being a gatekeeper between you and advertiser it really depends what you're trying to protect against.


Also HTTPS Everywhere and, in Firefox, NoScript.


I stopped considering NoScript something I can trust when this happened[1]. Many years have passed, the Tor project trusts it but I'm still cautious.

[1] http://www.schillmania.com/content/entries/2009/adblock-vs-n...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: