August 2017 - tor-commits - lists.torproject.org

[metrics-web/master] Link to new Tor bridge descriptors specification.
by karsten＠torproject.org 05 Aug '17

05 Aug '17

commit 8e15643cbcce09add914fe98905ec2117cf58b7d Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Sat Aug 5 22:23:04 2017 +0200 Link to new Tor bridge descriptors specification. --- .../src/main/resources/web/WEB-INF/collector.jsp | 83 +--------------------- website/src/main/resources/web/WEB-INF/sources.jsp | 11 +++ 2 files changed, 13 insertions(+), 81 deletions(-) diff --git a/website/src/main/resources/web/WEB-INF/collector.jsp b/website/src/main/resources/web/WEB-INF/collector.jsp index 4b37e5e..f57ccb8 100644 --- a/website/src/main/resources/web/WEB-INF/collector.jsp +++ b/website/src/main/resources/web/WEB-INF/collector.jsp @@ -366,89 +366,10 @@ descriptors, because that would defeat the purpose of making bridges hard to enumerate for censors. We therefore sanitize bridge descriptors by removing all potentially identifying information and publish sanitized versions here. -The sanitizing steps are as follows: +The sanitizing steps are specified in detail on a separate +<a href="bridge-descriptors.html">page</a>. </p> -<ol> -<li><b>Replace bridge identities with their digests:</b> Clients -can request a bridge's current descriptor by sending its identity string -to the bridge authority. -This is a feature to make bridges on dynamic IP addresses useful. -Therefore, the original identities (and anything that could be used to -derive them) need to be removed from the descriptors. -The bridge's RSA-based identity fingerprint is replaced with its SHA-1 -hash value, and the bridge's optional base64-encoded Ed25519 master key is -replaced with its SHA-256 digest. -The idea is to have a consistent replacement that remains stable over -months or even years (without keeping a secret for a keyed hash -function).</li> -<li><b>Remove most cryptographic keys and signatures:</b> It would be -straightforward to learn about the bridge identity from the bridge's -public key. -Replacing keys by newly generated ones seemed to be unnecessary (and would -involve keeping a state over months/years), so that most cryptographic -keys and signatures have simply been removed.</li> -<li><b>Replace IP address with IP address hash:</b> Of course, IP -addresses need to be sanitized, too. -<ul><li>IPv4 addresses are replaced with <code>10.x.x.x</code> with -<code>x.x.x</code> being the 3 byte output of -<code>H(IP address | bridge identity | secret)[:3]</code>. -The input <code>IP address</code> is the 4-byte long binary representation of -the bridge's current IP address. -The <code>bridge identity</code> is the 20-byte long binary representation of -the bridge's long-term identity fingerprint. -The <code>secret</code> is a 31-byte long secure random string that changes -once per month for all descriptors and statuses published in that month. -<code>H()</code> is SHA-256. -The <code>[:3]</code> operator means that we pick the 3 most significant bytes -of the result.</li> -<li>IPv6 addresses are replaced with <code>[fd9f:2e19:3bcf::xx:xxxx]</code> -with <code>xx:xxxx</code> being the hex-formatted 3 byte output of a similar -hash function as described for IPv4 addresses. -The only differences are that the input <code>IP address</code> is 16 bytes -long and the <code>secret</code> is only 19 bytes long.</li></ul></li> -<li><b>Replace TCP port with TCP port hash:</b> It may be less obvious -that TCP ports need to be sanitized, but an unusual TCP port used by a -high-value bridge might still stand out and provide yet another way to -locate and block the bridge. -Therefore, each non-zero TCP port is replaced with a number in the range -from 49152 to 65535 that is the result of -<code>H(port | bridge identity | secret)[:2] / 2^2 + 2^15 + 2^14</code> -written as decimal number. -The input <code>port</code> is the 2-byte long binary representation of the -TCP port. -The <code>bridge identity</code> is the 20-byte long binary representation of -the bridge's long-term identity fingerprint. -The <code>secret</code> is a 33-byte long secure random string that changes -once per month for all descriptors and statuses published in that month. -<code>H()</code> is SHA-256. -The <code>[:2]</code> operator means that we pick the 2 most significant bytes -of the result. -The subsequent integer division and additions make sure that sanitized -ports are in the range from 49152 to 65535 which is reserved for private -services. -All operations assume inputs to be in network byte order. -TCP ports that are 0 in the original descriptor are left unchanged.</li> -<li><b>Replace contact information:</b> If there is contact information in -a descriptor, the contact line is changed to -<code>somebody</code>.</li> -<li><b>Remove pluggable transport addresses and arguments:</b> Bridges may -provide transports in addition to the onion-routing protocol and include -information about these transports in their extra-info descriptors for -BridgeDB. -In that case, any IP addresses, TCP ports, or additional arguments are -removed, only leaving in the supported transport names.</li> -<li><b>Append descriptor digests:</b> Descriptors are often referenced by -their digest, but that is not possible anymore once their content has -changed. -As a workaround, sanitized descriptors contain a new line -<code>router-digest</code> with the hex representation of the SHA-1 of the -original descriptor digest excluding RSA signature and—if the bridge -uses an Ed25519 identity—a new line <code>router-digest-sha256</code> -with the base64-encoded SHA-256 of the SHA-256 digest of the original -descriptor including all signatures.</li> -</ol> - <h3 id="type-bridge-network-status" class="hover">Bridge Network Statuses <small><code>@type bridge-network-status 1.2</code></small> <a href="https://collector.torproject.org/recent/bridge-descriptors/statuses/" target="_blank" class="btn btn-primary btn-xs"><i class="fa fa-chevron-right" aria-hidden="true"></i> recent</a> diff --git a/website/src/main/resources/web/WEB-INF/sources.jsp b/website/src/main/resources/web/WEB-INF/sources.jsp index 43a926b..a0f5460 100644 --- a/website/src/main/resources/web/WEB-INF/sources.jsp +++ b/website/src/main/resources/web/WEB-INF/sources.jsp @@ -41,5 +41,16 @@ </ul> </div> + <div class="container"> + <h2>Specifications <a href="#specifications" name="specifications" class="anchor">#</a></h2> + <p>The following specification documents are available for Tor network data.</p> + <ul> + <li><a href="https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt" target="_blank">Tor directory protocol, version 3</a></li> + <li><a href="https://gitweb.torproject.org/torspec.git/tree/attic/dir-spec-v2.txt" target="_blank">Tor directory protocol, version 2</a></li> + <li><a href="https://gitweb.torproject.org/torspec.git/tree/attic/dir-spec-v1.txt" target="_blank">Tor directory protocol, version 1</a></li> + <li><a href="bridge-descriptors.html">Tor bridge descriptors</a></li> + </ul> + </div> + <jsp:include page="bottom.jsp"/>

1 0

[research-web/master] the request and response for the first research safety board case
by arma＠torproject.org 05 Aug '17

05 Aug '17

commit 0ed61edd319c7715c6b41707abaa33a2548bff88 Author: Roger Dingledine <arma(a)torproject.org> Date: Sat Aug 5 16:38:31 2017 -0400 the request and response for the first research safety board case --- htdocs/trsb/2016-01-request.txt | 195 +++++++++++++++++++++++++++++++++++++++ htdocs/trsb/2016-01-response.txt | 45 +++++++++ 2 files changed, 240 insertions(+) diff --git a/htdocs/trsb/2016-01-request.txt b/htdocs/trsb/2016-01-request.txt new file mode 100644 index 0000000..47e3ff4 --- /dev/null +++ b/htdocs/trsb/2016-01-request.txt @@ -0,0 +1,195 @@ + +Date: Thu, 18 Aug 2016 10:47:45 -0700 +From: David Fifield <david(a)bamsoftware.com> +To: Roger Dingledine <arma(a)mit.edu> +Cc: Lynn Tsai <lynntsai(a)gmail.com> +Subject: Tor Research Safety Board: default bridge reachability + +We're seeking comments on a continuation of our research on the blocking +of default Tor Browser bridges. What we've done so far on this subject +is covered in our FOCI 2016 paper, "Censors' Delay in Blocking +Circumvention Proxies": +https://www.bamsoftware.com/proxy-probe/ + +The short summary of what we want to do is to greatly expand our +measurement locations, by using existing platforms such as ICLab, OONI, +or RIPE Atlas. We want to start doing traceroutes in addition to TCP +reachability. We want to control how new bridges are introduced, in +order to test specific hypotheses, such as whether there is a difference +in detection between stable and alpha. + + +== What are you trying to learn, and why is that useful for the world? + That is, what are the hoped-for benefits of your experiment? + +1. Where the default bridges are blocked, globally. We know that China + (eventually) blocks them, and Iran (currently) does not; but we don't + know the situation anywhere else. +2. In places where the default bridges get blocked, the dynamics of + blocking, such as how long it takes, its granularity (IP only or + IP/port), and whether blocks are eventually removed. +3. How bridge addresses are discovered (e.g. through traffic analysis, + tickets, or source code), and how they are extracted (e.g. manually + or through automated parsing). + +The overarching, abstract benefit of the experiment is a better +understanding of censorship, leading to the development of better +informed circumvention. + +The latest bridge users' guide +(https://blog.torproject.org/blog/breaking-through-censorship-barriers-even-when-tor-blocked) +recommends using meek to users in China, because obfs4 is blocked. This +research would let us know whether to expand that advice beyond China. + +By comparing reachability timelines across many censors, we may find +evidence for or against censors sharing a common data source. For +example, if two countries block a set of bridges at the same moment, it +is probably because there is something in common in their detection. + +We may uncover specific operational weaknesses of censors that can be +exploited. To choose an invented but plausible scenario, maybe a censor +only does black-box testing of new bundles on the day of release: in +that case, the browser could avoid connecting to a subset of bridges +until after a certain date. + +If we are able to reachability publish data online on a frequently +updated basis, someone could use it to build a Weather-like service that +notifies operators of default bridges when their bridge stops running. +This happened a few times already: some of the default bridges stopped +running because of lost iptables rules after a reboot, and we were the +first to notice, only because we were looking at the graphs every once +in a while. (This would not always be possible using only Collector +data, because for example the bridge might be running, but its obfs4 +port closed because of a firewall misconfiguration.) + + +== What exactly is your plan? That is, what are the steps of your + experiment, what will you collect, how will you keep it safe, and so + on. + +So far, we have only run from a handful of VPSes, never more than 4 at a +time. We only had visibility into the U.S., China, and Iran. We +carefully watched for the introduction of new obfs4 bridges (in some +cases being privately informed in advance), and added them to a probe +list, which got probed every 20 minutes by a cron job on the VPSes. + +We want to greatly expand our probe sites, by using existing measurement +platforms such as ICLab, OONI, or RIPE Atlas. We hope to be able to +measure from dozens or hundreds of diverse locations. We have already +talked to ICLab and they are willing to probe our destinations from +their endpoints, which mostly consist of commercial VPNs in various +countries. The probes will consist of periodic TCP connections to Tor +Browser default obfs4 bridges (released and not-yet-released) and +control destinations. We want to start doing traceroutes as well. + +We expect that the TCP reachability data we collect will be similar to +what we have collected so far. It looks like this: + date,site,host,port,elapsed,success,errno,errmsg + 1449892115.2,bauxite,178.209.52.110,443,10.0101830959,False,None,timed out + 1449901202.36,eecs-login,192.30.252.130,443,0.0761489868164,True,, + 1450858800.18,eecs-login,109.105.109.165,24215,0.189998865128,False,146,[Errno 146] Connection refused +For traceroutes we will collect hop information (perhaps with some hops +obscured; see the risks in the next section). We expect to be able to +publish everything we collect in an immediate and ongoing basis. + +We also want to test some specific hypotheses by controlling the +circumstances of bridge release. Here are specific experiments we have +thought of (see corresponding risks in the next section): +a. Rotating bridge ports with every release. Since the GFW blocks based + on IP/port, we can try just changing the port number of each bridge + in every release (using iptables forwarding for example). +b. Putting different subsets of bridges in stable and alpha releases. We + saw that Orbot-only bridges did not get blocked; we wonder if + stable-only or alpha-only bridges also will not get blocked. +c. Leaving a bridge commented out in bridge_prefs.js. This may help us + distinguish between black-box testing and manual source code review. + + +== What attacks or risks might be introduced or assisted because of your + actions or your data sets, and how well do you resolve each of them? + +The main risk is potentially enabling censors to discover new bridge +addresses early, by monitoring our probe sites. Even though "default +bridges" are conceptually broken, they do in fact work for many people, +and we wouldn't want to reduce their utility. + +In our research so far, we've identified a number of ways that censors +can discover new bridges: by watching the bug tracker, by reading source +code, or by inspecting releases. Whenever possible, we want to start +monitoring new bridges even before they enter the bug tracker. If a +censor discovers one of our probe sites (which would not be hard to do), +then they could watch for new addresses being connected to and add them +to a blocklist. An adversary keeping netflow records could identify +probe sites retroactively: download Tor Browser and get the new bridges, +then find the clients that made the earliest connections to those +addresses. + +We mitigate this risk partially by only testing default bridges, not +secret BridgeDB bridges. That way, even if a censor discovers them, it +doesn't affect users of secret bridges. Also, we suspect that, because +default bridges are, in theory, easily discoverable, adding another +potential discovery mechanism of medium difficult does not greatly +increase the risk of their being blocked. + +If early blocking of bridges as a result of our experiment becomes a +problem, we can adjust the protocol, for example not to monitor bridges +in advance of their ticket being filed. + +Our heretofore published data do not include the IP addresses of the +probe locations. The people who supplied us with the probe locations +asked us not to reveal them. Traceroute will make it harder to conceal +the source of probes in our published data. We can, for example, omit +the first few hops in each trace, but we don't know the best practices +along these lines. The potential harm to probe site operators is +probably less when we use existing measurement platforms rather than +VPSes acquired through personal contacts. + +Our results may be contaminated by other experiments being run from the +same source address. The measurement platforms we propose to use already +are running various other experiments, so they may be treated +differently by firewalls. The most likely wrong outcome is that we +falsely detect a bridge being blocked, when it is really the client +address being blocked (because it is a VPN node, for example). The risk +goes in the other direction as well: our experiment might affect others +running on the same endpoint. + +Here are the risks related to testing the specific bridge-blocking +hypotheses enumerated in the previous section: +a. The risk in rotating bridge ports is that eventually the censor + catches on to the pattern and develops more sophisticated, automated + blocking. If the censor doesn't react, it means we have better + reachability; but if it does, we lose what small window of + post-release reachability we have. +b. The risk in segregating bridge addresses across stable and alpha is + that a network observer can tell which a user is running by observing + what addresses they connect to. This may, for example, enable them to + target an exploit that only works on a specific version. +c. The risk in playing games like commenting out bridge lines is slight: + a commented-out bridge may get blocked even before it has had any + real users. + + +== Walk us through why the benefits from item 1 outweigh the remaining + risks from item 3: why is this plan worthwhile despite the remaining + risks? + +The main risk, bridge discovery by censors, has low potential harm, and +can be mitigated if necessary by changing when we start monitoring +bridges, or even ceasing the experiment altogether. The risk of our +measurements is probably less than that of even having default bridges +in the first place, because our probes are not connected to any +real-world circumventor. + +The risks associated with our specific bridge-blocking hypotheses are +variable, and we would appreciate discussion on them. The one we planned +to try first is the commenting-out one, because it seems to have the +best risk/reward tradeoff. + +Incidentally, OONI already has a bridge_reachability nettest that is +similar to what we have proposed: +https://ooni.torproject.org/nettest/tor-bridge-reachability/ +However their bridge list is not up to date, +https://gitweb.torproject.org/ooni-probe.git/tree/var/example_inputs/bridges.txt?id=v1.6.1 +and a perusal of http://measurements.ooni.torproject.org/ shows that the +test is not being run regularly. + diff --git a/htdocs/trsb/2016-01-response.txt b/htdocs/trsb/2016-01-response.txt new file mode 100644 index 0000000..a77b7a5 --- /dev/null +++ b/htdocs/trsb/2016-01-response.txt @@ -0,0 +1,45 @@ + +Date: Fri, 16 Dec 2016 16:54:52 +0100 +From: "M. Tariq Elahi" <Tariq.Elahi(a)esat.kuleuven.be> +To: tor-research-safety(a)lists.torproject.org, david(a)bamsoftware.com, + lynntsai(a)gmail.com, QI ZHONG <zhongqi92(a)berkeley.edu> +Subject: Re: [tor-research-safety] (FWD) Tor Research Safety Board: default + bridge reachability + +Yesterday, I wrote to David et al. with a short summary of our review. +The tl;dr was that we (Damon McCoy and I) don't see anything +particularly wrong with their experimental setup and their proposed +research. Here is a less terse version of the review. + +Summary of request: + +The goal of the experiments is to gain more extensive empirical data +about how censors block Tor bridges. The experiments will measure where +in the world bridges are blocked, how many are blocked, how long before +they are blocked and other similar statistics and data points. The +overarching goal is to use this new found information to aid in better +bridge distribution schemes and censorship resistance in general. + +Experimental setup: + +Mainly the setup is to try to access bridges from many points on the +Internet (through VPS hosting providers) and record if they were +successfully connected to. There doesn't seem to be anything +particularly risky here. For bridges that do get burned because of these +probes we suggested that perhaps replacing them might be fair. + +Risks: + +The risk to users or the testing nodes do not seem high. The expected to +be released data does not contain identifying information. The risk to +public bridges is that they get blocked. However, as noted in the +request as well, bridges that are public are not particularly well +defended. However, this state of affairs seems to be OK in situations +where the censor is not actively trying to find bridges to block. + + +Recommendation: + +We believe that these experiments do not significantly increase the +threat level of the Tor network, its operators, or its clients. +

1 0

[translation/liveusb-creator] Update translations for liveusb-creator
by translation＠torproject.org 05 Aug '17

05 Aug '17

commit 24e6f7cf7ffa4129203a2c55ace4aeb159558df7 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Aug 5 17:15:42 2017 +0000 Update translations for liveusb-creator --- uk/uk.po | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/uk/uk.po b/uk/uk.po index 1629c4597..9606f8967 100644 --- a/uk/uk.po +++ b/uk/uk.po @@ -8,15 +8,15 @@ # LinuxChata, 2014-2015 # Maxim Baturov <baksbigboy(a)gmail.com>, 2017 # Maxim Dziumanenko <dziumanenko(a)gmail.com>, 2010 -# Vira Motorko <ato4ka(a)i.ua>, 2015 +# Vira Motorko <ato4ka(a)i.ua>, 2015,2017 # Андрій Бандура <andriykopanytsia(a)gmail.com>, 2014 msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2017-06-30 13:14+0200\n" -"PO-Revision-Date: 2017-07-19 10:30+0000\n" -"Last-Translator: Maxim Baturov <baksbigboy(a)gmail.com>\n" +"PO-Revision-Date: 2017-08-05 16:57+0000\n" +"Last-Translator: Vira Motorko <ato4ka(a)i.ua>\n" "Language-Team: Ukrainian (http://www.transifex.com/otf/torproject/language/uk/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -179,7 +179,7 @@ msgstr "Непідтримуваний пристрій '%(device)s', будь #: ../tails_installer/creator.py:952 msgid "Trying to continue anyway." -msgstr "Спроба все одно продовжити." +msgstr "Спроба все одно продовжити. " #: ../tails_installer/creator.py:961 ../tails_installer/creator.py:1354 msgid "Verifying filesystem..."

1 0

[nyx/master] Limit FAQ cursor to question
by atagar＠torproject.org 05 Aug '17

05 Aug '17

commit 44430d082c41d19d67bccb2f185904c43bbac130 Author: Damian Johnson <atagar(a)torproject.org> Date: Sat Aug 5 08:44:31 2017 -0700 Limit FAQ cursor to question Only showing the finger cursor when on the clickable question. This was mistakenly applied to the right, as well as some elements it contained too. --- web/styles.css | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/web/styles.css b/web/styles.css index a4421fe..fd92867 100644 --- a/web/styles.css +++ b/web/styles.css @@ -171,20 +171,19 @@ FAQ Page } .questions li { - cursor: pointer; margin: 0px; padding: 0px 0px 5px 0px; text-align: left; } .questions span { + cursor: pointer; color: #302000; font-size: 18px; font-weight: bold; } .answer { - cursor: default; height: 0px; overflow: hidden; padding: 0px;

1 0

[nyx/master] Hide PyPI download options for now
by atagar＠torproject.org 05 Aug '17

05 Aug '17

commit 0c21dec27b36dbd75675536ef7b04b0efcf4ce6e Author: Damian Johnson <atagar(a)torproject.org> Date: Sat Aug 5 08:41:57 2017 -0700 Hide PyPI download options for now Haven't actually uploaded to pypi yet, and won't until our release (or at least the beta). Dropping this from the download page for now to avoid confusion. --- web/index.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/web/index.html b/web/index.html index b65800b..d330554 100644 --- a/web/index.html +++ b/web/index.html @@ -307,6 +307,7 @@ sudo python setup.py install</pre><br></li> <br> +  <div class="platform"> <a href="http://packages.debian.org/sid/tor-arm" id="debian"><img src="images/download/debian.png" alt="Debian"></a>

1 0

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 05 Aug '17

05 Aug '17

commit 2c6b3a7c5a0c2730e56b30dbfcf1f3887da1ea37 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Aug 5 11:45:32 2017 +0000 Update translations for https_everywhere --- pt_BR/https-everywhere.dtd | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pt_BR/https-everywhere.dtd b/pt_BR/https-everywhere.dtd index 07698758f..e4748fca6 100644 --- a/pt_BR/https-everywhere.dtd +++ b/pt_BR/https-everywhere.dtd @@ -34,11 +34,11 @@ <!ENTITY https-everywhere.prefs.export_settings "Exportar Configurações"> <!ENTITY https-everywhere.prefs.settings_warning "Cuidado:"> <!ENTITY https-everywhere.prefs.settings_warning_delete "Algumas das configurações do seu HTTPS Everywhere estão prestes a serem apagadas!"> -<!ENTITY https-everywhere.prefs.settings_warning_explain "This extension will be upgraded substantially in the near future. If you do not export your settings, you could lose one or more of the following:"> -<!ENTITY https-everywhere.prefs.settings_global "Global preferences"> +<!ENTITY https-everywhere.prefs.settings_warning_explain "Esta extensão será significativamente atualizada em um futuro próximo. Caso você não exporte as suas configurações, poderá perder uma ou mais funções:"> +<!ENTITY https-everywhere.prefs.settings_global "Preferências gerais:"> <!ENTITY https-everywhere.prefs.settings_toggle "Per-site on/off setting"> <!ENTITY https-everywhere.prefs.settings_custom "Custom site rules"> -<!ENTITY https-everywhere.prefs.settings_click_ok "Please click 'OK'"> +<!ENTITY https-everywhere.prefs.settings_click_ok "Por favor, clique em 'OK'"> <!ENTITY https-everywhere.prefs.settings_warning_closing "below to ensure your settings are saved. Once HTTPS Everywhere is upgraded, you will later have to import these settings in the extension options section."> <!ENTITY https-everywhere.prefs.reset_defaults "Restaurar as configurações padrão"> <!ENTITY https-everywhere.prefs.search "Procurar">

1 0

[translation/https_everywhere_completed] Update translations for https_everywhere_completed
by translation＠torproject.org 05 Aug '17

05 Aug '17

commit f9a5a8a20ae0b008fc573723effe1d2c8a2a7c0f Author: Translation commit bot <translation(a)torproject.org> Date: Sat Aug 5 10:15:42 2017 +0000 Update translations for https_everywhere_completed --- it/https-everywhere.dtd | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/it/https-everywhere.dtd b/it/https-everywhere.dtd index a1c600d4f..74af510c7 100644 --- a/it/https-everywhere.dtd +++ b/it/https-everywhere.dtd @@ -24,9 +24,22 @@ <!ENTITY https-everywhere.menu.showCounter "Mostra contatore"> <!ENTITY https-everywhere.menu.viewAllRules "Vedi tutte le regole"> +<!ENTITY https-everywhere.options.importSettings "Importa impostazioni"> +<!ENTITY https-everywhere.options.import "Importa"> +<!ENTITY https-everywhere.options.imported "Le tue impostazioni sono state importate."> + <!ENTITY https-everywhere.prefs.title "Preferenze di HTTPS Everywhere"> <!ENTITY https-everywhere.prefs.enable_all "Abilita tutto"> <!ENTITY https-everywhere.prefs.disable_all "Disabilita tutto"> +<!ENTITY https-everywhere.prefs.export_settings "Esporta impostazioni"> +<!ENTITY https-everywhere.prefs.settings_warning "Attenzione:"> +<!ENTITY https-everywhere.prefs.settings_warning_delete "Alcune tue impostazioni di HTTPS Everywhere verranno eliminate!"> +<!ENTITY https-everywhere.prefs.settings_warning_explain "Questa estensione verrà aggiornata in modo sostanzioso nel prossimo futuro. Se non esporti le tue impostazioni, potresti perderne una o più delle seguenti:"> +<!ENTITY https-everywhere.prefs.settings_global "Preferenze globali"> +<!ENTITY https-everywhere.prefs.settings_toggle "Impostazione on/off per sito"> +<!ENTITY https-everywhere.prefs.settings_custom "Regole personali per sito"> +<!ENTITY https-everywhere.prefs.settings_click_ok "Clicca 'OK'"> +<!ENTITY https-everywhere.prefs.settings_warning_closing "qua sotto per salvare le tue impostazioni. Una volta che HTTPS Everywhere sarà aggiornato, dovrai importare queste impostazioni usando le opzioni dell'estensione."> <!ENTITY https-everywhere.prefs.reset_defaults "Ripristina la configurazione predefinita"> <!ENTITY https-everywhere.prefs.search "Cerca"> <!ENTITY https-everywhere.prefs.site "Sito">

1 0

[translation/https_everywhere] Update translations for https_everywhere
by translation＠torproject.org 05 Aug '17

05 Aug '17

commit 896c3be43b15abaaab6d856feb0e1299c98df50e Author: Translation commit bot <translation(a)torproject.org> Date: Sat Aug 5 10:15:32 2017 +0000 Update translations for https_everywhere --- it/https-everywhere.dtd | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/it/https-everywhere.dtd b/it/https-everywhere.dtd index 845d7aab0..74af510c7 100644 --- a/it/https-everywhere.dtd +++ b/it/https-everywhere.dtd @@ -24,22 +24,22 @@ <!ENTITY https-everywhere.menu.showCounter "Mostra contatore"> <!ENTITY https-everywhere.menu.viewAllRules "Vedi tutte le regole"> -<!ENTITY https-everywhere.options.importSettings "Import Settings"> -<!ENTITY https-everywhere.options.import "Import"> -<!ENTITY https-everywhere.options.imported "Your settings have been imported."> +<!ENTITY https-everywhere.options.importSettings "Importa impostazioni"> +<!ENTITY https-everywhere.options.import "Importa"> +<!ENTITY https-everywhere.options.imported "Le tue impostazioni sono state importate."> <!ENTITY https-everywhere.prefs.title "Preferenze di HTTPS Everywhere"> <!ENTITY https-everywhere.prefs.enable_all "Abilita tutto"> <!ENTITY https-everywhere.prefs.disable_all "Disabilita tutto"> -<!ENTITY https-everywhere.prefs.export_settings "Export Settings"> -<!ENTITY https-everywhere.prefs.settings_warning "Warning:"> -<!ENTITY https-everywhere.prefs.settings_warning_delete "Some of your HTTPS Everywhere settings are about to be deleted!"> -<!ENTITY https-everywhere.prefs.settings_warning_explain "This extension will be upgraded substantially in the near future. If you do not export your settings, you could lose one or more of the following:"> -<!ENTITY https-everywhere.prefs.settings_global "Global preferences"> -<!ENTITY https-everywhere.prefs.settings_toggle "Per-site on/off setting"> -<!ENTITY https-everywhere.prefs.settings_custom "Custom site rules"> -<!ENTITY https-everywhere.prefs.settings_click_ok "Please click 'OK'"> -<!ENTITY https-everywhere.prefs.settings_warning_closing "below to ensure your settings are saved. Once HTTPS Everywhere is upgraded, you will later have to import these settings in the extension options section."> +<!ENTITY https-everywhere.prefs.export_settings "Esporta impostazioni"> +<!ENTITY https-everywhere.prefs.settings_warning "Attenzione:"> +<!ENTITY https-everywhere.prefs.settings_warning_delete "Alcune tue impostazioni di HTTPS Everywhere verranno eliminate!"> +<!ENTITY https-everywhere.prefs.settings_warning_explain "Questa estensione verrà aggiornata in modo sostanzioso nel prossimo futuro. Se non esporti le tue impostazioni, potresti perderne una o più delle seguenti:"> +<!ENTITY https-everywhere.prefs.settings_global "Preferenze globali"> +<!ENTITY https-everywhere.prefs.settings_toggle "Impostazione on/off per sito"> +<!ENTITY https-everywhere.prefs.settings_custom "Regole personali per sito"> +<!ENTITY https-everywhere.prefs.settings_click_ok "Clicca 'OK'"> +<!ENTITY https-everywhere.prefs.settings_warning_closing "qua sotto per salvare le tue impostazioni. Una volta che HTTPS Everywhere sarà aggiornato, dovrai importare queste impostazioni usando le opzioni dell'estensione."> <!ENTITY https-everywhere.prefs.reset_defaults "Ripristina la configurazione predefinita"> <!ENTITY https-everywhere.prefs.search "Cerca"> <!ENTITY https-everywhere.prefs.site "Sito">

1 0

[translation/torbutton-abouttorproperties_completed] Update translations for torbutton-abouttorproperties_completed
by translation＠torproject.org 05 Aug '17

05 Aug '17

commit 5ffa8872f979631568f1e3318b42dd6daab7b019 Author: Translation commit bot <translation(a)torproject.org> Date: Sat Aug 5 05:48:05 2017 +0000 Update translations for torbutton-abouttorproperties_completed --- es_MX/abouttor.properties | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/es_MX/abouttor.properties b/es_MX/abouttor.properties new file mode 100644 index 000000000..365c35bfc --- /dev/null +++ b/es_MX/abouttor.properties @@ -0,0 +1,9 @@ +# Copyright (c) 2014, The Tor Project, Inc. +# See LICENSE for licensing information. +# vim: set sw=2 sts=2 ts=8 et: + +aboutTor.searchDDG.privacy=Buscar<a href="%1$S">con seguridad</a> con <a href="%2$S">DuckDuckGo</a>. +# The following string is a link which replaces %1$S above. +aboutTor.searchDDG.privacy.link=https://duckduckgo.com/privacy.html +# The following string is a link which replaces %2$S above. +aboutTor.searchDDG.search.link=https://duckduckgo.com/

1 0

[translation/torbutton-abouttorproperties] Update translations for torbutton-abouttorproperties
by translation＠torproject.org 05 Aug '17

05 Aug '17

commit 198fa43b2ab9b29fb13877eea3b3c68fc0b630db Author: Translation commit bot <translation(a)torproject.org> Date: Sat Aug 5 05:47:58 2017 +0000 Update translations for torbutton-abouttorproperties --- es_MX/abouttor.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/es_MX/abouttor.properties b/es_MX/abouttor.properties index f9723bf25..365c35bfc 100644 --- a/es_MX/abouttor.properties +++ b/es_MX/abouttor.properties @@ -2,7 +2,7 @@ # See LICENSE for licensing information. # vim: set sw=2 sts=2 ts=8 et: -aboutTor.searchDDG.privacy=Search <a href="%1$S">securely</a> with <a href="%2$S">DuckDuckGo</a>. +aboutTor.searchDDG.privacy=Buscar<a href="%1$S">con seguridad</a> con <a href="%2$S">DuckDuckGo</a>. # The following string is a link which replaces %1$S above. aboutTor.searchDDG.privacy.link=https://duckduckgo.com/privacy.html # The following string is a link which replaces %2$S above.

1 0