[GNUnet-SVN] [gnunet] 01/02: linelength adjustments in 'philosophy'

[gnunet]

This is an automated email from the git hooks/post-receive script.

ng0 pushed a commit to branch master
in repository gnunet.

commit 9b9a2c8b892d62d62d0995a5a792f83e6c67c186
Author: ng0 <address@hidden>
AuthorDate: Fri Oct 20 15:29:28 2017 +0000

    linelength adjustments in 'philosophy'
---
 doc/chapters/philosophy.texi | 283 +++++++++++++++++++++++++------------------
 1 file changed, 162 insertions(+), 121 deletions(-)

diff --git a/doc/chapters/philosophy.texi b/doc/chapters/philosophy.texi
index d2d1f9289..c4572e6df 100644
--- a/doc/chapters/philosophy.texi
+++ b/doc/chapters/philosophy.texi
@@ -1,4 +1,3 @@
address@hidden 
***************************************************************************
 @node Philosophy
 @chapter Philosophy
 
@@ -23,7 +22,7 @@ generation of decentralized Internet protocols.
 @end menu
 
 
address@hidden 
***************************************************************************
address@hidden Design Goals
 @node Design Goals
 @section Design Goals
 
@@ -31,85 +30,100 @@ These are the core GNUnet design goals, in order of 
relative importance:
 
 @itemize
 @item GNUnet must be implemented as free software.
address@hidden GNUnet must only disclose the minimal amount of information 
necessary.
address@hidden GNUnet must be decentralised and survive Byzantine failures in 
any position in the network.
address@hidden GNUnet must make it explicit to the user which entities must be 
trustworthy when establishing secured communications.
address@hidden GNUnet must use compartmentalization to protect sensitive 
information.
address@hidden GNUnet must only disclose the minimal amount of information
+necessary.
address@hidden GNUnet must be decentralised and survive Byzantine failures in 
any
+position in the network.
address@hidden GNUnet must make it explicit to the user which entities must be
+trustworthy when establishing secured communications.
address@hidden GNUnet must use compartmentalization to protect sensitive
+information.
 @item GNUnet must be open and permit new peers to join.
 @item GNUnet must be self-organizing and not depend on administrators.
 @item GNUnet must support a diverse range of applications and devices.
 @item The GNUnet architecture must be cost effective.
address@hidden GNUnet must provide incentives for peers to contribute more 
resources than they consume.
address@hidden GNUnet must provide incentives for peers to contribute more
+resources than they consume.
 @end itemize
 
 
address@hidden Security and Privacy
 @node Security & Privacy
 @section Security & Privacy
 
-GNUnet's primary design goals are to protect the privacy of its users and to
-guard itself against attacks or abuse. GNUnet does not have any mechanisms
-to control, track or censor users. Instead, the GNUnet protocols aim to make
-it as hard as possible to find out what is happening on the network or to
-disrupt operations. 
+GNUnet's primary design goals are to protect the privacy of its users and
+to guard itself against attacks or abuse.
+GNUnet does not have any mechanisms to control, track or censor users.
+Instead, the GNUnet protocols aim to make it as hard as possible to
+find out what is happening on the network or to disrupt operations. 
 
address@hidden Versatility
 @node Versatility
 @section Versatility
 
 We call GNUnet a peer-to-peer framework because we want to support many
 different forms of peer-to-peer applications. GNUnet uses a plugin
 architecture to make the system extensible and to encourage code reuse.
-While the first versions of the system only supported anonymous file-sharing,
-other applications are being worked on and more will hopefully follow in the
-future. A powerful synergy regarding anonymity services is created by a large
+While the first versions of the system only supported anonymous
+file-sharing, other applications are being worked on and more will
+hopefully follow in the future.
+A powerful synergy regarding anonymity services is created by a large
 community utilizing many diverse applications over the same software
 infrastructure. The reason is that link encryption hides the specifics
 of the traffic for non-participating observers. This way, anonymity can
 get stronger with additional (GNUnet) traffic, even if the additional
 traffic is not related to anonymous communication. Increasing anonymity is
 the primary reason why GNUnet is developed to become a peer-to-peer
-framework where many applications share the lower layers of an increasingly
-complex protocol stack. If merging traffic to hinder traffic analysis was
-not important, we could have just developed a dozen stand-alone applications
+framework where many applications share the lower layers of an
+increasingly complex protocol stack.
+If merging traffic to hinder traffic analysis was not important,
+we could have just developed a dozen stand-alone applications
 and a few shared libraries. 
 
address@hidden Practicality
 @node Practicality
 @section Practicality
 
-GNUnet allows participants to trade various amounts of security in exchange
-for increased efficiency. However, it is not possible for any user's security
-and efficiency requirements to compromise the security and efficiency of
-any other user. 
+GNUnet allows participants to trade various amounts of security in
+exchange for increased efficiency. However, it is not possible for any
+user's security and efficiency requirements to compromise the security
+and efficiency of any other user.
 
-For GNUnet, efficiency is not paramount. If there is a more secure and still
-practical approach, we would choose to take the more secure alternative.
address@hidden is more efficient than @command{ssh}, yet it is obsolete.
+For GNUnet, efficiency is not paramount. If there is a more secure and
+still practical approach, we would choose to take the more secure
+alternative. @command{telnet} is more efficient than @command{ssh}, yet
+it is obsolete.
 Hardware gets faster, and code can be optimized. Fixing security issues as
 an afterthought is much harder. 
 
-While security is paramount, practicability is still a requirement. The most
-secure system is always the one that nobody can use. Similarly, any
-anonymous system that is extremely inefficient will only find few users.
+While security is paramount, practicability is still a requirement.
+The most secure system is always the one that nobody can use.
+Similarly, any anonymous system that is extremely inefficient will only
+find few users.
 However, good anonymity requires a large and diverse user base. Since
-individual security requirements may vary, the only good solution here is to
-allow individuals to trade-off security and efficiency. The primary challenge
-in allowing this is to ensure that the economic incentives work properly.
+individual security requirements may vary, the only good solution here is
+to allow individuals to trade-off security and efficiency.
+The primary challenge in allowing this is to ensure that the economic
+incentives work properly.
 In particular, this means that it must be impossible for a user to gain
 security at the expense of other users. Many designs (e.g. anonymity via
-broadcast) fail to give users an incentive to choose a less secure but more
-efficient mode of operation. GNUnet should avoid where ever possible to
-rely on protocols that will only work if the participants are benevolent.
+broadcast) fail to give users an incentive to choose a less secure but
+more efficient mode of operation.
+GNUnet should avoid where ever possible to rely on protocols that will
+only work if the participants are benevolent.
 While some designs have had widespread success while relying on parties
 to observe a protocol that may be sub-optimal for the individuals (e.g.
 TCP Nagle), a protocol that ensures that individual goals never conflict
 with the goals of the group is always preferable.
 
address@hidden Key Concepts
 @node Key Concepts
 @section Key Concepts
 
-In this section, the fundamental concepts of GNUnet are explained.  Most of
-them are also described in our research papers.  First, some of the concepts
-used in the GNUnet framework are detailed.  The second part describes concepts
-specific to anonymous file-sharing.
+In this section, the fundamental concepts of GNUnet are explained.
+Most of them are also described in our research papers.
+First, some of the concepts used in the GNUnet framework are detailed.
+The second part describes concepts specific to anonymous file-sharing.
 
 @menu
 * Authentication::
@@ -122,6 +136,7 @@ specific to anonymous file-sharing.
 * Egos::
 @end menu
 
address@hidden Authentication
 @node Authentication
 @subsection Authentication
 
@@ -148,64 +163,75 @@ IP protocol at all (by running directly on layer 2).
 GNUnet uses a special type of message to communicate a binding between
 public (ECC) keys to their current network address. These messages are
 commonly called HELLOs or peer advertisements. They contain the public key
-of the peer and its current network addresses for various transport services.
+of the peer and its current network addresses for various transport
+services.
 A transport service is a special kind of shared library that
-provides (possibly unreliable, out-of-order) message delivery between peers.
-For the UDP and TCP transport services, a network address is an IP and a port.
+provides (possibly unreliable, out-of-order) message delivery between
+peers.
+For the UDP and TCP transport services, a network address is an IP and a
+port.
 GNUnet can also use other transports (HTTP, HTTPS, WLAN, etc.) which use
-various other forms of addresses. Note that any node can have many different
+various other forms of addresses. Note that any node can have many
+different
 active transport services at the same time, and each of these can have a
 different addresses. Binding messages expire after at most a week (the
-timeout can be shorter if the user configures the node appropriately). This
-expiration ensures that the network will eventually get rid of outdated
-advertisements.
address@hidden details can be found in @uref{https://gnunet.org/transports, A 
Transport Layer Abstraction for Peer-to-Peer Networks}}
+timeout can be shorter if the user configures the node appropriately).
+This expiration ensures that the network will eventually get rid of
+outdated address@hidden details can be found in
address@hidden://gnunet.org/transports, A Transport Layer Abstraction for
+Peer-to-Peer Networks}}
 
address@hidden Resource Sharing
 @node Accounting to Encourage Resource Sharing
 @subsection Accounting to Encourage Resource Sharing
 
-Most distributed P2P networks suffer from a lack of defenses or precautions
-against attacks in the form of freeloading. While the intentions of an
-attacker and a freeloader are different, their effect on the network is the
-same; they both render it useless. Most simple attacks on networks such as
-Gnutella involve flooding the network with traffic, particularly with
-queries that are, in the worst case, multiplied by the network. 
+Most distributed P2P networks suffer from a lack of defenses or
+precautions against attacks in the form of freeloading.
+While the intentions of an attacker and a freeloader are different, their
+effect on the network is the same; they both render it useless.
+Most simple attacks on networks such as Gnutella involve flooding the
+network with traffic, particularly with queries that are, in the worst
+case, multiplied by the network. 
 
-In order to ensure that freeloaders or attackers have a minimal impact on the
-network, GNUnet's file-sharing implementation tries to distinguish
+In order to ensure that freeloaders or attackers have a minimal impact on
+the network, GNUnet's file-sharing implementation tries to distinguish
 good (contributing) nodes from malicious (freeloading) nodes. In GNUnet,
 every file-sharing node keeps track of the behavior of every other node it
 has been in contact with. Many requests (depending on the application) are
-transmitted with a priority (or importance) level. That priority is used to
-establish how important the sender believes this request is. If a peer
-responds to an important request, the recipient will increase its trust in the
-responder: the responder contributed resources. If a peer is too busy to
-answer all requests, it needs to prioritize. For that, peers to not take the
-priorities of the requests received at face value. First, they check how much
-they trust the sender, and depending on that amount of trust they assign the
-request a (possibly lower) effective priority. Then, they drop the requests
-with the lowest effective priority to satisfy their resource constraints. This
-way, GNUnet's economic model ensures that nodes that are not currently
-considered to have a surplus in contributions will not be served if the
-network load is high.
address@hidden details can be found in @uref{https://gnunet.org/ebe, this 
paper}}
-
+transmitted with a priority (or importance) level. That priority is used
+to establish how important the sender believes this request is. If a peer
+responds to an important request, the recipient will increase its trust in
+the responder: the responder contributed resources. If a peer is too busy
+to answer all requests, it needs to prioritize. For that, peers to not
+take the priorities of the requests received at face value.
+First, they check how much they trust the sender, and depending on that
+amount of trust they assign the request a (possibly lower) effective
+priority. Then, they drop the requests with the lowest effective priority
+to satisfy their resource constraints. This way, GNUnet's economic model
+ensures that nodes that are not currently considered to have a surplus in
+contributions will not be served if the network load is address@hidden
+e details can be found in @uref{https://gnunet.org/ebe, this paper}}
+
address@hidden Confidentiality
 @node Confidentiality
 @subsection Confidentiality
 
-Adversaries outside of GNUnet are not supposed to know what kind of actions a
-peer is involved in. Only the specific neighbor of a peer that is the
-corresponding sender or recipient of a message may know its contents, and even
-then application protocols may place further restrictions on that knowledge.
-In order to ensure confidentiality, GNUnet uses link encryption, that is each
-message exchanged between two peers is encrypted using a pair of keys only
-known to these two peers. Encrypting traffic like this makes any kind of
-traffic analysis much harder. Naturally, for some applications, it may still
-be desirable if even neighbors cannot determine the concrete contents of a
-message. In GNUnet, this problem is addressed by the specific
-application-level protocols (see for example, deniability and anonymity in
-anonymous file sharing).
-
+Adversaries outside of GNUnet are not supposed to know what kind of
+actions a peer is involved in. Only the specific neighbor of a peer that
+is the corresponding sender or recipient of a message may know its
+contents, and even then application protocols may place further
+restrictions on that knowledge.
+In order to ensure confidentiality, GNUnet uses link encryption, that is
+each message exchanged between two peers is encrypted using a pair of
+keys only known to these two peers.
+Encrypting traffic like this makes any kind of traffic analysis much
+harder. Naturally, for some applications, it may still be desirable if
+even neighbors cannot determine the concrete contents of a message.
+In GNUnet, this problem is addressed by the specific application-level
+protocols (see for example, deniability and anonymity in anonymous file
+sharing).
+
address@hidden Anonymity
 @node Anonymity
 @subsection Anonymity
 
@@ -214,14 +240,16 @@ anonymous file sharing).
 @end menu
 
 Providing anonymity for users is the central goal for the anonymous
-file-sharing application. Many other design decisions follow in the footsteps
-of this requirement. Anonymity is never absolute. While there are various
+file-sharing application. Many other design decisions follow in the
+footsteps of this requirement.
+Anonymity is never absolute. While there are various
 @uref{https://gnunet.org/anonymity_metric, scientific metrics} that can
 help quantify the level of anonymity that a given mechanism provides,
 there is no such thing as complete anonymity.
 GNUnet's file-sharing implementation allows users to select for each
 operation (publish, search, download) the desired level of anonymity.
-The metric used is the amount of cover traffic available to hide the request.
+The metric used is the amount of cover traffic available to hide the
+request.
 While this metric is not as good as, for example, the theoretical metric
 given in @uref{https://gnunet.org/anonymity_metric, scientific metrics},
 it is probably the best metric available to a peer with a purely local
@@ -236,10 +264,12 @@ allows GNUnet to use more efficient, non-anonymous 
routing.
 
 Contrary to other designs, we do not believe that users achieve strong
 anonymity just because their requests are obfuscated by a couple of
-indirections. This is not sufficient if the adversary uses traffic analysis.
-The threat model used for anonymous file sharing in GNUnet assumes that the
-adversary is quite powerful. In particular, we assume that the adversary can
-see all the traffic on the Internet. And while we assume that the adversary
+indirections. This is not sufficient if the adversary uses traffic
+analysis.
+The threat model used for anonymous file sharing in GNUnet assumes that
+the adversary is quite powerful.
+In particular, we assume that the adversary can see all the traffic on
+the Internet. And while we assume that the adversary
 can not break our encryption, we assume that the adversary has many
 participating nodes in the network and that it can thus see many of the
 node-to-node interactions since it controls some of the nodes. 
@@ -251,25 +281,29 @@ Hiding actions in the traffic of other users requires 
participating in the
 traffic, bringing back the traditional technique of using indirection and
 source rewriting. Source rewriting is required to gain anonymity since
 otherwise an adversary could tell if a message originated from a host by
-looking at the source address. If all packets look like they originate from
-a node, the adversary can not tell which ones originate from that node and
-which ones were routed. Note that in this mindset, any node can decide to
-break the source-rewriting paradigm without violating the protocol, as this
-only reduces the amount of traffic that a node can hide its own traffic in. 
+looking at the source address. If all packets look like they originate
+from a node, the adversary can not tell which ones originate from that
+node and which ones were routed.
+Note that in this mindset, any node can decide to break the
+source-rewriting paradigm without violating the protocol, as this
+only reduces the amount of traffic that a node can hide its own traffic
+in. 
 
 If we want to hide our actions in the traffic of other nodes, we must make
-our traffic indistinguishable from the traffic that we route for others. As
-our queries must have us as the receiver of the reply (otherwise they would
-be useless), we must put ourselves as the receiver of replies that actually
-go to other hosts; in other words, we must indirect replies. Unlike other
-systems, in anonymous file-sharing as implemented on top of GNUnet we do not
-have to indirect the replies if we don't think we need more traffic to hide
-our own actions.
+our traffic indistinguishable from the traffic that we route for others.
+As our queries must have us as the receiver of the reply
+(otherwise they would be useless), we must put ourselves as the receiver
+of replies that actually go to other hosts; in other words, we must
+indirect replies.
+Unlike other systems, in anonymous file-sharing as implemented on top of
+GNUnet we do not have to indirect the replies if we don't think we need
+more traffic to hide our own actions.
 
 This increases the efficiency of the network as we can indirect less under
-higher load.
address@hidden details can be found in @uref{https://gnunet.org/gap, this 
paper}}
+higher address@hidden details can be found in @uref{https://gnunet.
+org/gap, this paper}}
 
address@hidden Deniability
 @node Deniability
 @subsection Deniability
 
@@ -279,49 +313,56 @@ intermediaries can find out which queries or which 
content they are
 processing, a strong adversary could try to force them to censor
 certain materials. 
 
-With the file-encoding used by GNUnet's anonymous file-sharing, this problem
-does not arise.  The reason is that queries and replies are transmitted in
+With the file-encoding used by GNUnet's anonymous file-sharing, this
+problem does not arise.
+The reason is that queries and replies are transmitted in
 an encrypted format such that intermediaries cannot tell what the query
 is for or what the content is about.  Mind that this is not the same
 encryption as the link-encryption between the nodes.  GNUnet has
 encryption on the network layer (link encryption, confidentiality,
 authentication) and again on the application layer (provided
-by @command{gnunet-publish}, @command{gnunet-download}, @command{gnunet-search}
-and @command{gnunet-gtk}).
address@hidden details can be found @uref{https://gnunet.org/encoding, here}}
+by @command{gnunet-publish}, @command{gnunet-download},
address@hidden and @command{gnunet-gtk})address@hidden details
+can be found @uref{https://gnunet.org/encoding, here}}
 
address@hidden Peer Identities
 @node Peer Identities
 @subsection Peer Identities
 
-Peer identities are used to identify peers in the network and are unique for
-each peer.  The identity for a peer is simply its public key, which is
+Peer identities are used to identify peers in the network and are unique
+for each peer.  The identity for a peer is simply its public key, which is
 generated along with a private key the peer is started for the first time.
 While the identity is binary data, it is often expressed as ASCII string.
 For example, the following is a peer identity as you might see it in
-various places: @code{ UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0}
+various places:
address@hidden UAT1S6PMPITLBKSJ2DGV341JI6KF7B66AC4JVCN9811NNEGQLUN0}
 
 You can find your peer identity by running @command{gnunet-peerinfo -s}.
 
address@hidden GNS Zones
 @node Zones in the GNU Name System (GNS Zones)
 @subsection Zones in the GNU Name System (GNS Zones)
 
 GNS zones are similar to those of DNS zones, but instead of a hierarchy of
-authorities to governing their use, GNS zones are controlled by a private key.
+authorities to governing their use, GNS zones are controlled by a private
+key.
 When you create a record in a DNS zone, that information stored in your
-nameserver.  Anyone trying to resolve your domain then gets pointed (hopefully)
-by the centralised authority to your nameserver.  Whereas GNS, being
-decentralised by design, stores that information in DHT.  The validity of the
-records is assured cryptographically, by signing them with the private key of
-the respective zone.
+nameserver.  Anyone trying to resolve your domain then gets pointed
+(hopefully) by the centralised authority to your nameserver.
+Whereas GNS, being decentralised by design, stores that information in
+DHT.  The validity of the records is assured cryptographically, by
+signing them with the private key of the respective zone.
 
 Anyone trying to resolve records in a zone your domain can then verify the
-signature on the records they get from the DHT and be assured that they are
-indeed from the respective zone.  To make this work, there is a 1:1
-correspondence between zones and their public-private key pairs.  So when we
-talk about the owner of a GNS zone, that's really the owner of the private
-key.  And a user accessing a zone needs to somehow specify the corresponding
+signature on the records they get from the DHT and be assured that they
+are indeed from the respective zone.  To make this work, there is a 1:1
+correspondence between zones and their public-private key pairs.
+So when we talk about the owner of a GNS zone, that's really the owner of
+the private key.
+And a user accessing a zone needs to somehow specify the corresponding
 public key first.
 
address@hidden Egos
 @node Egos
 @subsection Egos
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden