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