privacyguides/i18n
1
0
Fork 0
mirror of https://github.com/privacyguides/i18n.git synced 2025-08-19 21:24:47 +00:00
Code Activity

New Crowdin translations by GitHub Action

Browse Source
This commit is contained in:
Crowdin Bot
2025-08-07 13:44:17 +00:00
parent 6983a79ab2
commit fb5879b670
2 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
i18n/cs/basics/common-threats.md
View File

@@ -130,20 +130,20 @@ Tyto druhy útoků mohou vyžadovat mnoho času a příprav k tomu, aby byly usk
Problém samozřejmě spočívá v tom, že poskytovatel služby (nebo hacker, který se nabourá do serveru) může vaše zprávy číst kdykoliv a jakkoliv chce, a to niž byste o tom věděli. To platí pro mnoho běžných služeb, jako jsou např. SMS zprávy, Telegram nebo Discord.
Thankfully, E2EE can alleviate this issue by encrypting communications between you and your desired recipients before they are even sent to the server. The confidentiality of your messages is guaranteed, assuming the service provider doesn't have access to the private keys of either party.
Tento problém může naštěstí zmenšit E2EE tím, že šifruje komunikaci mezi vámi a zamýšleným příjemcem, ještě než je odeslána na server. Důvěrnost vašich zpráv je zaručena za předpokladu, že poskytovatel služby nemá přístup k soukromým klíčům ani jedné strany.
<div class="admonition note" markdown>
<p class="admonition-title">Note on Web-based Encryption</p>
<p class="admonition-title">Poznámka k šifrování na webu</p>
In practice, the effectiveness of different E2EE 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 introduce a [backdoor](https://en.wikipedia.org/wiki/Backdoor_(computing)) in their application—in an attempt to steal your private keys—it could later be detected with [reverse engineering](https://en.wikipedia.org/wiki/Reverse_engineering).
V praxi se efektivita různých E2EE implementací liší. Aplikace jako je [Signal](../real-time-communication.md#signal) běží přímo na vašem zařízení a každá kopie aplikace je stejná napříč různými instalacemi. Pokud by poskytovatel služby zanesl [zadní vrátka](https://cs.wikipedia.org/wiki/Zadn%C3%AD_vr%C3%A1tka) do jejich aplikace – ve snaze ukrást vaše soukromé klíče – bylo by možné to zjistit pomocí [reverzního inženýrství](https://cs.wikipedia.org/wiki/Reverzn%C3%AD_in%C5%BEen%C3%BDrstv%C3%AD).
On the other hand, web-based E2EE implementations, such as Proton Mail's web app or Bitwarden's *Web Vault*, rely on the server dynamically serving JavaScript code to the browser to handle cryptography. A malicious server can target you and send you malicious JavaScript code to steal your encryption key (and it would be extremely hard to notice). Because the server can choose to serve different web clients to different people—even if you noticed the attack—it would be incredibly hard to prove the provider's guilt.
Na druhou stranu, webové implementace E2EE, např. u webové aplikace Proton Mail nebo *Web Vault* od Bitwardenu, se spoléhají na server, který dynamicky doručuje JavaScriptový kód prohlížeči, pomocí kterého pracuje s kryptografií. Škodlivý server vás může zacílit a poslat vám škodlivý JavaScriptový kód, který ukradne vaše šifrovací klíče (a bylo by velmi těžké to zaznamenat). Jelikož server může podstrčit různého klienta různým lidem, i kdybyste si útoku všimli, bylo by velmi obtížné dokázat poskytovateli jeho zavinění.
Therefore, you should use native applications over web clients whenever possible.
Proto byste měli používat nativní aplikace místo webových klientů, kdykoliv je to možné.
</div>
Even with E2EE, service providers can still profile you based on **metadata**, which typically isn't protected. While the service provider can't read your messages, they can still observe important things, such as whom you're talking to, how often you message them, and when you're typically active. Protection of metadata is fairly uncommon, and—if it's within your [threat model](threat-modeling.md)—you should pay close attention to the technical documentation of the software you're using to see if there's any metadata minimization or protection at all.
I v případě E2EE vás ale mohou poskytovatelé služeb profilovat na základě **metadat**, která obvykle chráněná nejsou. While the service provider can't read your messages, they can still observe important things, such as whom you're talking to, how often you message them, and when you're typically active. Protection of metadata is fairly uncommon, and—if it's within your [threat model](threat-modeling.md)—you should pay close attention to the technical documentation of the software you're using to see if there's any metadata minimization or protection at all.
## Mass Surveillance Programs

10
i18n/ja/advanced/dns-overview.md
View File

@@ -299,15 +299,15 @@ graph TB
## DNSSECとは？
[Domain Name System Security Extensions](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) (DNSSEC) is a feature of DNS that authenticates responses to domain name lookups. It does not provide privacy protections for those lookups, but rather prevents attackers from manipulating or poisoning the responses to DNS requests.
[DNS Security Extensions](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)（DNSSEC）はドメイン名検索に対する応答を認証するDNSの機能です。 検索に対してプライバシー保護を行うものではなく、 攻撃者がDNSリクエストに対する応答を操作したり、ポイズニングしたりすることを防ぐものです。
In other words, DNSSEC digitally signs data to help ensure its validity. In order to ensure a secure lookup, the signing occurs at every level in the DNS lookup process. As a result, all answers from DNS can be trusted.
言い換えれば、DNSSECはデータの正当性を保証するために、データにデジタル署名を行うものです。 安全な検索を保証するため、DNSルックアップのプロセスの各レベルで署名が行われます。 その結果、DNSからのすべての応答を信頼することができます。
The DNSSEC signing process is similar to someone signing a legal document with a pen; that person signs with a unique signature that no one else can create, and a court expert can look at that signature and verify that the document was signed by that person. These digital signatures ensure that data has not been tampered with.
DNSSECの署名プロセスは法的文書にペンで署名することに似ています。ある人は他の人が作成できない固有の署名をし、裁判所の専門家はその署名を見て、文書がその人によって署名されたことを検証します。 デジタル署名はデータが改ざんされていないことを保証します。
DNSSEC implements a hierarchical digital signing policy across all layers of DNS. For example, in the case of a `privacyguides.org` lookup, a root DNS server would sign a key for the `.org` nameserver, and the `.org` nameserver would then sign a key for `privacyguides.org`’s authoritative nameserver.
DNSSECはDNSのすべてのレイヤーにわたり、階層的なデジタル署名ポリシーを実装しています。 例えば、`privacyguides.org`を検索する場合、ルートDNSサーバーは`.org`ネームサーバーの鍵に署名し、`.org`ネームサーバーは`privacyguides.org`の権威ネームサーバーの鍵に署名します。
<small>Adapted from [DNS Security Extensions (DNSSEC) overview](https://cloud.google.com/dns/docs/dnssec) by Google and [DNSSEC: An Introduction](https://blog.cloudflare.com/dnssec-an-introduction) by Cloudflare, both licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0).</small>
<small>Googleの[DNS Security Extensions（DNSSEC）の概要](https://cloud.google.com/dns/docs/dnssec)およびCloudflareの[DNSSEC: An Introduction](https://blog.cloudflare.com/dnssec-an-introduction)を引用しています。両方とも[CC BY 4.0](https://creativecommons.org/licenses/by/4.0)の下でライセンスされています。</small>
## What is QNAME minimization?