Edit: changed the link to an archive because the issue was made private.
5 Likes
Two* since Izzy in the replies does not seem to be leaving yet. I don’t know anything about the inner workings of F-Droid, but it doesn’t sound great…
5 Likes
Accrescent doesn’t check for proprietary code and non-free dependencies. It also doesn’t show anti-features like F-Droid does. You can even publish a proprietary app on Accrescent because there is no open-source requirement.
5 Likes
Open source != private, consider 1password is private. Moreover, tracker blocking makes much more sense at the DNS level than at the app level.
FLOSS is much more than just the ability to check the source code to see if there is any privacy violations, etc.
It’s also almost completely proprietary, so nobody knows how privacy-respecting 1Password is.
5 Likes
There’s more to open source than that, but that’s the only aspect that’s relevant to PG. The data sent by 1password is e2ee and this can be checked via mitmproxy or similar.
Well, the only reason why a proprietary password manager such as 1Password is recommended is out of desperation for more options. If 1Password was removed, then only Bitwarden would be left as an only cloud-based option. I can almost guarantee that when Proton Pass gets more mature, the 1Password recommendation will be removed and replaced with Proton Pass.
I also have to completely disagree that PG is only about privacy. PG team also cares about security, FOSS, data ownership, etc.
6 Likes
How could you check whether any proprietary software only does what it tells you?
EDIT: I am not saying whether it is a scam, but since it cannot be proven, my point is that nobody can say for sure that any proprietary software is perfectly safe to use at any point in any period of time.
1 Like
You can verify what the app sends using tools like mitmproxy. Once the data is on someone else’s server, you can’t know what they are doing with the data regardless of their source model. You have no way of verifying the code Bitwarden pushes is actually what they run behind bitwarden.com
3 Likes
E.g. reverse engineering (dynamic analysis, …) and network sniffing.
2 Likes
In addition to what’s already been explicitly mentioned, I really want to draw attention to fuzzing. This is a method that is extremely useful when it comes to testing out what a program does when given various inputs. You can even apply this to web APIs to varying degrees of success and it’s commonly used for FOSS programs too (see the fuzzing section in this blog post for some more details)
Accrescent, once stable, will do what F-Droid does but better since it has more security features and is actively maintained. It would be great if the departing F-Droid devs moved to develop Accrescent.
@clockwork
F-Droid.org has over 5,000 apps on it. It will take a long time for anyone else to catchup. And again, it doesn’t provide the same guarantees that fdo does.
I know I won’t put my apps on it.
4 Likes
No, Accrescent will never do what F-Droid does.
Accrescent is basically Play Store but better because it’s open source, doesn’t require an account, doesn’t invade user privacy, etc. But it doesn’t come close to what F-Droid does.
If there is an app store that has an inclusion policy like this:
And it also makes users aware of anti-features like this:
And if it also has and encourages reproducible builds, then I would be happy to hear about it.
3 Likes
archives because it has been marked private:
6 Likes
If you know the source on both ends, you would know for real how your data has been sent, and how the servers/nodes keep and process your data, also whether there’s any backdoor/hole to either end. Therefore, the source model is matter.
Reverse engineering is based on observations and assumptions, which are limited to:
- The tools necessary for a specific app.
- The complexity of the app.
- Time. It would probably be too late to actually catch something useful with this method. And since the app usually updates all the time, the re-engineering attempt is less relevant.
Network sniffing can’t be used to monitor servers/nodes activities.
Any suspicious party would probably know about this too. It wouldn’t be surprised if they invented ways to counter this method. If the code is open sourced, security flaws are found and patched by various party all the time, as bounties, hiring, or even from voluntary efforts.
- How do you know that the binaries running on both ends are actually from the source code? Most binaries haven’t been build with reproducible builds.
- Which system do you have in place to monitor that the code which is running is indeed the source code at all times? You would need a tamper proof live attestation system, which is not available, so you never know what is actually running.
- You simply make the assumption that it is easy to find backdoors or security holes if you have the source code. That’s not a valid assumption at all for any non-trivial project. Many open-source projects are full of security holes which sometimes only get discovered after decades, despite many people having access to the source code, even reputable ones like the Linux kernel.
- Even the assumption that it is the most easy way to find these via source code is wrong. It is ineffective and inefficient.
Or you could listen to people who actually work on cybersecurity, for example Matthew Garrett: ""You can't audit closed source software" is such …" - Nondeterministic Computer
2 Likes
All of the counter arguments above are simply saying that since having access to the source is not necessary a security benefit, so running the software without having access to the source should not matter, security-wise.
Well, it simply ignored the fact that by having access to the source you could:
-
Have an option to build a binary from source. Even if it is not 100% reproducible, you could still be able to verify that your build would act as it’s written in the source. This makes your point #1 and #2 muted. Whether everyone running binaries they built from sources is another point entirely, though.
-
Have an easier time finding backdoors(usually only proprietary software have backdoor implemented, since they didn’t release the source, thus were able to hide anything that could running at any period of time if they so wished to) and security holes.
I simply don’t understand your point #3 and #4. Why did you bring up the reverse engineering thing in the first place if you think that finding security issues through the source is pretty hard? Of course, no one said it’s easy, but it’s at least practically doable. On the other hand, trying to find those issues through reverse engineering would be 100x harder and 100x more time consuming, basically, far less effective and efficient than having the source at hand.
Therefore, I would assume you didn’t actually believe that finding security issues of proprietary software through reverse engineering is possible in reality, hence why everyone should using open source software in their workflow whenever it’s possible.
1 Like