mirror of
https://github.com/PrivSec-dev/privsec.dev.git
synced 2024-12-29 09:06:30 -05:00
pPdate Threat Modeling page
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
parent
a96e6e946a
commit
ee61290b86
@ -93,6 +93,6 @@ As a beginner, you may often fall into some bad practices while making a threat
|
||||
|
||||
As discussed, focusing solely on advertising networks and relying solely on privacy policies does not make up a sensible threat model. When switching away from a service provider, try to determine what the root problem is and see if your new provider has any technical solution to the problem. For example, you may not like Google Drive as it means giving Google access to all of your data. The underlying problem here is the lack of end to end encryption, which you can solve by using an encryption tool like Cryptomator or by switching to a provider who provides it out of the box like Proton Drive. Blindly switching from Google Drive to a provider who does not provide end to end encryption like the Murena Cloud does not make sense.
|
||||
|
||||
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.
|
||||
You should also keep in mind that [badness enumeration does not work, cannot work, has never worked, and will never work](/knowledge/badness-enumeration/). While things like ad blockers and antiviruses may help block the low hanging fruits, they can never fully protect you from the threat. On the other hand, they often increase your attack surface and are not worth the security sacrifice. At best, they are merely covenience tools at best and should not be thought of as part of a defense strategy.
|
||||
|
||||
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.
|
||||
|
Loading…
Reference in New Issue
Block a user