this post was submitted on 08 Jul 2023
28 points (68.9% liked)
Privacy
32156 readers
893 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@133arc585
The client-code is naturally open, while currently the core-engine is kept highly encrypted and we do not publish it (yet) as open-source.
There's a bit of a debate about pros & cons of opening it, regarding confidential comms.
Anyway we are independently pen-tested by volunteers.
Thanks for asking π
Why not? If you're 100% confident it's secure, you should have no issue making it public. If you aren't 100% confident its secure, not making it public is just dishonest and ends up hurting trust when something inevitably does happen. Also, what do you mean that the code is "highly encrypted"? First off, using phrases like "highly encrypted" and "military grade" are already massively suspicious because they're marketing terms that really don't mean anything. Second, keeping the code encrypted (at rest perhaps?) doesn't mean anything; and in order to run the code, it has to be un-encrypted anyway.
How so? Here are the possibilities:
There's no situation in which not releasing code helps security or trust. Security by obscurity is not security.
Which is fine as one facet of being verifiably secure, but it's not suffucient. Code can have flaws that pen-testers will not (or are very unlikely to) stumble upon, even with fuzzing environments. The proper approach is to have the code audited and openly-available and to have independent pen-testing of the running implementation.
Not that I was a potential user of your software to begin with, but the way you're describing your product and operations really would turn me off trusting it.
@133arc585
Thanks, I will share your feedback internally and get back to you with a more details π
@133arc585
Wishing to write more but limited at 500 chars... we are happy to get on board your constructive feedback. We are enthusiast of what we are doing but it takes time and a lot of work to improve. Feel free to contact us at [email protected] to expand the conversation. Regards
@133arc585
A brief feedback summary π
100% secure code is ideal but never the case: bugs, vulnerabilities, patches exist always. Hence, option one (100% secure) cannot be really considered in a real-world scenario.
Option two (not 100% secure) is not a binary choice: open-source is great but has wider implications other than peer/security review. Rights, alteration, distribution (etc) are to be considered too. We started with mixed open & closed source code, aiming to improve. Read next