mirror of
https://github.com/PrivSec-dev/privsec.dev
synced 2024-12-22 21:01:34 -05:00
Minor typo fixes
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
parent
6e7ea212b9
commit
e20f1f3036
@ -1,2 +1,2 @@
|
||||
# privsec.dev
|
||||
A practical approach to privacy and security
|
||||
A practical approach to Privacy and Security
|
||||
|
@ -89,4 +89,4 @@ As discussed, focusing solely on advertising networks and relying solely on priv
|
||||
|
||||
Badness enumeration cannot provide any privacy guarantee and should not be relied upon against real threat actors. While things like ad blockers may help block the low hanging fruits that is common tracking domains, they are trivially bypassed by just using a new domain that is not on common blacklists, or proxying third-party tracking code on the first part domain. Likewise, antivirus software may help you quickly detect common malware with known signatures, but they can never fully protect you from said threat.
|
||||
|
||||
Another thing to keep in mind is that open-source software is not automatically private or secure. Malicious code can be sneaked into the package by the developer of the project, contributors, library developers or the person who compile the code. Beyond that, sometimes, a piece of open-source software may have worse security properties than its proprietary counterpart. An example of this would be traditional Linux desktops lacking verified boot, system integrity protection, or a full system access control for apps when compared to macOS. When doing threat modeling, it is vital that you evaluate the privacy and security properties of each piece of software being used, rather than just blindly trusting it because it is open-source.
|
||||
Another thing to keep in mind is that open-source software is not automatically private or secure. Malicious code can be sneaked into the package by the developer of the project, contributors, library developers or the person who compiles the code. Beyond that, sometimes, a piece of open-source software may have worse security properties than its proprietary counterpart. An example of this would be traditional Linux desktops lacking verified boot, system integrity protection, or a full system access control for apps when compared to macOS. When doing threat modeling, it is vital that you evaluate the privacy and security properties of each piece of software being used, rather than just blindly trusting it because it is open-source.
|
||||
|
@ -26,7 +26,7 @@ For the Privacy policy of GitHub, please check out [this link](https://docs.gith
|
||||
|
||||
We use Matrix as our primary communication method. Since Matrix is a Federated protocol, the privacy of our conversaion depends on that of your homeserver and the homeserver of your contact.
|
||||
|
||||
You should not have any expectation of privacy for your conversation in our public room, as anyone (be it a person or a bot) can access all of your messages and log them. Even if you "delete" your messages, it is merely a redaction request to the participating homeservers in the room, and any of them could choose to ignore said request.
|
||||
You should not have any expectation of privacy for your conversations in our public room, as anyone (be it a person or a bot) can access all of your messages and log them. Even if you "delete" your messages, it is merely a redaction request to the participating homeservers in the room, and any of them could choose to ignore said request.
|
||||
|
||||
Direct or private messages with individuals are end to end encrypted by default. However, the Matrix protocol does not provide any metadata protection, and homeserver admins know who you have been talking to, how often you talk to them, and so on.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user