privacyguides/privacyguides.org
1
0
Fork 0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-07-25 12:51:14 +00:00
Code Issues Activity

Update Proton products to Proton.me (#1319)

Browse Source 
Signed-off-by: Daniel Gray <dng@disroot.org>
This commit is contained in:
d4rklynk
2022-05-25 12:31:41 +00:00
committed by Daniel Gray
parent 9bb70d2e6b
commit 641f80db99
6 changed files with 40 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/basics/common-threats.en.md
View File

@@ -63,9 +63,9 @@ Thankfully, end-to-end encryption can alleviate this issue by encrypting communi
??? note "Note on web-based encryption"
In practice, the effectiveness of different end-to-end encryption implementations varies. Applications such as [Signal](../real-time-communication.md#signal) run natively on your device, and every copy of the application is the same across different installations. If the service provider were to backdoor their application in an attempt to steal your private keys, that could later be detected using reverse engineering.
On the other hand, web based end-to-end encryption implementations such as ProtonMail's webmail or Bitwarden's web vault rely on the server dynamically serving JavaScript code to the browser to handle cryptographic operations. A malicious server could target a specific user and send them malicious JavaScript code to steal their encryption key, and it would be extremely hard for the user to ever notice such a thing. Even if the user does notice the attempt to steal their key, it would be incredibly hard to prove that it is the provider trying to do so, because the server can choose to serve different web clients to different users.
On the other hand, web based end-to-end encryption implementations such as Proton Mail's webmail or Bitwarden's web vault rely on the server dynamically serving JavaScript code to the browser to handle cryptographic operations. A malicious server could target a specific user and send them malicious JavaScript code to steal their encryption key, and it would be extremely hard for the user to ever notice such a thing. Even if the user does notice the attempt to steal their key, it would be incredibly hard to prove that it is the provider trying to do so, because the server can choose to serve different web clients to different users.
Therefore, when relying on end-to-end encryption, you should choose to use native applications over web clients whenever possible.
Even with end-to-end encryption, service providers can still profile you based on **metadata**, which is typically not protected. While the service provider could not read your messages to see what you're saying, they can still observe things like who you're talking to, how often you message them, and what times you're typically active. Protection of metadata is fairly uncommon, and you should pay close attention to the technical documentation of the software you are using to see if there is any metadata minimization or protection at all, if that is a concern for you.