aboutsummaryrefslogtreecommitdiff
path: root/template/faq.html.j2
diff options
context:
space:
mode:
Diffstat (limited to 'template/faq.html.j2')
-rw-r--r--template/faq.html.j21471
1 files changed, 890 insertions, 581 deletions
diff --git a/template/faq.html.j2 b/template/faq.html.j2
index 7ba8f849..d2110213 100644
--- a/template/faq.html.j2
+++ b/template/faq.html.j2
@@ -9,596 +9,905 @@
9 <div class="row"> 9 <div class="row">
10 <div class="col-2 d-none d-lg-block"><!-- for large viewports show menu for better orientation --> 10 <div class="col-2 d-none d-lg-block"><!-- for large viewports show menu for better orientation -->
11 <nav class="nav subnav position-fixed flex-column border-right" style="position:fixed"> 11 <nav class="nav subnav position-fixed flex-column border-right" style="position:fixed">
12 <a class="nav-link" href="#general">{{ _("General") }}</a> 12 <a class="nav-link" href="#general">{{ _("General") }}</a>
13 <a class="nav-link" href="#features">{{ _("Features") }}</a> 13 <a class="nav-link" href="#features">{{ _("Features") }}</a>
14 <a class="nav-link" href="#gns">GNU Name System</a> 14 <a class="nav-link" href="#gns">GNU Name System</a>
15 <a class="nav-link" href="#errors">{{ _("Error messages") }}</a> 15 <a class="nav-link" href="#errors">{{ _("Error messages") }}</a>
16 <a class="nav-link" href="#fs">{{ _("File-sharing") }}</a>
17 <a class="nav-link" href="#contrib">{{ _("Contributing") }}</a>
16 </nav> 18 </nav>
17 </div> 19 </div>
18 20
19 <div class="col"> 21 <div class="col">
20 <article> 22 <article>
21 <h2><a name="general" class="subnav-anchor"></a>{{ _("General") }}</h2> 23 <h2><a name="general" class="subnav-anchor"></a>{{ _("General") }}</h2>
22 General questions about the project. 24 General questions about the project.
23 <section> 25 <section>
24 <h3>{{ _("What do I do if my question is not answered here?") }}</h3> 26 <h3>{{ _("What do I do if my question is not answered here?") }}</h3>
25 <p> 27 <p>
26 {% trans %} 28 {% trans %}
27 A: There are many other sources of information. You can read additional 29 A: There are many other sources of information. You can read additional
28 documentation or ask the question on the help-gnunet@gnu.org mailing list or 30 documentation or ask the question on the help-gnunet@gnu.org mailing list or
29 the #gnunet IRC on irc.freenode.net. 31 the #gnunet IRC on irc.freenode.net.
30 {% endtrans %} 32 {% endtrans %}
31 </p> 33 </p>
32 </section> 34 </section>
33 <section> 35 <section>
34 <h3>{{ _("When are you going to release the next version?") }}</h3> 36 <h3>{{ _("When are you going to release the next version?") }}</h3>
35 <p> 37 <p>
36 {% trans %} 38 {% trans %}
37 A: The general answer is, when it is ready. A better answer may be: earlier 39 A: The general answer is, when it is ready. A better answer may be: earlier
38 if you contribute (test, debug, code, document). Every release will be 40 if you contribute (test, debug, code, document). Every release will be
39 anounced on the info-gnunet@gnu.org mailing list and on 41 anounced on the info-gnunet@gnu.org mailing list and on
40 <a href="https://planet.gnu.org">planet GNU</a>. You can subscribe to the 42 <a href="https://planet.gnu.org">planet GNU</a>. You can subscribe to the
41 mailing list or the RSS feed of this site to automatically receive a 43 mailing list or the RSS feed of this site to automatically receive a
42 notification. 44 notification.
43 {% endtrans %} 45 {% endtrans %}
44 </p> 46 </p>
45 </section> 47 </section>
46 <section> 48 <section>
47 <h3>{{ _("Is the code free?") }}</h3> 49 <h3>{{ _("Is the code free?") }}</h3>
48 <p> 50 <p>
49 {% trans %} 51 {% trans %}
50 A: GNUnet is free software, available under the 52 A: GNUnet is free software, available under the
51 <a href="https://www.gnu.org/licenses/agpl-3.0.en.html">GNU Affero Public License (AGPL)</a>. 53 <a href="https://www.gnu.org/licenses/agpl-3.0.en.html">GNU Affero Public License (AGPL)</a>.
52 {% endtrans %} 54 {% endtrans %}
53 </p> 55 </p>
54 </section> 56 </section>
55 <section> 57 <section>
56 <h3>{{ _("Are there any known bugs?") }}</h3> 58 <h3>{{ _("Are there any known bugs?") }}</h3>
57 <p> 59 <p>
58 {% trans %} 60 {% trans %}
59 A: We track the list of currently known bugs in the 61 A: We track the list of currently known bugs in the
60 <a href="https://bugs.gnunet.org/">Mantis system</a>. 62 <a href="https://bugs.gnunet.org/">Mantis system</a>.
61 63
62Some bugs are occasionally reported directly to developers or the developer 64 Some bugs are occasionally reported directly to developers or the developer
63mailing list. This is discouraged since developers often do not have the time 65 mailing list. This is discouraged since developers often do not have the time
64to feed these bugs back into the Mantis database. Please report bugs directly 66 to feed these bugs back into the Mantis database. Please report bugs directly
65to the bug tracking system. If you believe a bug is sensitive, you can set its 67 to the bug tracking system. If you believe a bug is sensitive, you can set its
66view status to private (this should be the exception). 68 view status to private (this should be the exception).
67 {% endtrans %} 69 {% endtrans %}
68 </p> 70 </p>
69 </section> 71 </section>
70 <section> 72 <section>
71 <h3>{{ _("Is there a graphical user interface?") }}</h3> 73 <h3>{{ _("Is there a graphical user interface?") }}</h3>
72 <p> 74 <p>
73 {% trans %} 75 {% trans %}
74 A: gnunet-gtk is a separate download. The package 76 A: gnunet-gtk is a separate download. The package
75 contains various GTK+ based graphical interfaces, including a 77 contains various GTK+ based graphical interfaces, including a
76 graphical tool for configuration. 78 graphical tool for configuration.
77 {% endtrans %} 79 {% endtrans %}
78 </p> 80 </p>
79 </section> 81 </section>
80 <section> 82 <section>
81 <h3>{{ _("Why does gnunet-service-nse create a high CPU load?") }}</h3> 83 <h3>{{ _("Why does gnunet-service-nse create a high CPU load?") }}</h3>
82 <p> 84 <p>
83 {% trans %} 85 {% trans %}
84 A: The gnunet-service-nse process will initially compute a so-called 86 A: The gnunet-service-nse process will initially compute a so-called
85 &quot;proof-of-work&quot; which is used to convince the network that your 87 &quot;proof-of-work&quot; which is used to convince the network that your
86 peer is real (or, rather, make it expensive for an adversary to mount a Sybil 88 peer is real (or, rather, make it expensive for an adversary to mount a Sybil
87 attack on the network size estimator). The calculation is expected to take a 89 attack on the network size estimator). The calculation is expected to take a
88 few days, depending on how fast your CPU is. If the CPU load is creating a 90 few days, depending on how fast your CPU is. If the CPU load is creating a
89 problem for you, you can set the value &quot;WORKDELAY&quot; in the 91 problem for you, you can set the value &quot;WORKDELAY&quot; in the
90 &quot;nse&quot; section of 92 &quot;nse&quot; section of
91 your configuration file to a higher value. The default is &quot;5 ms&quot;. 93 your configuration file to a higher value. The default is &quot;5 ms&quot;.
92 {% endtrans %} 94 {% endtrans %}
93 </p> 95 </p>
94 </section> 96 </section>
95 97
96 <section> 98 <section>
97 <h3>{{ _("How does GNUnet compare to Tor?") }}</h3> 99 <h3>{{ _("How does GNUnet compare to Tor?") }}</h3>
98 <p> 100 <p>
99 {% trans %} 101 {% trans %}
100 A: Tor focuses on anonymous communication and censorship-resistance for TCP 102 A: Tor focuses on anonymous communication and censorship-resistance for TCP
101 connections and, with the Tor Browser Bundle, for the Web in particular. 103 connections and, with the Tor Browser Bundle, for the Web in particular.
102 GNUnet does not really have one focus; our theme is secure decentralized 104 GNUnet does not really have one focus; our theme is secure decentralized
103 networking, but that is too broad to be called a focus. 105 networking, but that is too broad to be called a focus.
104 {% endtrans %} 106 {% endtrans %}
105 </p> 107 </p>
106 </section> 108 </section>
107 109
108 <section> 110 <section>
109 <h3>{{ _("How does GNUnet compare to I2P?") }}</h3> 111 <h3>{{ _("How does GNUnet compare to I2P?") }}</h3>
110 <p> 112 <p>
111 {% trans %} 113 {% trans %}
112 A: Both GNUnet and I2P want to build a better, more secure, more decentralized 114 A: Both GNUnet and I2P want to build a better, more secure, more decentralized
113 Internet. However, on the technical side, there are almost no overlaps. 115 Internet. However, on the technical side, there are almost no overlaps.
114 <br><br> 116 <br><br>
115I2P is written in Java, and has (asymmetric) tunnels using onion (or garlic) 117 I2P is written in Java, and has (asymmetric) tunnels using onion (or garlic)
116routing as the basis for various (anonymized) applications. I2P is largely used 118 routing as the basis for various (anonymized) applications. I2P is largely used
117via a Web frontend. 119 via a Web frontend.
118 {% endtrans %} 120 {% endtrans %}
119 </p> 121 </p>
120 </section> 122 </section>
121 <section> 123 <section>
122 <h3>{{ _("Is GNUnet ready for use on production systems?") }}</h3> 124 <h3>{{ _("Is GNUnet ready for use on production systems?") }}</h3>
123 <p> 125 <p>
124 {% trans %} 126 {% trans %}
125 A: GNUnet is still undergoing major development. It is largely not yet ready 127 A: GNUnet is still undergoing major development. It is largely not yet ready
126 for usage beyond developers. Your mileage will vary depending on the 128 for usage beyond developers. Your mileage will vary depending on the
127 functionality you use, but you will always likely run into issues with 129 functionality you use, but you will always likely run into issues with
128 our current low-level transport system. We are currently in the process of 130 our current low-level transport system. We are currently in the process of
129 rewriting it (Project &quot;Transport Next Generation [TNG]&quot;) 131 rewriting it (Project &quot;Transport Next Generation [TNG]&quot;)
130 {% endtrans %} 132 {% endtrans %}
131 </p> 133 </p>
132 </section> 134 </section>
133 <section> 135 <section>
134 <h3>{{ _("Is GNUnet build using distributed ledger technologies?") }}</h3> 136 <h3>{{ _("Is GNUnet build using distributed ledger technologies?") }}</h3>
135 <p> 137 <p>
136 {% trans %} 138 {% trans %}
137 A: No. GNUnet is a new network protocol stack for building secure, 139 A: No. GNUnet is a new network protocol stack for building secure,
138 distributed, and privacy-preserving applications. 140 distributed, and privacy-preserving applications.
139 While a ledger could be built using GNUnet, we currently have no plans in 141 While a ledger could be built using GNUnet, we currently have no plans in
140 doing so. 142 doing so.
141 {% endtrans %} 143 {% endtrans %}
142 </p> 144 </p>
143 </section> 145 </section>
144 146
145 147
146 <h2><a name="features" class="subnav-anchor"></a>{{ _("Features") }}</h2> 148 <hr/>
147 <section> 149 <h2><a name="features" class="subnav-anchor"></a>{{ _("Features") }}</h2>
148 <h3>{{ _("What can I do with GNUnet?") }}</h3> 150 <section>
149 <p> 151 <h3>{{ _("What can I do with GNUnet?") }}</h3>
150 {% trans %} 152 <p>
151 A: GNUnet is a peer-to-peer framework, by which we mostly mean that it can do 153 {% trans %}
152 more than just one thing. Naturally, the implementation and documentation of 154 A: GNUnet is a peer-to-peer framework, by which we mostly mean that it can do
153 some of the features that exist are more advanced than others. 155 more than just one thing. Naturally, the implementation and documentation of
154 {% endtrans %} 156 some of the features that exist are more advanced than others.
155 </p> 157 {% endtrans %}
156 <p> 158 </p>
157 {% trans %} 159 <p>
158 For users, GNUnet offers anonymous and non-anonymous file-sharing, a fully 160 {% trans %}
159 decentralized and censorship-resistant replacement for DNS and a mechanism for 161 For users, GNUnet offers anonymous and non-anonymous file-sharing, a fully
160 IPv4-IPv6 protocol translation and tunneling (NAT-PT with DNS-ALG). 162 decentralized and censorship-resistant replacement for DNS and a mechanism for
161 {% endtrans %} 163 IPv4-IPv6 protocol translation and tunneling (NAT-PT with DNS-ALG).
162 See also: <a href="{{ url_localized('applications.html') }}">Applications</a>. 164 {% endtrans %}
163 165 See also: <a href="{{ url_localized('applications.html') }}">Applications</a>.
164 </p> 166
165 </section> 167 </p>
166 168 </section>
167 169
168 170 <section>
169 <h2><a name="gns" class="subnav-anchor"></a>GNU Name System</h2> 171 <h3>{{ _("Is it possible to surf the WWW anonymously with GNUnet?") }}</h3>
170 <section> 172 <p>
171 <h3>{{ _("Who runs the GNS root zone?") }}</h3> 173 {% trans %}
172 <p> 174 A: It is not possible use GNUnet for anonymous browsing at this point.
173 {% trans %} 175 We recommend that you use Tor for anonymous surfing.
174 A: Short answer: you. The long answer is the GNUnet will ship with a 176 {% endtrans %}
175 default configuration of top-level domains. The governance of this default 177 </p>
176 configuration is not yet established. In any case, the user will be able 178 </section>
177 to modify this configuration at will. We expect normal users to have 179
178 no need to edit their own GNS zone(s) unless they host services themselves. 180 <section>
179 {% endtrans %} 181 <h3>{{ _("Is it possible to access GNUnet via a browser as an anonymous WWW?") }}</h3>
180 </p> 182 <p>
181 </section> 183 {% trans %}
182 184 A: There is currently no proxy (like fproxy in Freenet) for GNUnet that would
183 <section> 185 make it accessible with a browser. It is possible to build such a proxy and
184 <h3>{{ _("Where is the per-user GNS database kept?") }}</h3> 186 all one needs to know is the protocol used between browser and proxy and a
185 <p> 187 swift look at the GNUnet code for file-sharing.
186 {% trans %} 188 {% endtrans %}
187 A: The short answer is that the database is kept at the user's GNUnet peer. 189 </p>
188 Now, a user may run multiple GNUnet peers, in which case the database could be 190 </section>
189 kept at each peer (however, we don't have code for convenient replication). 191
190 Similarly, multiple GNUnet peers can share one instance of the database --- 192 <section>
191 the &quot;gnunet-service-namestore&quot; can be accessed from remote 193 <h3>{{ _("Is there a graphical user interface?") }}</h3>
192 (via TCP). The actual data can be stored in a Postgres database, for which 194 <p>
193 various replication options are again applicable. Ultimately, there are many 195 {% trans %}
194 options for how users can store (and secure) their GNS database. 196 A: There are actually a few graphical user interfaces for different functions.
195 {% endtrans %} 197 gnunet-setup is to configure GNUnet, and gnunet-fs-gtk is for file-sharing.
196 </p> 198 There are a few other gnunet-XXX-gtk GUIs of lesser importance.
197 </section> 199 Note that in order to obtain the GUI, you need to install the gnunet-gtk
198 200 package, which is a separate download.
199 201
200 <section> 202 gnunet-gtk is a meta GUI that integrates most of the other GUIs in one window.
201 <h3>{{ _("What is the expected average size of a GNS namestore database?") }}</h3> 203 One exception is gnunet-setup, which must still be run separately at this time
202 <p> 204 (as setup requires the peer to be stopped).
203 {% trans %} 205 {% endtrans %}
204 A: Pretty small. Based on our user study where we looked at browser histories 206 </p>
205 and the number of domains visited, we expect that GNS databases will only 207 </section>
206 grow to a few tens of thousands of entries, small enough to fit even on mobile 208
207 devices. 209 <section>
208 {% endtrans %} 210 <h3>{{ _("On top of which operating systems does GNUnet run?") }}</h3>
209 </p> 211 <p>
210 </section> 212 {% trans %}
211 213 A: GNUnet is being developed and tested primarily under Debian GNU/Linux.
212 <section> 214 Furthermore, we regularly build and test GNUnet on Fedora, Ubuntu, Arch,
213 <h3>{{ _("Is GNS resistant to the attacks on DNS used by the US?") }}</h3> 215 FreeBSD and macOS.
214 <p> 216
215 {% trans %} 217 We have reports of working versions on many other GNU/Linux distributions;
216 A: We believe so, as there is no entity that any government could force to 218 in the past we had reports of working versions on NetBSD, OpenBSD and Solaris.
217 change the mapping for a name except for each individual user (and then the 219 However, not all of those reports are recent, so if you cannot get GNUnet to
218 changes would only apply to the names that this user is the authority for). 220 work on those systems please let us know.
219 So if everyone used GNS, the only practical attack of a government would be to 221 {% endtrans %}
220 force the operator of a server to change the GNS records for his server to 222 </p>
221 point elsewhere. However, if the owner of the private key for a zone is 223 </section>
222 unavailable for enforcement, the respective zone cannot be changed and any 224
223 other zone delegating to this zone will achieve proper resolution. 225 <hr/>
224 {% endtrans %} 226 <h2><a name="gns" class="subnav-anchor"></a>GNU Name System</h2>
225 </p> 227 <section>
226 </section> 228 <h3>{{ _("Who runs the GNS root zone?") }}</h3>
227 229 <p>
228 <section> 230 {% trans %}
229 <h3>{{ _("What is the difference between GNS and CoDoNS?") }}</h3> 231 A: Short answer: you. The long answer is the GNUnet will ship with a
230 <p> 232 default configuration of top-level domains. The governance of this default
231 {% trans %} 233 configuration is not yet established. In any case, the user will be able
232 A: CoDoNS decentralizes the DNS database (using a DHT) but preserves the 234 to modify this configuration at will. We expect normal users to have
233 authority structure of DNS. With CoDoNS, IANA/ICANN are still in charge, and 235 no need to edit their own GNS zone(s) unless they host services themselves.
234 there are still registrars that determine who owns a name. 236 {% endtrans %}
235 <br><br> 237 </p>
236 With GNS, we decentralize the database and also decentralize the 238 </section>
237 responsibility for naming: each user runs his own personal root zone and is 239
238 thus in complete control of the names he uses. GNS also has many additional 240 <section>
239 features (to keep names short and enable migration) which don't even make 241 <h3>{{ _("Where is the per-user GNS database kept?") }}</h3>
240 sense in the context of CoDoNS. 242 <p>
241 243 {% trans %}
242 {% endtrans %} 244 A: The short answer is that the database is kept at the user's GNUnet peer.
243 </p> 245 Now, a user may run multiple GNUnet peers, in which case the database could be
244 </section> 246 kept at each peer (however, we don't have code for convenient replication).
245 247 Similarly, multiple GNUnet peers can share one instance of the database ---
246 <section> 248 the &quot;gnunet-service-namestore&quot; can be accessed from remote
247 <h3>{{ _("What is the difference between GNS and SocialDNS?") }}</h3> 249 (via TCP). The actual data can be stored in a Postgres database, for which
248 <p> 250 various replication options are again applicable. Ultimately, there are many
249 {% trans %} 251 options for how users can store (and secure) their GNS database.
250 A: Like GNS, SocialDNS allows each user to create DNS mappings. However, with 252 {% endtrans %}
251 SocialDNS the mappings are shared through the social network and subjected to 253 </p>
252 ranking. As the social relationships evolve, names can thus change in 254 </section>
253 surprising ways. 255
254 <br><br> 256
255 With GNS, names are primarily shared via delegation, and thus mappings will 257 <section>
256 only change if the user responsible for the name (the authority) manually 258 <h3>{{ _("What is the expected average size of a GNS namestore database?") }}</h3>
257 changes the record. 259 <p>
258 {% endtrans %} 260 {% trans %}
259 </p> 261 A: Pretty small. Based on our user study where we looked at browser histories
260 </section> 262 and the number of domains visited, we expect that GNS databases will only
261 263 grow to a few tens of thousands of entries, small enough to fit even on mobile
262 <section> 264 devices.
263 <h3>{{ _("What is the difference between GNS and ODDNS?") }}</h3> 265 {% endtrans %}
264 <p> 266 </p>
265 {% trans %} 267 </section>
266 A: ODDNS is primarily designed to bypass the DNS root zone and the TLD 268
267 registries (such as those for ".com" and ".org"). Instead of using those, 269 <section>
268 each user is expected to maintain a database of (second-level) domains 270 <h3>{{ _("Is GNS resistant to the attacks on DNS used by the US?") }}</h3>
269 (like "gnu.org") and the IP addresses of the respective name servers. 271 <p>
270 Resolution will fail if the target name servers change IPs. 272 {% trans %}
271 {% endtrans %} 273 A: We believe so, as there is no entity that any government could force to
272 </p> 274 change the mapping for a name except for each individual user (and then the
273 </section> 275 changes would only apply to the names that this user is the authority for).
274 276 So if everyone used GNS, the only practical attack of a government would be to
275 <section> 277 force the operator of a server to change the GNS records for his server to
276 <h3>{{ _("What is the difference between GNS and Namecoin?") }}</h3> 278 point elsewhere. However, if the owner of the private key for a zone is
277 <p> 279 unavailable for enforcement, the respective zone cannot be changed and any
278 </p> 280 other zone delegating to this zone will achieve proper resolution.
279 </section> 281 {% endtrans %}
280 282 </p>
281 283 </section>
282 <section> 284
283 <h3>{{ _("What is the difference between GNS and Handshake?") }}</h3> 285 <section>
284 <p> 286 <h3>{{ _("What is the difference between GNS and CoDoNS?") }}</h3>
285 </p> 287 <p>
286 </section> 288 {% trans %}
287 289 A: CoDoNS decentralizes the DNS database (using a DHT) but preserves the
288 <section> 290 authority structure of DNS. With CoDoNS, IANA/ICANN are still in charge, and
289 <h3>{{ _("What is the difference between GNS and ENS?") }}</h3> 291 there are still registrars that determine who owns a name.
290 <p> 292 <br><br>
291 </p> 293 With GNS, we decentralize the database and also decentralize the
292 </section> 294 responsibility for naming: each user runs his own personal root zone and is
293 295 thus in complete control of the names he uses. GNS also has many additional
294 <section> 296 features (to keep names short and enable migration) which don't even make
295 <h3>{{ _("What is the difference between GNS and TrickleDNS?") }}</h3> 297 sense in the context of CoDoNS.
296 <p> 298
297 {% trans %} 299 {% endtrans %}
298 A: TrickleDNS pushes (&quot;critical&quot;) DNS records between DNS resolvers 300 </p>
299 of participating domains to provide &quot;better availability, lower query 301 </section>
300 resolution times, and faster update propagation&quot;. Thus TrickleDNS is 302
301 focused on defeating attacks on the availability (and performance) of record 303 <section>
302 propagation in DNS, for example via DDoS attacks on DNS root servers. 304 <h3>{{ _("What is the difference between GNS and SocialDNS?") }}</h3>
303 TrickleDNS is thus concerned with how to ensure distribution of authoritative 305 <p>
304 records, and authority remains derived from the DNS hierarchy. 306 {% trans %}
305 {% endtrans %} 307 A: Like GNS, SocialDNS allows each user to create DNS mappings. However, with
306 </p> 308 SocialDNS the mappings are shared through the social network and subjected to
307 </section> 309 ranking. As the social relationships evolve, names can thus change in
308 310 surprising ways.
309 <section> 311 <br><br>
310 <h3>{{ _("Does GNS require real-world introduction (secure PKEY exchange) in the style of the PGP web of trust?") }}</h3> 312 With GNS, names are primarily shared via delegation, and thus mappings will
311 <p> 313 only change if the user responsible for the name (the authority) manually
312 {% trans %} 314 changes the record.
313 A: For security, it is well known that an initial trust path between the two 315 {% endtrans %}
314 parties must exist. However, for applications where this is not required, 316 </p>
315 weaker mechanisms can be used. For example, we have implemented a 317 </section>
316 first-come-first-served (FCFS) authority which allows arbitrary users to 318
317 register arbitrary names. The key of this authority is included with every 319 <section>
318 GNUnet installation. Thus, any name registered with FCFS is in fact global and 320 <h3>{{ _("What is the difference between GNS and ODDNS?") }}</h3>
319 requires no further introduction. However, the security of these names 321 <p>
320 depends entirely on the trustworthiness of the FCFS authority. 322 {% trans %}
321 The authority can be queried under the &quot;.pin&quot; TLD. 323 A: ODDNS is primarily designed to bypass the DNS root zone and the TLD
322 {% endtrans %} 324 registries (such as those for ".com" and ".org"). Instead of using those,
323 </p> 325 each user is expected to maintain a database of (second-level) domains
324 </section> 326 (like "gnu.org") and the IP addresses of the respective name servers.
325 327 Resolution will fail if the target name servers change IPs.
326 <section> 328 {% endtrans %}
327 <h3>{{ _("How can a legitimate domain owner tell other people to not use his name in GNS?") }}</h3> 329 </p>
328 <p> 330 </section>
329 {% trans %} 331
330 A: Names have no owners in GNS, so there cannot be a &quot;legitimate&quot; 332 <section>
331 domain owner. Any user can claim any name (as his preferred name or 333 <h3>{{ _("What is the difference between GNS and Namecoin?") }}</h3>
332 &quot;pseudonym&quot;) in his NICK record. Similarly, all other users can 334 <p>
333 choose to ignore this preference and use a name of their choice (or even 335 </p>
334 assign no name) for this user. 336 </section>
335 {% endtrans %} 337
336 </p> 338
337 </section> 339 <section>
338 340 <h3>{{ _("What is the difference between GNS and Handshake?") }}</h3>
339 <section> 341 <p>
340 <h3>{{ _("Did you consider the privacy implications of making your personal GNS zone visible?") }}</h3> 342 </p>
341 <p> 343 </section>
342 {% trans %} 344
343 A: Each record in GNS has a flag &quot;private&quot;. Records are shared with 345 <section>
344 other users (via DHT or zone transfers) only if this flag is not set. 346 <h3>{{ _("What is the difference between GNS and ENS?") }}</h3>
345 Thus, users have full control over what information about their zones is made 347 <p>
346 public. 348 </p>
347 {% endtrans %} 349 </section>
348 </p> 350
349 </section> 351 <section>
350 352 <h3>{{ _("What is the difference between GNS and TrickleDNS?") }}</h3>
351 <section> 353 <p>
352 <h3>{{ _("Are \"Legacy Host\" (LEHO) records not going to be obsolete with IPv6?") }}</h3> 354 {% trans %}
353 <p> 355 A: TrickleDNS pushes (&quot;critical&quot;) DNS records between DNS resolvers
354 {% trans %} 356 of participating domains to provide &quot;better availability, lower query
355 A: The question presumes that (a) virtual hosting is only necessary because of 357 resolution times, and faster update propagation&quot;. Thus TrickleDNS is
356 IPv4 address scarcity, and (b) that LEHOs are only useful in the context of 358 focused on defeating attacks on the availability (and performance) of record
357 virtual hosting. However, LEHOs are also useful to help with X.509 certificate 359 propagation in DNS, for example via DDoS attacks on DNS root servers.
358 validation (as they specify for which legacy hostname the certificate should 360 TrickleDNS is thus concerned with how to ensure distribution of authoritative
359 be valid). Also, even with IPv6 fully deployed and &quot;infinite&quot; IP 361 records, and authority remains derived from the DNS hierarchy.
360 addresses being available, we're not sure that virtual hosting would 362 {% endtrans %}
361 disappear. Finally, we don't want to have to wait for IPv6 to become 363 </p>
362 commonplace, GNS should work with today's networks. 364 </section>
363 {% endtrans %} 365
364 </p> 366 <section>
365 </section> 367 <h3>{{ _("Does GNS require real-world introduction (secure PKEY exchange) in the style of the PGP web of trust?") }}</h3>
366 368 <p>
367 <section> 369 {% trans %}
368 <h3>{{ _("Why does GNS not use a trust metric or consensus to determine globally unique names?") }}</h3> 370 A: For security, it is well known that an initial trust path between the two
369 <p> 371 parties must exist. However, for applications where this is not required,
370 {% trans %} 372 weaker mechanisms can be used. For example, we have implemented a
371 A: Trust metrics have the fundamental problem that they have thresholds. 373 first-come-first-served (FCFS) authority which allows arbitrary users to
372 As trust relationships evolve, mappings would change their meaning as they 374 register arbitrary names. The key of this authority is included with every
373 cross each others thresholds. We decided that the resulting unpredictability 375 GNUnet installation. Thus, any name registered with FCFS is in fact global and
374 of the resolution process was not acceptable. Furthermore, trust and consensus 376 requires no further introduction. However, the security of these names
375 might be easy to manipulate by adversaries. 377 depends entirely on the trustworthiness of the FCFS authority.
376 {% endtrans %} 378 The authority can be queried under the &quot;.pin&quot; TLD.
377 </p> 379 {% endtrans %}
378 </section> 380 </p>
379 381 </section>
380 <section> 382
381 <h3>{{ _("How do you handle compromised zone keys in GNS?") }}</h3> 383 <section>
382 <p> 384 <h3>{{ _("How can a legitimate domain owner tell other people to not use his name in GNS?") }}</h3>
383 {% trans %} 385 <p>
384 A: The owner of a private key can create a revocation message. This one can 386 {% trans %}
385 then be flooded throughout the overlay network, creating a copy at all peers. 387 A: Names have no owners in GNS, so there cannot be a &quot;legitimate&quot;
386 Before using a public key, peers check if that key has been revoked. 388 domain owner. Any user can claim any name (as his preferred name or
387 All names that involve delegation via a revoked zone will then fail to 389 &quot;pseudonym&quot;) in his NICK record. Similarly, all other users can
388 resolve. Peers always automatically check for the existence of a revocation 390 choose to ignore this preference and use a name of their choice (or even
389 message when resolving names. 391 assign no name) for this user.
390 {% endtrans %} 392 {% endtrans %}
391 </p> 393 </p>
392 </section> 394 </section>
393 395
394 <section> 396 <section>
395 <h3>{{ _("Could the signing algorithm of GNS be upgraded in the future?") }}</h3> 397 <h3>{{ _("Did you consider the privacy implications of making your personal GNS zone visible?") }}</h3>
396 <p> 398 <p>
397 {% trans %} 399 {% trans %}
398 A: Yes. In our efforts to standardize GNS, we have already modified the protocol 400 A: Each record in GNS has a flag &quot;private&quot;. Records are shared with
399 to support alternative delegation records. 401 other users (via DHT or zone transfers) only if this flag is not set.
400 <br> 402 Thus, users have full control over what information about their zones is made
401 <br> 403 public.
402 Naturally, deployed GNS implementations would have to be updated to support 404 {% endtrans %}
403 the new signature scheme. The new scheme can then be run in parallel with 405 </p>
404 the existing system by using a new record type to indicate the use of a 406 </section>
405 different cipher system. 407
406 {% endtrans %} 408 <section>
407 </p> 409 <h3>{{ _("Are \"Legacy Host\" (LEHO) records not going to be obsolete with IPv6?") }}</h3>
408 </section> 410 <p>
409 411 {% trans %}
410 <section> 412 A: The question presumes that (a) virtual hosting is only necessary because of
411 <h3>{{ _("How can a GNS zone maintain several name servers, e.g. for load balancing?") }}</h3> 413 IPv4 address scarcity, and (b) that LEHOs are only useful in the context of
412 <p> 414 virtual hosting. However, LEHOs are also useful to help with X.509 certificate
413 {% trans %} 415 validation (as they specify for which legacy hostname the certificate should
414 A: We don't expect this to be necessary, as GNS records are stored (and 416 be valid). Also, even with IPv6 fully deployed and &quot;infinite&quot; IP
415 replicated) in the R5N DHT. Thus the authority will typically not be contacted 417 addresses being available, we're not sure that virtual hosting would
416 whenever clients perform a lookup. Even if the authority goes (temporarily) 418 disappear. Finally, we don't want to have to wait for IPv6 to become
417 off-line, the DHT will cache the records for some time. However, should having 419 commonplace, GNS should work with today's networks.
418 multiple servers for a zone be considered truly necessary, the owner of the 420 {% endtrans %}
419 zone can simply run multiple peers (and share the zone's key and database 421 </p>
420 among them). 422 </section>
421 {% endtrans %} 423
422 </p> 424 <section>
423 </section> 425 <h3>{{ _("Why does GNS not use a trust metric or consensus to determine globally unique names?") }}</h3>
424 426 <p>
425 <section> 427 {% trans %}
426 <h3>{{ _("Why do you believe it is worth giving up unique names for censorship resistance?") }}</h3> 428 A: Trust metrics have the fundamental problem that they have thresholds.
427 <p> 429 As trust relationships evolve, mappings would change their meaning as they
428 {% trans %} 430 cross each others thresholds. We decided that the resulting unpredictability
429 A: The GNU Name system offers an alternative to DNS that is censorship 431 of the resolution process was not acceptable. Furthermore, trust and consensus
430 resistant. As with any security mechanism, this comes at a cost (names are not 432 might be easy to manipulate by adversaries.
431 globally unique). To draw a parallel, HTTPS connections use more bandwidth and 433 {% endtrans %}
432 have higher latency than HTTP connections. Depending on your application, 434 </p>
433 HTTPS may not be worth the cost. However, for users that are experiencing 435 </section>
434 censorship (or are concerned about it), giving up globally unique names may 436
435 very well be worth the cost. After all, what is a &quot;globally&quot; unique 437 <section>
436 name worth, if it does not resolve? 438 <h3>{{ _("How do you handle compromised zone keys in GNS?") }}</h3>
437 {% endtrans %} 439 <p>
438 </p> 440 {% trans %}
439 </section> 441 A: The owner of a private key can create a revocation message. This one can
440 442 then be flooded throughout the overlay network, creating a copy at all peers.
441 <section> 443 Before using a public key, peers check if that key has been revoked.
442 <h3>{{ _("Why do you say that DNS is 'centralized' and 'distributed'?") }}</h3> 444 All names that involve delegation via a revoked zone will then fail to
443 <p> 445 resolve. Peers always automatically check for the existence of a revocation
444 {% trans %} 446 message when resolving names.
445 A: We say that DNS is 'centralized' because it has a central component / 447 {% endtrans %}
446 central point of failure --- the root zone and its management by IANA/ICANN. 448 </p>
447 This centralization creates vulnerabilities. For example, the US government 449 </section>
448 was able to reassign the management of the country-TLDs of Afganistan and Iraq 450
449 during the wars at the beginning of the 21st century. 451 <section>
450 {% endtrans %} 452 <h3>{{ _("Could the signing algorithm of GNS be upgraded in the future?") }}</h3>
451 </p> 453 <p>
452 </section> 454 {% trans %}
453 455 A: Yes. In our efforts to standardize GNS, we have already modified the protocol
454 <section> 456 to support alternative delegation records.
455 <h3>{{ _("How does GNS protect against layer-3 censorship?") }}</h3> 457 <br>
456 <p> 458 <br>
457 {% trans %} 459 Naturally, deployed GNS implementations would have to be updated to support
458 A: GNS does not directly help with layer-3 censorship, but it does help 460 the new signature scheme. The new scheme can then be run in parallel with
459 indirectly in two ways: 461 the existing system by using a new record type to indicate the use of a
460 462 different cipher system.
461 <ol> 463 {% endtrans %}
462 <li> Many websites today use virtual hosting, so blocking a particular IP 464 </p>
463 address causes much more collateral damage than blocking a DNS name. 465 </section>
464 It thus raises the cost of censorship.</li> 466
465 <li> Existing layer-3 circumvention solutions (such as Tor) would benefit from 467 <section>
466 a censorship resistant naming system. Accessing Tor's &quot;.onion&quot; 468 <h3>{{ _("How can a GNS zone maintain several name servers, e.g. for load balancing?") }}</h3>
467 namespace currently requires users to use unmemorable cryptographic 469 <p>
468 identifiers. With nicer names, Tor and tor2web-like services would be even 470 {% trans %}
469 easier to use. 471 A: We don't expect this to be necessary, as GNS records are stored (and
470 </ol> 472 replicated) in the R5N DHT. Thus the authority will typically not be contacted
471 {% endtrans %} 473 whenever clients perform a lookup. Even if the authority goes (temporarily)
472 </p> 474 off-line, the DHT will cache the records for some time. However, should having
473 </section> 475 multiple servers for a zone be considered truly necessary, the owner of the
474 476 zone can simply run multiple peers (and share the zone's key and database
475 <section> 477 among them).
476 <h3>{{ _("Does GNS work with search engines?") }}</h3> 478 {% endtrans %}
477 <p> 479 </p>
478 {% trans %} 480 </section>
479 A: GNS creates no significant problems for search engines, as they can use GNS 481
480 to perform name resolution as well as any normal user. Naturally, while we 482 <section>
481 typically expect normal users to install custom software for name resolution, 483 <h3>{{ _("Why do you believe it is worth giving up unique names for censorship resistance?") }}</h3>
482 this is unlikely to work for search engines today. However, the DNS2GNS 484 <p>
483 gateway allows search engines to use DNS to resolve GNS names, so they can 485 {% trans %}
484 still index GNS resources. However, as using DNS2GNS gateways breaks the 486 A: The GNU Name system offers an alternative to DNS that is censorship
485 cryptographic chain of trust, legacy search engines will obviously not obtain 487 resistant. As with any security mechanism, this comes at a cost (names are not
486 censorship-resistant names. 488 globally unique). To draw a parallel, HTTPS connections use more bandwidth and
487 {% endtrans %} 489 have higher latency than HTTP connections. Depending on your application,
488 </p> 490 HTTPS may not be worth the cost. However, for users that are experiencing
489 </section> 491 censorship (or are concerned about it), giving up globally unique names may
490 492 very well be worth the cost. After all, what is a &quot;globally&quot; unique
491 <section> 493 name worth, if it does not resolve?
492 <h3>{{ _("How does GNS compare to the Unmanaged Internet Architecture (UIA)?") }}</h3> 494 {% endtrans %}
493 <p> 495 </p>
494 {% trans %} 496 </section>
495 A: UIA and GNS both share the same basic naming model, which actually 497
496 originated with Rivest's SDSI. However, UIA is not concerned about integration 498 <section>
497 with legacy applications and instead focuses on universal connectivity between 499 <h3>{{ _("Why do you say that DNS is 'centralized' and 'distributed'?") }}</h3>
498 a user's many machines. In contrast, GNS was designed to interoperate with DNS 500 <p>
499 as much as possible, and to also work as much as possible with the existing 501 {% trans %}
500 Web infrastructure. UIA is not at all concerned about legacy systems (clean 502 A: We say that DNS is 'centralized' because it has a central component /
501 slate). 503 central point of failure --- the root zone and its management by IANA/ICANN.
502 {% endtrans %} 504 This centralization creates vulnerabilities. For example, the US government
503 </p> 505 was able to reassign the management of the country-TLDs of Afganistan and Iraq
504 </section> 506 during the wars at the beginning of the 21st century.
505 507 {% endtrans %}
506 <section> 508 </p>
507 <h3>{{ _("Doesn't GNS increase the trusted-computing base compared to DNS(SEC)?") }}</h3> 509 </section>
508 <p> 510
509 {% trans %} 511 <section>
510 A: First of all, in GNS you can explicitly see the trust chain, so you know if 512 <h3>{{ _("How does GNS protect against layer-3 censorship?") }}</h3>
511 a name you are resolving belongs to a friend, or a friend-of-a-friend, and can 513 <p>
512 thus decide how much you trust the result. Naturally, the trusted-computing 514 {% trans %}
513 base (TCB) can become arbitrarily large this way --- however, given the name 515 A: GNS does not directly help with layer-3 censorship, but it does help
514 length restriction, for an individual name it is always less than about 128 516 indirectly in two ways:
515 entities. 517
516 {% endtrans %} 518 <ol>
517 </p> 519 <li> Many websites today use virtual hosting, so blocking a particular IP
518 </section> 520 address causes much more collateral damage than blocking a DNS name.
519 521 It thus raises the cost of censorship.</li>
520 <section> 522 <li> Existing layer-3 circumvention solutions (such as Tor) would benefit from
521 <h3>{{ _("How does GNS handle SRV/TLSA records where service and protocol are part of the domain name?") }}</h3> 523 a censorship resistant naming system. Accessing Tor's &quot;.onion&quot;
522 <p> 524 namespace currently requires users to use unmemorable cryptographic
523 {% trans %} 525 identifiers. With nicer names, Tor and tor2web-like services would be even
524 A: When GNS splits a domain name into labels for resolution, it detects the 526 easier to use.
525 &quot;_Service._Proto&quot; syntax, converts &quot;Service&quot; to the 527 </ol>
526 corresponding port number and &quot;Proto&quot; to the corresponding protocol 528 {% endtrans %}
527 number. The rest of the name is resolved as usual. Then, when the result is 529 </p>
528 presented, GNS looks for the GNS-specific &quot;BOX&quot; record type. 530 </section>
529 A BOX record is a record that contains another record (such as SRV or TLSA 531
530 records) and adds a service and protocol number (and the original boxed record 532 <section>
531 type) to it. 533 <h3>{{ _("Does GNS work with search engines?") }}</h3>
532 {% endtrans %} 534 <p>
533 </p> 535 {% trans %}
534 </section> 536 A: GNS creates no significant problems for search engines, as they can use GNS
535 537 to perform name resolution as well as any normal user. Naturally, while we
536 538 typically expect normal users to install custom software for name resolution,
537 539 this is unlikely to work for search engines today. However, the DNS2GNS
538 540 gateway allows search engines to use DNS to resolve GNS names, so they can
539 <h2><a name="errors" class="subnav-anchor"></a>{{ _("Error messages") }}</h2> 541 still index GNS resources. However, as using DNS2GNS gateways breaks the
540 <section> 542 cryptographic chain of trust, legacy search engines will obviously not obtain
541 <h3>{{ _("I receive many &quot;WARNING Calculated flow delay for X at Y for Z&quot;. Should I worry?") }}</h3> 543 censorship-resistant names.
542 <p> 544 {% endtrans %}
543 {% trans %} 545 </p>
544 A: Right now, this is expected and a known cause for high 546 </section>
545 latency in GNUnet. We have started a major rewrite to address 547
546 this and other problems, but until the Transport Next 548 <section>
547 Generation (TNG) is ready, these warnings are expected. 549 <h3>{{ _("How does GNS compare to the Unmanaged Internet Architecture (UIA)?") }}</h3>
548 {% endtrans %} 550 <p>
549 </p> 551 {% trans %}
550 </section> 552 A: UIA and GNS both share the same basic naming model, which actually
551 <section> 553 originated with Rivest's SDSI. However, UIA is not concerned about integration
552 <h3>{{ _("Error opening `/dev/net/tun': No such file or directory?") }}</h3> 554 with legacy applications and instead focuses on universal connectivity between
553 <p> 555 a user's many machines. In contrast, GNS was designed to interoperate with DNS
554 {% trans %} 556 as much as possible, and to also work as much as possible with the existing
555 A: If you get this error message, the solution is simple. Issue the following 557 Web infrastructure. UIA is not at all concerned about legacy systems (clean
556 commands (as root) to create the required device file 558 slate).
557 {% endtrans %} 559 {% endtrans %}
558 <code class="block"> 560 </p>
559 # mkdir /dev/net<br> 561 </section>
560 # mknod /dev/net/tun c 10 200<br> 562
561 </code> 563 <section>
562 </p> 564 <h3>{{ _("Doesn't GNS increase the trusted-computing base compared to DNS(SEC)?") }}</h3>
563 </section> 565 <p>
564 566 {% trans %}
565 <section> 567 A: First of all, in GNS you can explicitly see the trust chain, so you know if
566 <h3>{{ _("'iptables: No chain/target/match by that name.' (when running gnunet-service-dns)?") }}</h3> 568 a name you are resolving belongs to a friend, or a friend-of-a-friend, and can
567 <p> 569 thus decide how much you trust the result. Naturally, the trusted-computing
568 {% trans %} 570 base (TCB) can become arbitrarily large this way --- however, given the name
569 A: For GNUnet DNS, your iptables needs to have &quot;owner&quot; match 571 length restriction, for an individual name it is always less than about 128
570 support. 572 entities.
571 573 {% endtrans %}
572 This is accomplished by having the correct kernel options. Check if your 574 </p>
573 kernel has CONFIG_NETFILTER_XT_MATCH_OWNER set to either 'y' or 'm' (and the 575 </section>
574 module is loaded). 576
575 {% endtrans %} 577 <section>
576 </p> 578 <h3>{{ _("How does GNS handle SRV/TLSA records where service and protocol are part of the domain name?") }}</h3>
577 </section> 579 <p>
578 580 {% trans %}
579 <section> 581 A: When GNS splits a domain name into labels for resolution, it detects the
580 <h3>{{ _("'Timeout was reached' when running PT on Fedora (and possibly others)?") }}</h3> 582 &quot;_Service._Proto&quot; syntax, converts &quot;Service&quot; to the
581 <p> 583 corresponding port number and &quot;Proto&quot; to the corresponding protocol
582 {% trans %} 584 number. The rest of the name is resolved as usual. Then, when the result is
583 A: If you get an error stating that the VPN timeout was reached, check if your 585 presented, GNS looks for the GNS-specific &quot;BOX&quot; record type.
584 firewall is enabled and blocking the connections. 586 A BOX record is a record that contains another record (such as SRV or TLSA
585 {% endtrans %} 587 records) and adds a service and protocol number (and the original boxed record
586 </p> 588 type) to it.
587 </section> 589 {% endtrans %}
588 590 </p>
589 591 </section>
590 </article> 592
593 <hr/>
594 <h2><a name="errors" class="subnav-anchor"></a>{{ _("Error messages") }}</h2>
595 <section>
596 <h3>{{ _("I receive many &quot;WARNING Calculated flow delay for X at Y for Z&quot;. Should I worry?") }}</h3>
597 <p>
598 {% trans %}
599 A: Right now, this is expected and a known cause for high
600 latency in GNUnet. We have started a major rewrite to address
601 this and other problems, but until the Transport Next
602 Generation (TNG) is ready, these warnings are expected.
603 {% endtrans %}
604 </p>
605 </section>
606 <section>
607 <h3>{{ _("Error opening `/dev/net/tun': No such file or directory?") }}</h3>
608 <p>
609 {% trans %}
610 A: If you get this error message, the solution is simple. Issue the following
611 commands (as root) to create the required device file
612 {% endtrans %}
613 <code class="block">
614 # mkdir /dev/net<br>
615 # mknod /dev/net/tun c 10 200<br>
616 </code>
617 </p>
618 </section>
619
620 <section>
621 <h3>{{ _("'iptables: No chain/target/match by that name.' (when running gnunet-service-dns)?") }}</h3>
622 <p>
623 {% trans %}
624 A: For GNUnet DNS, your iptables needs to have &quot;owner&quot; match
625 support.
626
627 This is accomplished by having the correct kernel options. Check if your
628 kernel has CONFIG_NETFILTER_XT_MATCH_OWNER set to either 'y' or 'm' (and the
629 module is loaded).
630 {% endtrans %}
631 </p>
632 </section>
633
634 <section>
635 <h3>{{ _("'Timeout was reached' when running PT on Fedora (and possibly others)?") }}</h3>
636 <p>
637 {% trans %}
638 A: If you get an error stating that the VPN timeout was reached, check if your
639 firewall is enabled and blocking the connections.
640 {% endtrans %}
641 </p>
642 </section>
643
644 <section>
645 <h3>{{ _("I'm getting an 'error while loading shared libraries: libgnunetXXX.so.X'") }}</h3>
646 <p>
647 {% trans %}
648 A: This error usually occurs when your linker fails to locate one of GNUnet's
649 libraries. This can have two causes. First, it is theoretically possible that
650 the library is not installed on your system; however, if you compiled GNUnet
651 the normal way and/or used a binary package, that is highly unlikely. The more
652 common cause is that you installed GNUnet to a directory that your linker
653 does not search. There are several ways to fix this that are described below.
654
655 If you are 'root' and you installed to a system folder (such as /usr/local),
656 you want to add the libraries to the system-wide search path. This is done by
657 adding a line "/usr/local/lib/" to /etc/ld.so.conf and running "ldconfig".
658 If you installed GNUnet to /opt or any other similar path, you obviously have
659 to change "/usr/local" accordingly.
660
661 If you do not have 'root' rights or if you installed GNUnet to say
662 "/home/$USER/", then you can explicitly tell your linker to search a
663 particular directory for libraries using the "LD_LIBRARY_PATH" environment
664 variable. For example, if you configured GNUnet using a prefix of
665 "$HOME/gnunet/" you want to run:
666 {% endtrans %}
667 </p>
668 <code>
669 $ export LD_LIBRARY_PATH=$HOME/gnunet/lib:$LD_LIBRARY_PATH<br>
670 $ export PATH=$HOME/gnunet/bin:$PATH
671 </code>
672 </p>
673 {% trans %}
674 to ensure GNUnet's binaries and libraries are found. In order to avoid having to do so each time, you can add the above lines (without the "$") to your .bashrc or .profile file. You will have to logout and login again to have this new profile be applied to all shells (including your desktop environment).
675 {% endtrans %}
676 </p>
677 </section>
678
679 <section>
680 <h3>{{ _("What error messages can be ignored?") }}</h3>
681 <p>
682 {% trans %}
683 A: Error messages flagged as "DEBUG" should be disabled in binaries
684 built for end-users and can always be ignored.
685
686 Error messages flagged as "INFO" always refer to harmless events that
687 require no action. For example, GNUnet may use an INFO message to
688 indicate that it is currently performing an expensive operation that
689 will take some time. GNUnet will also use INFO messages to display
690 information about important configuration values.
691 {% endtrans %}
692 </p>
693 </section>
694
695 <hr/>
696 <h2><a name="fs" class="subnav-anchor"></a>{{ _("File-sharing")}}</h2>
697 <section>
698 <h3>{{ _("How does GNUnet compare to other file-sharing applications?") }}</h3>
699 <p>
700 {% trans %}
701 A: As opposed to Napster, Gnutella, Kazaa, FastTrack, eDonkey and most
702 other P2P networks, GNUnet was designed with security in mind as the
703 highest priority. We intend on producing a network with comprehensive
704 security features. Many other P2P networks are open to a wide variety
705 of attacks, and users have little privacy. GNUnet is also Free
706 Software and thus the source code is available, so you do not have to
707 worry about being spied upon by the software. The following table
708 summarises the main differences between GNUnet and other systems.
709 The information is accurate to the best of our knowledge.
710 The comparison is difficult since there are sometimes differences
711 between various implementations of (almost) the same protocol.
712 In general, we pick a free implementation as the reference
713 implementation since it is possible to inspect the free code. Also,
714 all of these systems are changing over time and thus the data below
715 may not be up-to-date. If you find any flaws, please let us know.
716 Finally, the table is not saying terribly much (it is hard to compare
717 these systems this briefly), so if you want the real differences, read
718 the research papers (and probably the code).
719 {% endtrans %}
720 </p>
721 <table width="90%" border="0" cellpadding="0" cellspacing="0"><tbody><tr><th >Network</th>
722 <th ><a>GNUnet FS</a></th>
723 <th ><a>OneSwarm</th>
724 <th ><a>Napster</th>
725 <th ><a>Direct Connect</th>
726 <th ><a>FastTrack</th>
727 <th ><a>eDonkey</th>
728 <th ><a>Gnutella</th>
729 <th ><a>Freenet</th>
730 </tr><tr><th >Distributed Queries</th>
731 <td >yes</td>
732 <td >yes</td>
733 <td >no</td>
734 <td >hubs</td>
735 <td >super-peers</td>
736 <td >DHT (eMule)</td>
737 <td >yes</td>
738 <td >yes</td>
739 </tr><tr><th >Multisource Download</th>
740 <td >yes</td>
741 <td >yes</td>
742 <td >no</td>
743 <td >no</td>
744 <td >yes</td>
745 <td >yes</td>
746 <td >yes</td>
747 <td >no</td>
748 </tr><tr><th >Economics</th>
749 <td >yes</td>
750 <td >yes</td>
751 <td >no</td>
752 <td >no</td>
753 <td >no</td>
754 <td >yes</td>
755 <td >no</td>
756 <td >no</td>
757 </tr><tr><th >Anonymity</th>
758 <td >yes</td>
759 <td >maybe</td>
760 <td >no</td>
761 <td >no</td>
762 <td >no</td>
763 <td >no</td>
764 <td >no</td>
765 <td >yes</td>
766 </tr><tr><th >Language</th>
767 <td >C</td>
768 <td >Java</td>
769 <td >often C</td>
770 <td >C++</td>
771 <td >C</td>
772 <td >C++</td>
773 <td >often C</td>
774 <td >Java</td>
775 </tr><tr><th >Transport Protocol</th>
776 <td >UDP, TCP, SMTP, HTTP</td>
777 <td >TCP</td>
778 <td >TCP</td>
779 <td >TCP?</td>
780 <td >UDP, TCP</td>
781 <td >UDP, TCP</td>
782 <td >TCP</td>
783 <td >TCP</td>
784 </tr><tr><th >Query Format (UI)</th>
785 <td >keywords / CHK</td>
786 <td >filename / SHA?</td>
787 <td >keywords</td>
788 <td >filename, THEX</td>
789 <td >filename, SHA</td>
790 <td >filename, MD4?</td>
791 <td >filename, SHA</td>
792 <td >secret key, CHK</td>
793 </tr><tr><th >Routing</th>
794 <td >dynamic (indirect, direct)</td>
795 <td >static (indirect, direct)</td>
796 <td >always direct</td>
797 <td >always direct</td>
798 <td >always direct</td>
799 <td >always direct</td>
800 <td >always direct</td>
801 <td >always indirect</td>
802 </tr><tr><th >License</th>
803 <td >GPL</td>
804 <td >GPL</td>
805 <td >GPL (knapster)</td>
806 <td >GPL (Valknut)</td>
807 <td >GPL (giFT)</td>
808 <td >GPL (eMule)</td>
809 <td >GPL (gtk-gnutella)</td>
810 <td >GPL</td>
811 </tr></tbody>
812 </table>
813 <p>
814 {% trans %}
815 Another important point of reference are the various anonymous
816 peer-to-peer networks.
817 Here, there are differences in terms of application domain and how
818 specifically anonymity is achieved.
819 Anonymous routing is a hard research topic, so for a superficial
820 comparisson like this one we focus on the latency.
821 Another important factor is the programming language.
822 Type-safe languages may offer certain security benefits; however, this may come at the cost of significant increases in resource consumption which in turn may reduce anonymity.
823 {% endtrans %}
824 </p>
825 </section>
826 <section>
827 <h3>{{ _("Are there any known attacks (on GNUnet's file-sharing application)?") }}</h3>
828 <p>
829 {% trans %}
830 A: Generally, there is the possibility of a known plaintext attack on
831 keywords, but since the user has control over the keywords that are
832 associated with the content he inserts, the user can take advantage of
833 the same techniques used to generate reasonable passwords to defend
834 against such an attack. In any event, we are not trying to hide
835 content; thus, unless the user is trying to insert information into
836 the network that can only be shared with a small group of people,
837 there is no real reason to try to obfuscate the content by choosing a
838 difficult keyword anyway.
839 {% endtrans %}
840 </p>
841 </section>
842 <section>
843 <h3>{{ _("What do you mean by anonymity?") }}</h3>
844 <p>
845 {% trans %}
846 A: Anonymity is the lack of distinction of an individual from a
847 (large) group. A central goal for anonymous file-sharing in GNUnet is
848 to make all users (peers) form a group and to make communications in
849 that group anonymous, that is, nobody (but the initiator) should be
850 able to tell which of the peers in the group originated the message.
851 In other words, it should be difficult to impossible for an adversary
852 to distinguish between the originating peer and all other peers.
853 {% endtrans %}
854 </p>
855 </section>
856 <section>
857 <h3>{{ _("What does my system do when participating in GNUnet file sharing?") }}</h3>
858 <p>
859 {% trans %}
860 A: In GNUnet you set up a node (a peer). It is identified by an ID (hash
861 of its public key) and has a number of addresses it is reachable by
862 (may have no addresses, for instance when it's behind a NAT).
863 You specify bandwidth limits (how much traffic GNUnet is allowed to
864 consume) and datastore quote (how large your on-disk block storage is)
865 . Your node will then proceed to connect to other nodes, becoming
866 part of the network.
867 {% endtrans %}
868 </p>
869 </section>
870
871 <hr/>
872 <h2><a name="contrib" class="subnav-anchor"></a>{{ _("Contributing")}}</h2>
873 <section>
874 <h3>{{ _("How can I help translate this webpage into other languages?") }}</h3>
875 <p>
876 {% trans %}
877 A: First, you need to register an account with our weblate system.
878 Please send an e-mail with the desired target language to
879 translators@gnunet.org or ask for help on the #gnunet chat on
880 irc.freenode.net. Typically someone with sufficient permissions will
881 then grant you access. Naturally, any abuse will result in the loss
882 of permissions.
883 {% endtrans %}
884 </p>
885 </section>
886
887 <section>
888 <h3>{{ _("I have some great idea for a new feature, what should I do?") }}</h3>
889 <p>
890 {% trans %}
891 A: Sadly, we have many more feature requests than we can possibly
892 implement. The best way to actually get a new feature implemented is
893 to do it yourself --- and to then send us a patch.
894 {% endtrans %}
895 </p>
896 </section>
897
898
899 </article>
591 </div> <!-- col --> 900 </div> <!-- col -->
592</div> <!-- row--> 901 </div> <!-- row-->
593 902
594 903
595<!-- 904 <!--
596<h2>{{ ("Q?") }}</h2> 905 <h2>{{ ("Q?") }}</h2>
597 906
598<h2>{{ ("Q?") }}</h2> 907 <h2>{{ ("Q?") }}</h2>
599 908
600<h2>{{ ("Q?") }}</h2> 909 <h2>{{ ("Q?") }}</h2>
601--> 910 -->
602 911
603</div> 912</div>
604{% endblock body_content %} 913{% endblock body_content %}
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-23 07:21:09 +0000