mirror of
https://github.com/privacyguides/i18n.git
synced 2025-08-27 08:29:15 +00:00
New Crowdin translations by GitHub Action
This commit is contained in:
@@ -20,9 +20,7 @@ cover: real-time-communication.webp
|
||||
|
||||
{ align=right }
|
||||
|
||||
**Signal** 是Signal Messenger LLC所研发的一款手机应用。 这款应用提供即时通讯,语音通话以及视频通话。
|
||||
|
||||
所有的聊天窗口都有端到端加密(E2EE) 联系人列表使用你的Signal PIN码来保护,且服务器无法访问。 个人资料也经过加密,并只与你联系过的人共享。
|
||||
**Signal** 是Signal Messenger LLC所研发的一款手机应用。 The app provides instant messaging and calls secured with the Signal Protocol, an extremely secure encryption protocol which supports forward secrecy[^1] and post-compromise security.[^2]
|
||||
|
||||
[:octicons-home-16: Homepage](https://signal.org/){ .md-button .md-button--primary }
|
||||
[:octicons-eye-16:](https://signal.org/legal/#privacy-policy){ .card-link title="Privacy Policy" }
|
||||
@@ -44,7 +42,18 @@ cover: real-time-communication.webp
|
||||
|
||||
</div>
|
||||
|
||||
Signal 支持 [私密群组](https://signal.org/blog/signal-private-group-system/). 服务器没有你的群组成员资格,名称,头像以及其他属性的记录。 只有当 [加密发送(Sealed Sender)](https://signal.org/blog/sealed-sender/)启用时,Signal才会保存最少的元数据。 发信人地址与消息正文一起被加密,只有收信人的地址对服务器可见。 加密发送仅对你联系人列表中的人启用,你也可以对所有收件人启用,但是这么做会增加你收到垃圾邮件的风险。 Signal需要你的电话号码作为个人识别码。
|
||||
Signal requires your phone number for registration, however you should create a username to hide your phone number from your contacts:
|
||||
|
||||
1. In Signal, open the app's settings and tap your account profile at the top.
|
||||
2. Tap **Username** and choose **Continue** on the "Set up your Signal username" screen.
|
||||
3. Enter a username. Your username will always be paired with a unique set of digits to keep your username unique and prevent people from guessing it, for example if you enter "John" your username might end up being `@john.35`.
|
||||
4. Go back to the main app settings page and select **Privacy**.
|
||||
5. Select **Phone Number**
|
||||
6. Change the **Who Can See My Number** setting to: **Nobody**
|
||||
|
||||
You can optionally change the **Who Can Find Me By Number** setting to **Nobody** as well, if you want to prevent people who already have your phone number from discovering your Signal account/username.
|
||||
|
||||
Contact lists on Signal are encrypted using your Signal PIN and the server does not have access to them. 个人资料也经过加密,并只与你联系过的人共享。 Signal supports [private groups](https://signal.org/blog/signal-private-group-system/), where the server has no record of your group memberships, group titles, group avatars, or group attributes. 只有当 [加密发送(Sealed Sender)](https://signal.org/blog/sealed-sender/)启用时,Signal才会保存最少的元数据。 发信人地址与消息正文一起被加密,只有收信人的地址对服务器可见。 加密发送仅对你联系人列表中的人启用,你也可以对所有收件人启用,但是这么做会增加你收到垃圾邮件的风险。
|
||||
|
||||
Signal协议在2016年被独立[审计](https://eprint.iacr.org/2016/1013.pdf) 。 该协议的规范可以在他们的[文档](https://signal.org/docs/)查看。
|
||||
|
||||
@@ -115,14 +124,14 @@ The client software was independently [audited](https://briarproject.org/news/20
|
||||
|
||||
Briar has a fully [published specification](https://code.briarproject.org/briar/briar-spec).
|
||||
|
||||
Briar supports Forward Secrecy by using the Bramble [Handshake](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BHP.md) and [Transport](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BTP.md) protocol.
|
||||
Briar supports forward secrecy[^1] by using the Bramble [Handshake](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BHP.md) and [Transport](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BTP.md) protocol.
|
||||
|
||||
## Additional Options
|
||||
|
||||
<div class="admonition warning" markdown>
|
||||
<p class="admonition-title">警告</p>
|
||||
|
||||
These messengers do not have [Forward Secrecy](https://en.wikipedia.org/wiki/Forward_secrecy), and while they fulfill certain needs that our previous recommendations may not, we do not recommend them for long-term or sensitive communications. Any key compromise among message recipients would affect the confidentiality of **all** past communications.
|
||||
These messengers do not have forward secrecy[^1], and while they fulfill certain needs that our previous recommendations may not, we do not recommend them for long-term or sensitive communications. Any key compromise among message recipients would affect the confidentiality of **all** past communications.
|
||||
|
||||
</div>
|
||||
|
||||
@@ -160,7 +169,7 @@ Profile pictures, reactions, and nicknames are not encrypted.
|
||||
|
||||
Group voice and video calls are [not](https://github.com/vector-im/element-web/issues/12878) E2EE, and use Jitsi, but this is expected to change with [Native Group VoIP Signalling](https://github.com/matrix-org/matrix-doc/pull/3401). Group calls have [no authentication](https://github.com/vector-im/element-web/issues/13074) currently, meaning that non-room participants can also join the calls. We recommend that you do not use this feature for private meetings.
|
||||
|
||||
The Matrix protocol itself [theoretically supports PFS](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#partial-forward-secrecy), however this is [not currently supported in Element](https://github.com/vector-im/element-web/issues/7101) due to it breaking some aspects of the user experience such as key backups and shared message history.
|
||||
The Matrix protocol itself [theoretically supports forward secrecy](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#partial-forward-secrecy)[^1], however this is [not currently supported in Element](https://github.com/vector-im/element-web/issues/7101) due to it breaking some aspects of the user experience such as key backups and shared message history.
|
||||
|
||||
The protocol was independently [audited](https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last) in 2016. The specification for the Matrix protocol can be found in their [documentation](https://spec.matrix.org/latest/). The [Olm cryptographic ratchet](https://matrix.org/docs/matrix-concepts/end-to-end-encryption/) used by Matrix is an implementation of Signal’s [Double Ratchet algorithm](https://signal.org/docs/specifications/doubleratchet/).
|
||||
|
||||
@@ -195,11 +204,11 @@ Session uses the decentralized [Oxen Service Node Network](https://oxen.io/) to
|
||||
|
||||
Session allows for E2EE in one-on-one chats or closed groups which allow for up to 100 members. Open groups have no restriction on the number of members, but are open by design.
|
||||
|
||||
Session does [not](https://getsession.org/blog/session-protocol-technical-information) support PFS, which is when an encryption system automatically and frequently changes the keys it uses to encrypt and decrypt information, such that if the latest key is compromised it exposes a smaller portion of sensitive information.
|
||||
Session was previously based on Signal Protocol before replacing it with their own in December 2020. Session Protocol does [not](https://getsession.org/blog/session-protocol-technical-information) support forward secrecy.[^1]
|
||||
|
||||
Oxen requested an independent audit for Session in March of 2020. The audit [concluded](https://getsession.org/session-code-audit) in April of 2021, “The overall security level of this application is good and makes it usable for privacy-concerned people.”
|
||||
Oxen requested an independent audit for Session in March 2020. The audit [concluded](https://getsession.org/session-code-audit) in April 2021, “The overall security level of this application is good and makes it usable for privacy-concerned people.”
|
||||
|
||||
Session has a [whitepaper](https://arxiv.org/pdf/2002.04609.pdf) describing the technicals of the app and protocol.
|
||||
Session has a [whitepaper](https://arxiv.org/pdf/2002.04609.pdf) describing the technical details of the app and protocol.
|
||||
|
||||
## Criteria
|
||||
|
||||
@@ -212,17 +221,22 @@ We are working on establishing defined criteria for every section of our site, a
|
||||
|
||||
</div>
|
||||
|
||||
- Must have open-source clients.
|
||||
- Must use E2EE for private messages by default.
|
||||
- Must support E2EE for all messages.
|
||||
- Must have been independently audited.
|
||||
- Has open-source clients.
|
||||
- Does not require sharing personal identifiers (phone numbers or emails in particular) with contacts.
|
||||
- Uses E2EE for private messages by default.
|
||||
- Supports E2EE for all messages.
|
||||
- Has been independently audited.
|
||||
|
||||
### Best-Case
|
||||
|
||||
Our best-case criteria represents what we would like to see from the perfect project in this category. Our recommendations may not include any or all of this functionality, but those which do may rank higher than others on this page.
|
||||
|
||||
- Should have Forward Secrecy.
|
||||
- Should have open-source servers.
|
||||
- Should be decentralized, i.e. federated or P2P.
|
||||
- Should use E2EE for all messages by default.
|
||||
- Should support Linux, macOS, Windows, Android, and iOS.
|
||||
- Supports Forward Secrecy[^1]
|
||||
- Supports Future Secrecy (Post-Compromise Security)[^2]
|
||||
- Has open-source servers.
|
||||
- Decentralized, i.e. [federated or P2P](advanced/communication-network-types.md).
|
||||
- Uses E2EE for all messages by default.
|
||||
- Supports Linux, macOS, Windows, Android, and iOS.
|
||||
|
||||
[^1]: [Forward Secrecy](https://en.wikipedia.org/wiki/Forward_secrecy) is where keys are rotated very frequently, so that if the current encryption key is compromised, it does not expose **past** messages as well.
|
||||
[^2]: Future Secrecy (or Post-Compromise Security) is a feature where an attacker is prevented from decrypting **future** messages after compromising a private key, unless they compromise more session keys in the future as well. This effectively forces the attacker to intercept all communication between parties, since they lose access as soon as a key exchange occurs that is not intercepted.
|
||||
|
Reference in New Issue
Block a user