April 2014 - tor-commits - lists.torproject.org

[tor-browser-spec/master] Update graphic to match origin policy suggestions.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit d60e343c6a518fa7b7e15e3aa85900edc0a5a8dc Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 4 22:45:09 2011 -0700 Update graphic to match origin policy suggestions. --- docs/design/CookieManagers.png | Bin 121020 -> 113551 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/docs/design/CookieManagers.png b/docs/design/CookieManagers.png index b979f30..0fc3e64 100644 Binary files a/docs/design/CookieManagers.png and b/docs/design/CookieManagers.png differ

1 0

[tor-browser-spec/master] Speel chek
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 2552a9cde3ed579b7fab59834151a16662dae24a Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 4 22:26:48 2011 -0700 Speel chek --- docs/design/design.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 6c1a806..244c9ab 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -218,7 +218,7 @@ determining how identifying a particular browser property is. However, … [View More]some quirks of their study means that they do not extract as much information as they could from display information: they only use desktop resolution (which Torbutton reports as the window resolution) and do not attempt to infer the -size of toolbars. In the other direction, they may be overcounting in some +size of toolbars. In the other direction, they may be over-counting in some areas, as they did not compute joint entropy over multiple attributes that may exhibit a high degree of correlation. Also, new browser features are added regularly, so the data should not be taken as final. @@ -235,8 +235,8 @@ attack vectors: <para> Properties of the user's request behavior comprise the bulk of low-hanging -fingerprintig targets. These include: User agent, Accept-* headers, pipeline -useage, and request ordering. Additionally, the use of custom filters such as +fingerprinting targets. These include: User agent, Accept-* headers, pipeline +usage, and request ordering. Additionally, the use of custom filters such as AdBlock and other privacy filters can be used to fingerprint request patterns (as an extreme example). @@ -263,7 +263,7 @@ and interpreter speed</ulink>. The Panopticlick project found that the mere list of installed plugins (in navigator.plugins) was sufficient to provide a large degree of -fingerprintability. Additionally, plugins are capable of extracing font lists, +fingerprintability. Additionally, plugins are capable of extracting font lists, interface addresses, and other machine information that is beyond what the browser would normally provide to content. In addition, plugins can be used to store unique identifiers that are more difficult to clear than standard @@ -523,7 +523,7 @@ Therefore, if plugins are to be enabled in private browsing modes, they must be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user decides to craft an exemption to allow a plugin to be -used, it MUST ONLY apply to the top level urlbar domain, and not to all sites, +used, it MUST ONLY apply to the top level url bar domain, and not to all sites, to reduce linkability. </para> @@ -793,7 +793,7 @@ seven different pieces of privacy UI governing these identifiers and permissions can become just one piece of UI. For instance, a window that lists the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. -An example of this simplifcation can be seen in Figure 1. +An example of this simplification can be seen in Figure 1. </para> <figure><title>Improving the Privacy UI</title> @@ -807,7 +807,7 @@ An example of this simplifcation can be seen in Figure 1. On the left is the standard Firefox cookie manager. On the right is a mock-up of how isolating identifiers to the URL bar origin might simplify the privacy UI for all data - not just cookies. Both windows represent the set of -Cookies accomulated after visiting just five sites, but the window on the +Cookies accumulated after visiting just five sites, but the window on the right has the option of also representing history, DOM Storage, HTTP Auth, search form history, login values, and so on within a context menu for each site. @@ -945,7 +945,7 @@ automatically navigate between two different url bar origins. <para><command>Implementation status:</command> There are numerous ways for the user to be redirected, and the Firefox API -suport to detect each of them is poor. We have a <ulink +support to detect each of them is poor. We have a <ulink url="https://trac.torproject.org/projects/tor/ticket/3600">trac bug open</ulink> to implement what we can. @@ -1512,7 +1512,7 @@ AnonTest</ulink> <para> The <ulink url="https://anonymous-proxy-servers.net/">JonDos people</ulink> also provide an -anonymity tester. It is more focused on HTTP headers than plugin bypass, and +anonymity tester. It is more focused on HTTP headers and behaviors than plugin bypass, and points out a couple of headers Torbutton could do a better job with obfuscating. [View Less]

1 0

[tor-browser-spec/master] Reorganize and update the attacks section for the new model.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit bdfc51217eca3e1e5e87e730c467d47fa1e2d002 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 4 22:22:12 2011 -0700 Reorganize and update the attacks section for the new model. It was still mostly written towards the toggle model. --- docs/design/design.xml | 197 +++++++++++++++++++++++------------------------- 1 file changed, 94 insertions(+), 103 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 8930820..6c1a806 100644 ---… [View More] a/docs/design/design.xml +++ b/docs/design/design.xml @@ -173,136 +173,119 @@ performed by malicious agents on the Tor network and at national firewalls. </para> <orderedlist> - <listitem><command>Inserting Javascript</command> + <listitem><command>Read and insert identifiers</command> <para> -If not properly disabled, Javascript event handlers and timers -can cause the browser to perform network activity after Tor has been disabled, -thus allowing the adversary to correlate Tor and Non-Tor activity and reveal -a user's non-Tor IP address. Javascript -also allows the adversary to execute <ulink -url="http://whattheinternetknowsaboutyou.com/">history disclosure attacks</ulink>: -to query the history via the different attributes of 'visited' links to search -for particular Google queries, sites, or even to <ulink -url="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate…">profile -users based on gender and other classifications</ulink>. Finally, -Javascript can be used to query the user's timezone via the -<function>Date()</function> object, and to reduce the anonymity set by querying -the <function>navigator</function> object for operating system, CPU, locale, -and user agent information. - </para> - </listitem> - <listitem><command>Inserting Plugins</command> - <para> - -Plugins are abysmal at obeying the proxy settings of the browser. Every plugin -capable of performing network activity that the author has -investigated is also capable of performing network activity independent of -browser proxy settings - and often independent of its own proxy settings. -Sites that have plugin content don't even have to be malicious to obtain a -user's -Non-Tor IP (it usually leaks by itself), though <ulink -url="http://decloak.net">plenty of active -exploits</ulink> are possible as well. In addition, plugins can be used to store unique identifiers that are more -difficult to clear than standard cookies. -<ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based -cookies</ulink> fall into this category, but there are likely numerous other -examples. +The browser contains multiple facilities for storing identifiers that the +adversary creates for the purposes of tracking users. These identifiers are +most obviously cookies, but also include HTTP auth, DOM storage, cached +scripts and other elements with embedded identifiers, client certificates, and +even TLS Session IDs. </para> - </listitem> - <listitem><command>Inserting CSS</command> - <para> - -CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's -Non-Tor IP address, via the usage of -<ulink url="http://www.tjkdesign.com/articles/css%20pop%20ups/">CSS -popups</ulink> - essentially CSS-based event handlers that fetch content via -CSS's onmouseover attribute. If these popups are allowed to perform network -activity in a different Tor state than they were loaded in, they can easily -correlate Tor and Non-Tor activity and reveal a user's IP address. In -addition, CSS can also be used without Javascript to perform <ulink -url="http://ha.ckers.org/weird/CSS-history.cgi">CSS-only history disclosure -attacks</ulink>. - </para> - </listitem> -  - <listitem><command>Read and insert cookies</command> <para> An adversary in a position to perform MITM content alteration can inject document content elements to both read and inject cookies for arbitrary -domains. In fact, many "SSL secured" websites are vulnerable to this sort of +domains. In fact, even many "SSL secured" websites are vulnerable to this sort of <ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active sidejacking</ulink>. In addition, the ad networks of course perform tracking with cookies as well. </para> </listitem> - <listitem><command>Create arbitrary cached content</command> - <para> - -Likewise, the browser cache can also be used to <ulink -url="http://crypto.stanford.edu/sameorigin/safecachetest.html">store unique -identifiers</ulink>. Since by default the cache has no same-origin policy, -these identifiers can be read by any domain, making them an ideal target for -ad network-class adversaries. - - </para> - </listitem> - <listitem id="fingerprinting"><command>Fingerprint users based on browser attributes</command> <para> There is an absurd amount of information available to websites via attributes of the browser. This information can be used to reduce anonymity set, or even -<ulink url="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html">uniquely -fingerprint individual users</ulink>. </para> +uniquely fingerprint individual users. Fingerprinting is an intimidating +problem to attempt to tackle, especially without a metric to determine or at +least intuitively understand and estimate which features will most contribute +to linkability between visits. + +</para> - <para> -The <ulink -url="https://wiki.mozilla.org/Fingerprinting#Data">Panopticlick study -done</ulink> by the EFF attempts to measure the actual entropy - the number of -identifying bits of information encoded in browser properties. Their result -data is definitely useful, and the metric is probably the appropriate one for +The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study +done</ulink> by the EFF uses the actual entropy - the number of identifying +bits of information encoded in browser properties - as this metric. Their +<ulink url="https://wiki.mozilla.org/Fingerprinting#Data">result data</ulink> +is definitely useful, and the metric is probably the appropriate one for determining how identifying a particular browser property is. However, some quirks of their study means that they do not extract as much information as they could from display information: they only use desktop resolution (which Torbutton reports as the window resolution) and do not attempt to infer the -size of toolbars. +size of toolbars. In the other direction, they may be overcounting in some +areas, as they did not compute joint entropy over multiple attributes that may +exhibit a high degree of correlation. Also, new browser features are added +regularly, so the data should not be taken as final. - + </para> + <para> -</para> +Despite the uncertainty, all fingerprinting attacks leverage the following +attack vectors: + + </para> + <orderedlist> + <listitem><command>Observing Request Behavior</command> + <para> + +Properties of the user's request behavior comprise the bulk of low-hanging +fingerprintig targets. These include: User agent, Accept-* headers, pipeline +useage, and request ordering. Additionally, the use of custom filters such as +AdBlock and other privacy filters can be used to fingerprint request patterns +(as an extreme example). + + </para> + </listitem> + + <listitem><command>Inserting Javascript</command> + <para> + +Javascript can reveal a lot of fingerprinting information. It provides DOM +objects, just as window.screen and window.navigator to extract information +about the useragent. Also, Javascript can be used to query the user's timezone +via the <function>Date()</function> object, and to use timing information to +<ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">fingerprint the CPU +and interpreter speed</ulink>. + + + + </para> + </listitem> + + <listitem><command>Inserting Plugins</command> + <para> + +The Panopticlick project found that the mere list of installed plugins (in +navigator.plugins) was sufficient to provide a large degree of +fingerprintability. Additionally, plugins are capable of extracing font lists, +interface addresses, and other machine information that is beyond what the +browser would normally provide to content. In addition, plugins can be used to +store unique identifiers that are more difficult to clear than standard +cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based +cookies</ulink> fall into this category, but there are likely numerous other +examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy +settings of the browser. + + + </para> + </listitem> + <listitem><command>Inserting CSS</command> + <para> + +<ulink url="https://developer.mozilla.org/En/CSS/Media_queries">CSS media +queries</ulink> can be inserted to gather information about the desktop size, +widget size, display type, DPI, user agent type, and other information that +was formerly available only to Javascript. + + </para> + </listitem> + </orderedlist> </listitem> <listitem><command>Remotely or locally exploit browser and/or OS</command> @@ -659,8 +642,9 @@ SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>, </listitem> <listitem>Disabling plugins - <para> - Plugins have the ability to make arbitrary OS system calls. This includes + + <para>Plugins have the ability to make arbitrary OS system calls and <ulink +url="http://decloak.net/">bypass proxy settings</ulink>. This includes the ability to make UDP sockets and send arbitrary data independent of the browser proxy settings. </para> @@ -678,6 +662,13 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src for Flash and Gnash</ulink>. </para> + <para> + +Finally, even if the user alters their browser settings to re-enable the Flash +plugin, we have configured NoScript to provide click-to-play placeholders, so +that only desired objects will be loaded, and only after user confirmation. + + </para> </listitem> <listitem>External App Blocking <para> [View Less]

1 0

[tor-browser-spec/master] More comments from PDE.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 545a2a00f5bdf35720c3829b04147bb9c370c934 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Oct 6 17:32:53 2011 -0700 More comments from PDE. --- docs/design/design.xml | 140 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 106 insertions(+), 34 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 2145751..ddbb9f8 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -131,12 +131,12 @@ upstream of exit nodes.… [View More] Both of these scenarios have been observed in the wild. </para> </listitem> - <listitem><command>Adservers and/or Malicious Websites</command> + <listitem><command>Ad servers and/or Malicious Websites</command> <para> The adversary can also run websites, or more likely, they can contract out -ad space from a number of different adservers and inject content that way. For -some users, the adversary may be the adservers themselves. It is not -inconceivable that adservers may try to subvert or reduce a user's anonymity +ad space from a number of different ad servers and inject content that way. For +some users, the adversary may be the ad servers themselves. It is not +inconceivable that ad servers may try to subvert or reduce a user's anonymity through Tor for marketing purposes. </para> </listitem> @@ -167,7 +167,7 @@ The adversary can perform the following attacks from a number of different positions to accomplish various aspects of their goals. It should be noted that many of these attacks (especially those involving IP address leakage) are often performed by accident by websites that simply have Javascript, dynamic -CSS elements, and plugins. Others are performed by adservers seeking to +CSS elements, and plugins. Others are performed by ad servers seeking to correlate users' activity across different IP addresses, and still others are performed by malicious agents on the Tor network and at national firewalls. @@ -331,7 +331,8 @@ adversary. <para> The Tor Browser Design Requirements are meant to describe the properties of a -Private Browsing Mode that defends against both network and forensic adversaries. +Private Browsing Mode that defends against both network and local forensic +adversaries. </para> <para> @@ -392,7 +393,6 @@ duration of one browsing session, unless the user has explicitly opted to store their browsing history information to disk. </para></listitem> - <listitem><command>Application Data Isolation</command><para> The components involved in providing private browsing MUST BE self-contained, @@ -402,7 +402,9 @@ operating system to write <emphasis>any information</emphasis> about the use of private browsing to disk outside of the application's control. The user must be able to ensure that secure removal of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings -due to operating system behavior MUST BE wiped by an uninstaller. +due to operating system behavior MUST BE wiped by an uninstaller. However, due +to permissions issues with access to swap, implementations MAY choose to leave +it out of scope, and/or leave it to the user to implement encrypted swap. </para></listitem> <listitem><command>Update Safety</command><para>The browser SHOULD NOT perform unsafe updates or upgrades.</para></listitem> @@ -437,10 +439,12 @@ to be the entire fully qualified domain name <para> User activity on one url bar origin MUST NOT be linkable to their activity in -any other url bar origin by any third party. This property specifically applies to -linkability from stored browser identifiers, authentication tokens, and shared -state. This functionality SHOULD NOT interfere with federated login in a -substantial way. +any other url bar origin by any third party automatically or without user +interaction or approval. This requirement specifically applies to linkability +from stored browser identifiers, authentication tokens, and shared state. The +requirement does not apply to linkable information the user manually submits +to sites, or due information submitted during manual link traversal. This +functionality SHOULD NOT interfere with federated login in a substantial way. </para> </listitem> @@ -796,6 +800,7 @@ context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. </para> +  <figure><title>Improving the Privacy UI</title> <mediaobject> <imageobject> @@ -959,13 +964,18 @@ Unlinkability <link linkend="privacy">privacy requirement</link>, the browser MUST prompt users before following redirects that would cause the user to automatically navigate between two different url bar origins. - </para> - <para><command>Implementation status:</command> +</para> +<para> -There are numerous ways for the user to be redirected, and the Firefox API -support to detect each of them is poor. We have a <ulink -url="https://trac.torproject.org/projects/tor/ticket/3600">trac bug -open</ulink> to implement what we can. +However, to +reduce the occurrence of warning fatigue, these warning messages MAY be limited +to automated redirect cycles only. For example, the automated redirect +sequence <command>User Click -> t.co -> bit.ly -> cnn.com</command> can be +assumed to be benign, but the redirect sequence <command>User Click -> t.co -> +bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</command> is +clearly due to tracking. Non-automated redirect cycles that require +user input at some step (such as federated login systems) need not be +interrupted by the UI. </para> <para> @@ -977,6 +987,14 @@ especially with frequent use of the <link linkend="new-identity">New Identity</link> button. </para> + <para><command>Implementation status:</command> + +There are numerous ways for the user to be redirected, and the Firefox API +support to detect each of them is poor. We have a <ulink +url="https://trac.torproject.org/projects/tor/ticket/3600">trac bug +open</ulink> to implement what we can. + + </para> </listitem> <listitem>window.name <para> @@ -999,6 +1017,43 @@ enters a new URL or navigates between https/http schemes, the property is cleare </para> </listitem> + <listitem>Auto form-fill + <para> + +We disable the password saving functionality in the browser as part of our +<link linkend="disk-avoidance">Disk Avoidance</link> requirement. However, +since users may decide to re-enable disk history records and password saving, +we also set the <ulink +url="http://kb.mozillazine.org/Signon.autofillForms">signon.autofillForms</ulink> +preference to false to prevent saved values from immediately populating +fields upon page load. Since Javascript can read these values as soon as they +appear, setting this preference prevents automatic linkability from stored passwords. + + </para> + </listitem> + <listitem>HSTS supercookies + <para> +An extreme (but not impossible) attack to mount is the creation of <ulink +url="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Securi…">HSTS</ulink> +supercookies. Since HSTS effectively stores one bit of information per domain +name, an adversary in possession of numerous domains can use them to construct +cookies based on stored HSTS state. + + </para> + <para><command>Design Goal:</command> + +There appears to be three options for us: 1. Disable HSTS entirely, and rely +instead on HTTPS-Everywhere. 2. Restrict the number of HSTS-enabled third +parties allowed per url bar origin. 3. Prevent third parties from storing HSTS +rules. We have not yet decided upon the best approach. + + </para> + <para><command>Implementation Status:</command> Currently, HSTS state is +cleared by <link linkend="new-identity">New Identity</link>, but we don't +defend against the creation of these cookies between <command>New +Identity</command> invocations. + </para> + </listitem> <listitem>Exit node usage <para><command>Design Goal:</command> @@ -1094,12 +1149,25 @@ pre-built list to query, a large amount of fingerprintable information may still be available. </para> + <para> + +The sure-fire way to address font linkability is to ship the browser with a +font for every language, typeface, and style in use in the world, and to only +use those fonts at the exclusion of system fonts. However, this set may be +impractically large. It is possible that a smaller <ulink +url="https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_typeface#List_of_Uni…">common +subset</ulink> may be found that provides total coverage. However, we believe +that with strong url bar origin identifier isolation, a simpler approach can reduce the +number of bits available to the adversary while avoiding the rendering and +language issues of supporting a global font set. + + </para> <para><command>Design Goal:</command> -To address the Javascript issue, we intend to <ulink +We intend to <ulink url="https://trac.torproject.org/projects/tor/ticket/2872">limit the number of -fonts</ulink> an origin can load, gracefully degrading to built-in and/or -remote fonts once the limit is reached. +fonts</ulink> a url bar origin can load, gracefully degrading to built-in +and/or remote fonts once the limit is reached. </para> <para><command>Implementation Status:</command> @@ -1207,7 +1275,7 @@ url="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</ulink> found that even with the default precision in most browsers, they required up to 120 seconds of amortization and repeated trials to get stable results from their feature set. We intend to work with the research community to establish the -optimum tradeoff between quantization+jitter and amortization time. +optimum trade-off between quantization+jitter and amortization time. </para> @@ -1284,17 +1352,19 @@ All linkable identifiers and browser state MUST be cleared by this feature. <sect3> <title>Implementation Status:</title> <blockquote> - First, Torbutton disables -all open tabs and windows via nsIContentPolicy blocking, and then closes each -tab and window. The extra step for blocking tabs is done as a precaution to -ensure that any asynchronous Javascript is in fact properly disabled. After -closing all of the windows, we then clear the following state: OCSP (by -toggling security.OCSP.enabled), cache, site-specific zoom and content -preferences, Cookies, DOM storage, safe browsing key, the Google wifi -geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened URL -field (via the pref general.open_location.last_url). After clearing the -browser state, we then send the NEWNYM signal to the Tor control port to cause -a new circuit to be created. + + First, Torbutton disables all open tabs and windows via nsIContentPolicy +blocking, and then closes each tab and window. The extra step for blocking +tabs is done as a precaution to ensure that any asynchronous Javascript is in +fact properly disabled. After closing all of the windows, we then clear the +following state: OCSP (by toggling security.OCSP.enabled), cache, +site-specific zoom and content preferences, Cookies, DOM storage, safe +browsing key, the Google wifi geolocation token (if exists), HTTP auth, SSL +Session IDs, HSTS state, and the last opened URL field (via the pref +general.open_location.last_url). After clearing the browser state, we then +send the NEWNYM signal to the Tor control port to cause a new circuit to be +created. + </blockquote> </sect3> @@ -1344,7 +1414,9 @@ Firebox version, but not much else. This patch exposes a pref 'permissions.memory_only' that properly isolates the permissions manager to memory, which is responsible for all user specified -site permissions, as well as stored HTTPS STS policy from visited sites. +site permissions, as well as stored <ulink +url="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Securi…">HSTS</ulink> +policy from visited sites. The pref does successfully clear the permissions manager memory if toggled. It does not need to be set in prefs.js, and can be handled by Torbutton. [View Less]

1 0

[translation/torbutton-torbuttondtd] Update translations for torbutton-torbuttondtd
by translation＠torproject.org 28 Apr '14

28 Apr '14

commit a2262d4db36f461adbdad6b53cb9cbc9ba95cca6 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 28 14:15:48 2014 +0000 Update translations for torbutton-torbuttondtd --- pl/torbutton.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pl/torbutton.dtd b/pl/torbutton.dtd index ed8c455..5c71901 100644 --- a/pl/torbutton.dtd +++ b/pl/torbutton.dtd @@ -77,7 +77,7 @@ <!ENTITY torbutton.prefs.spoofblank "Spoof blank referer during … [View More]

1 0

[translation/tails-iuk_completed] Update translations for tails-iuk_completed
by translation＠torproject.org 28 Apr '14

28 Apr '14

commit eceecfbeaa74e0d375381ea29a8fd0250df4cc0d Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 28 13:46:00 2014 +0000 Update translations for tails-iuk_completed --- it.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it.po b/it.po index d8e633e..af126ee 100644 --- a/it.po +++ b/it.po @@ -17,7 +17,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" "POT-… [View More]

1 0

[translation/tails-iuk] Update translations for tails-iuk
by translation＠torproject.org 28 Apr '14

28 Apr '14

commit 0d9e39b52816a3d576bca830918a2482c801fdde Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 28 13:45:58 2014 +0000 Update translations for tails-iuk --- it.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/it.po b/it.po index d8e633e..af126ee 100644 --- a/it.po +++ b/it.po @@ -17,7 +17,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" "POT-Creation-… [View More]

1 0

[translation/torbutton-torbuttondtd] Update translations for torbutton-torbuttondtd
by translation＠torproject.org 28 Apr '14

28 Apr '14

commit 9ba2c3f01f61e1f09f320e921417592a752fbbfd Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 28 13:45:56 2014 +0000 Update translations for torbutton-torbuttondtd --- pl/torbutton.dtd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pl/torbutton.dtd b/pl/torbutton.dtd index 3e93e2d..ed8c455 100644 --- a/pl/torbutton.dtd +++ b/pl/torbutton.dtd @@ -31,11 +31,11 @@ <!ENTITY torbutton.context_menu.about "O Torbutton"> &… [View More]

1 0

[translation/abouttor-homepage_completed] Update translations for abouttor-homepage_completed
by translation＠torproject.org 28 Apr '14

28 Apr '14

commit 474153ddfa9629f96a7821b8e86aa2fbc8f851c0 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 28 13:45:47 2014 +0000 Update translations for abouttor-homepage_completed --- pl/aboutTor.dtd | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pl/aboutTor.dtd b/pl/aboutTor.dtd index 452de3b..654dc58 100644 --- a/pl/aboutTor.dtd +++ b/pl/aboutTor.dtd @@ -43,6 +43,8 @@ <!ENTITY aboutTor.helpInfo5.label "Przekaż darowiznę »"> &… [View More]

1 0

[translation/abouttor-homepage] Update translations for abouttor-homepage
by translation＠torproject.org 28 Apr '14

28 Apr '14

commit e7c0770ebb8a79b14a21671207121f8c592f6c08 Author: Translation commit bot <translation(a)torproject.org> Date: Mon Apr 28 13:45:44 2014 +0000 Update translations for abouttor-homepage --- pl/aboutTor.dtd | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pl/aboutTor.dtd b/pl/aboutTor.dtd index 452de3b..654dc58 100644 --- a/pl/aboutTor.dtd +++ b/pl/aboutTor.dtd @@ -43,6 +43,8 @@ <!ENTITY aboutTor.helpInfo5.label "Przekaż darowiznę »"> <!ENTITY … [View More]

1 0