PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-11-18 20:41:33 -05:00
Code

Minor typo fixes

Browse Source 
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
Tommy 2022-07-19 00:13:43 -04:00 committed by tommytran732
parent 62b13beb37
commit 8b9640bb43
No known key found for this signature in database
GPG Key ID: 060B29EB996BD9F2
3 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -1,2 +1,2 @@
# privsec.dev
A practical approach to privacy and security
A practical approach to Privacy and Security

2
content/knowledge/Threat Modeling.md
View File

@ -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.

2
content/privacy.md
View File

@ -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.