{"id":"3bf5d72ece9d1b2181609d9658089b1288c73c02e3b853a21894c2340d9a34ef","pubkey":"b98ded4ceaea20790dbcb3c31400692009d34c7f9927c286835a99b7481a5c22","created_at":1750886908,"kind":1,"tags":[["e","5df782f3053d887241a083189a5e8d10b617a38ac6f9d05870ed9202b25018b6","","mention"],["p","b98ded4ceaea20790dbcb3c31400692009d34c7f9927c286835a99b7481a5c22","","mention"],["q","5df782f3053d887241a083189a5e8d10b617a38ac6f9d05870ed9202b25018b6"],["t","security"],["t","privacy"]],"content":"When it comes to choosing software I want, there are three \"No\"s that make the reviewed software an immediate fail:\n\n- No patches\n- No assurance\n- No trust\n\nIf your software is not regularly updated or responds inappropriately to #security disclosures, then you can assume it is not safe and can become even more unsafe in the future. This should also be heavily scrutinised by fork projects or projects with upstream dependencies or third-party libraries. If you are not able to take upstream patches or updated libraries in a timely manner, then your software should not be promoted with a commitment to security.\n\nAssurance is continuous assessment and review by security professionals to measure confidence that security controls are working as designed. Threat modelling, penetration testing / reverse engineering, security scanning and audits are methods to do this. Assurance helps discover vulnerabilities and potential room for improvement, which is a good thing since it leads to change and commitment to developing more secure software.\n\nAssurance matters because implementation is not always equal to the intended design. You can code something, read the code line by line and test / debug the feature and it may still have a security vulnerability, it just isnt known yet. Therefore, you should only use software you know is committed or receives regular audits. The frequency is completely up to your tolerance.\n\nSecurity assurance is heavy work and often can't be done alone by developers. Proprietary or corporate-sponsored products often have the benefit of assurance because they provide financial incentive (bounties) to make people choose to commit into discovering vulnerabilities to help secure the product. In open source, especially for smaller projects, this can often only be done by good will of users, or worse, isn't done at all. The most popular example, xz, only had their backdoor discovered thanks to goodwill of an eyed Microsoft employee.\n\nThis is where the controversial (for Nostr) take comes in, but this would also mean Windows and MacOS, Chrome and others are far more assured than esoteric software. Security professionals are far more likely to be targeting popular software for security assurance, NOT your small Linux distro you spent weeks 'ricing' through baskets of additional, far more esoteric software.\n\nThis isn't all bad news though. Open software benefits from being derived from already highly assured software, such as GrapheneOS and the upstream Android Open Source Project. Sometimes, especially with cryptography, it can be better not to DIY.\n\nNo trust is a given. You shouldn't use software if you don't trust it, their upstream / third party components or it's developers. I wouldn't decide to concede because that would be hypocritcal. \n\nThere are a lot of ways I decide what makes software trustworthy beyond these three No's, but they'd probably be better in something more long form.\n\n#privacy\n\nnostr:nevent1qqs9mauz7vznmzrjgxsgxxy6t6x3pdsh5w9vd7wstpcwmyszkfgp3dspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqsvctalz","sig":"c2886872c00b163fb6ef22bce59738f514a45330d5597b018038fc090c080779600af3cffb790b035abac9577930f03a5ef6ee4cb77e40e216e3aa6a5fc1be05"}