8 ms·

The build steps are provided as a GitHub action in the repo. You can audit the build pretty easily, or if you're super paranoid you can build it yourself by fol

The build steps are provided as a GitHub action in the repo. You can audit the build pretty easily, or if you're super paranoid you can build it yourself by following the build steps.

themerone 3y ago
Even if the app is trustworthy, it still adds an attack vector to your system. It could have a bug, or the certificate could be exploited by another program.
- anigbrowl 3y ago
  Equally true of every ad
  - lolinder 3y ago
    This would be a reasonable argument if there weren't many alternative ad blocking methods that don't require MITMing your TLS traffic.
    - rollcat 3y ago
      It's in no way worse than running a single browser extension with overly broad privileges. If this method of adblocking gains more traction (quite possible, as Google keeps moving to damage in-browser ad blockers), I expect the implementation to receive a lot more scrutiny. I think we have to face the reality that web browsers might no longer be considered "user" agents.
      - shiroiuma 3y ago
        >I think we have to face the reality that web browsers might no longer be considered "user" agents. Well obviously, if you keep insisting on using a browser made by Google, an ad company.
      - lolinder 3y ago
        > I think we have to face the reality that web browsers might no longer be considered "user" agents. If by "web browsers" you mean specifically Chrome, yes. Firefox, Brave, and others are all committed to supporting MV2, and will continue to serve my interests as a user for the foreseeable future.
      - lelanthran 3y ago
        > I think we have to face the reality that web browsers might no longer be considered "user" agents. I think too many techies are, much like yourself, contributing to the problem by refusing to move away from Chrome for "reasons"[1], and then compounding it by refusing to acknowledge that "web browsers" != "Google Chrome". [1] The "reasons" are of dubious quality. Myself and many others are able to do all normal web-browsing from firefox or firefox forks with no functional or performance degradation.
        rollcat 3y ago
        > I think too many techies are, much like yourself, contributing to the problem by refusing to move away from Chrome [...] Contrary to your assumptions, I've been quite vocal against the Chrome/Blink monoculture for a while. Unfortunately there is a legit case for it; several generations of "low-end" devices (anything older than 10 years basically), that are still quite capable and in common use, where the difference in performance between Firefox and Chromium becomes quite noticeable, especially as you try to watch video. I don't think the problem is "techies", we have zero influence outside our own circles - see the historical rates of Linux adoption. The problem is we need the good ol' hammer of antitrust to start swinging again. We also need the regulators to be smart; if we get really unlucky, they will target iOS Safari instead. (This would be good in a healthy ecosystem, but would only serve to further entrench Google's position in the current situation.) By the way, using a filtering/rewriting proxy has other merits, especially on said older hardware; you can rewrite the entire web page to make it more lightweight and accessible. Check out miniwebproxy[1] and medium-rare[2]. It's also quite simple to write one; you need maybe a hundred lines of Go to start getting results. I've been experimenting with integrating Readability[3][4]; and I think there's more potential to this approach. [1]: https://humungus.tedunangst.com/r/miniwebproxy https://humungus.tedunangst.com/r/miniwebproxy [2]: https://humungus.tedunangst.com/r/medium-rare https://humungus.tedunangst.com/r/medium-rare [3]: https://github.com/go-shiori/go-readability https://github.com/go-shiori/go-readability [4]: https://github.com/mozilla/readability https://github.com/mozilla/readability
        lelanthran 3y ago
        > Contrary to your assumptions, I've been quite vocal against the Chrome/Blink monoculture for a while. I apologise for my incorrect assumptions. What browser are you reading this on, right now?
    - zzo38computer 3y ago
      I think it is a mistake for programs that have SSL traffic to not have an option for a user-defined non-secure proxy (usually this would be for a proxy running on the local computer, rather than a remote proxy). A non-secure proxy would save energy (since then it doesn't need to decrypt and encrypt it twice) as well as allowing use of newer (or older) cipher methods in programs that do not support them.
sedatk 3y ago
How do you know that the downloaded binaries are built by the GitHub action? If I must audit the code and build it myself every release, then how is this a usable product?
- Centigonal 3y ago
  Where is the bar for software you trust? do you trust your OS, router firmware, VPN client, web browser, etc?
  - sedatk 3y ago
    In fact, that's what I'm trying to say. The line we draw at "hey we can at least audit open source" is a fully imaginary one. It's a false comfort we create. It's the Kool-Aid we drink. I don't have any trust in any of those components you mentioned, but I came to terms with the risks associated with using them as part of my threat model. However, I find the notion that open source is somewhat safer because "we can audit it" exaggerating if not misleading. It's not a valid argument, and it should never be used because there's no way to do it in an either practical or consistent way for the users of the said product.
    - hnfong 3y ago
      There's a difference between "you/I can audit it" and "we (collectively) can audit it". You're not living in a vacuum. The more users (and perhaps more importantly, contributors) an open source product has, the less likely it has intentional backdoors built into it.
      - sedatk 3y ago
        What's your process to validate if that said software has been collectively audited sufficiently?
    - axelthegerman 3y ago
      Yes that's fair, however that's how our complex world works. E.g. we rely on journalism (the real kind) to uncover all kind of scummy behavior. Similar in the OSS world. There is no way to easily verify that unless some trusted bodies do this for us and publish their work specifically for what you're using. Now you just have been stating a problem and no solution. I do agree with you though that "hey it's OSS and easy to verify because we have the code" is indeed lying to ourselves and especially tools with privileges like this (MITM your encrypted traffic) should not be taken that lightly and have the proper warnings, disclaimer and attention (to watch for bad behavior)
godelski 3y ago
> You can audit the build pretty easily, Please define "easily"

The build steps are provided as a GitHub action in the repo. You can audit the build pretty easily, or if you're super paranoid you can build it yourself by following the build steps.

themerone 3y ago

Even if the app is trustworthy, it still adds an attack vector to your system. It could have a bug, or the certificate could be exploited by another program.

anigbrowl 3y ago
Equally true of every ad
- lolinder 3y ago
  This would be a reasonable argument if there weren't many alternative ad blocking methods that don't require MITMing your TLS traffic.
  - rollcat 3y ago
    It's in no way worse than running a single browser extension with overly broad privileges. If this method of adblocking gains more traction (quite possible, as Google keeps moving to damage in-browser ad blockers), I expect the implementation to receive a lot more scrutiny. I think we have to face the reality that web browsers might no longer be considered "user" agents.
    - shiroiuma 3y ago
      >I think we have to face the reality that web browsers might no longer be considered "user" agents. Well obviously, if you keep insisting on using a browser made by Google, an ad company.
    - lolinder 3y ago
      > I think we have to face the reality that web browsers might no longer be considered "user" agents. If by "web browsers" you mean specifically Chrome, yes. Firefox, Brave, and others are all committed to supporting MV2, and will continue to serve my interests as a user for the foreseeable future.
    - lelanthran 3y ago
      > I think we have to face the reality that web browsers might no longer be considered "user" agents. I think too many techies are, much like yourself, contributing to the problem by refusing to move away from Chrome for "reasons"[1], and then compounding it by refusing to acknowledge that "web browsers" != "Google Chrome". [1] The "reasons" are of dubious quality. Myself and many others are able to do all normal web-browsing from firefox or firefox forks with no functional or performance degradation.
      - rollcat 3y ago
        > I think too many techies are, much like yourself, contributing to the problem by refusing to move away from Chrome [...] Contrary to your assumptions, I've been quite vocal against the Chrome/Blink monoculture for a while. Unfortunately there is a legit case for it; several generations of "low-end" devices (anything older than 10 years basically), that are still quite capable and in common use, where the difference in performance between Firefox and Chromium becomes quite noticeable, especially as you try to watch video. I don't think the problem is "techies", we have zero influence outside our own circles - see the historical rates of Linux adoption. The problem is we need the good ol' hammer of antitrust to start swinging again. We also need the regulators to be smart; if we get really unlucky, they will target iOS Safari instead. (This would be good in a healthy ecosystem, but would only serve to further entrench Google's position in the current situation.) By the way, using a filtering/rewriting proxy has other merits, especially on said older hardware; you can rewrite the entire web page to make it more lightweight and accessible. Check out miniwebproxy[1] and medium-rare[2]. It's also quite simple to write one; you need maybe a hundred lines of Go to start getting results. I've been experimenting with integrating Readability[3][4]; and I think there's more potential to this approach. [1]: https://humungus.tedunangst.com/r/miniwebproxy https://humungus.tedunangst.com/r/miniwebproxy [2]: https://humungus.tedunangst.com/r/medium-rare https://humungus.tedunangst.com/r/medium-rare [3]: https://github.com/go-shiori/go-readability https://github.com/go-shiori/go-readability [4]: https://github.com/mozilla/readability https://github.com/mozilla/readability
        lelanthran 3y ago
        > Contrary to your assumptions, I've been quite vocal against the Chrome/Blink monoculture for a while. I apologise for my incorrect assumptions. What browser are you reading this on, right now?
  - zzo38computer 3y ago
    I think it is a mistake for programs that have SSL traffic to not have an option for a user-defined non-secure proxy (usually this would be for a proxy running on the local computer, rather than a remote proxy). A non-secure proxy would save energy (since then it doesn't need to decrypt and encrypt it twice) as well as allowing use of newer (or older) cipher methods in programs that do not support them.

sedatk 3y ago

How do you know that the downloaded binaries are built by the GitHub action? If I must audit the code and build it myself every release, then how is this a usable product?

Centigonal 3y ago
Where is the bar for software you trust? do you trust your OS, router firmware, VPN client, web browser, etc?
- sedatk 3y ago
  In fact, that's what I'm trying to say. The line we draw at "hey we can at least audit open source" is a fully imaginary one. It's a false comfort we create. It's the Kool-Aid we drink. I don't have any trust in any of those components you mentioned, but I came to terms with the risks associated with using them as part of my threat model. However, I find the notion that open source is somewhat safer because "we can audit it" exaggerating if not misleading. It's not a valid argument, and it should never be used because there's no way to do it in an either practical or consistent way for the users of the said product.
  - hnfong 3y ago
    There's a difference between "you/I can audit it" and "we (collectively) can audit it". You're not living in a vacuum. The more users (and perhaps more importantly, contributors) an open source product has, the less likely it has intentional backdoors built into it.
    - sedatk 3y ago
      What's your process to validate if that said software has been collectively audited sufficiently?
  - axelthegerman 3y ago
    Yes that's fair, however that's how our complex world works. E.g. we rely on journalism (the real kind) to uncover all kind of scummy behavior. Similar in the OSS world. There is no way to easily verify that unless some trusted bodies do this for us and publish their work specifically for what you're using. Now you just have been stating a problem and no solution. I do agree with you though that "hey it's OSS and easy to verify because we have the code" is indeed lying to ourselves and especially tools with privileges like this (MITM your encrypted traffic) should not be taken that lightly and have the proper warnings, disclaimer and attention (to watch for bad behavior)

godelski 3y ago

> You can audit the build pretty easily, Please define "easily"