From 9e7994ad4cadc91d91648716bc121022dc113495 Mon Sep 17 00:00:00 2001
From: Christian Grothoff <christian@grothoff.org>
Date: Thu, 27 Jun 2019 13:20:31 +0200
Subject: update footer, rename design to princiles

---
 principles.html.j2 | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 principles.html.j2

(limited to 'principles.html.j2')

diff --git a/principles.html.j2 b/principles.html.j2
new file mode 100644
index 00000000..95f51a1f
--- /dev/null
+++ b/principles.html.j2
@@ -0,0 +1,149 @@
+{% extends "common/base.j2" %}
+{% block body_content %}
+
+<script>
+function expand(n) {
+  var x = document.getElementById(n);
+  console.log(x);
+  x.setAttribute("style", "");
+}
+</script>
+
+<style>
+h2 {
+  margin-top: 1em;
+}
+</style>
+
+
+<div class="container">
+  <div class="row">
+    <div class="col">
+    <h1>GNU Taler: Design Principles</h1>
+    </div>
+  </div>
+  <div class="row">
+    <div class="col">
+      <p>When designing GNU Taler, we had the following design principles in mind.</p>
+
+      <h2>1. Free Software implementation <a onclick="expand('x1')">(+)</a></h2>
+      <div id="x1" style="display: none">
+      <p>
+        Free refers to “free as in free speech”, as opposed to “free as in free beer”.
+        More specifically, the four essential freedoms of free software must
+        be respected, namely users must have the freedom to (1) run the software,
+        (2) study and modify it, (3) redistribute copies, and (4) distribute copies of
+        the modified version.
+      </p>
+      <p>
+        For merchants this prevents vendor lock-in, as another payment provider can
+        take over, should the current one provide inadequate quality of service. As
+        the software of the payment provider itself is free, smaller or disadvantaged
+        countries or organizations can run the payment system without being
+        controlled by a foreign company. Customers benefit from this freedom,
+        as the wallet software can be made to run on a variety of platforms, and
+        user-hostile features such as tracking or telemetry could easily be removed
+        from wallet software.
+      </p>
+      <p>
+        This rules out the mandatory usage of specialized hardware such as smart
+        cards or other hardware security modules, as the software they run cannot
+        be modified by the user. These components can, however, be voluntarily
+        used by merchants, customers or payment processors to increase their
+        operational security.
+      </p>
+      </div>
+
+      <h2>2. Protect the privacy of buyers <a onclick="expand('x2')">(+)</a></h2>
+      <div id="x2" style="display: none">
+      <p>
+        Privacy should be guaranteed via technical measures, as opposed to mere
+        policies. Especially with micropayments for online content, a disproportion-
+        ate amount of rather private data about buyers would be revealed, if the
+        payment system does not have privacy protections.
+      </p>
+      <p>
+        In legislations with data protection regulations (such as the recently introduced GDPR in Europe),
+        merchants benefit from this as well, as
+        no data breach of customers can happen if this information is, by design,
+        not collected in the first place. Obviously some private data, such as the
+        shipping address for a physical delivery, must still be collected according to
+        business needs.
+      </p>
+      </div>
+
+      <h2>3. Enable the state to tax income and crack down on illegal business activities <a onclick="expand('x3')">(+)</a></h2>
+      <div id="x3" style="display: none">
+      <p>
+        As a payment system must still be legal to operate and use, it must comply
+        with these requirements. Furthermore, we consider levying of taxes as
+        beneficial to society.
+      </p>
+      </div>
+
+      <h2>4. Prevent payment fraud <a onclick="expand('x4')">(+)</a></h2>
+      <div id="x4" style="display: none">
+      <p>
+        This imposes requirements on the security of the system, as well as on the
+        general design, as payment fraud can also happen through misleading user
+        interface design or the lack of cryptographic evidence for certain processes.
+      </p>
+      </div>
+
+      <h2>5. Only disclose the minimal amount of information nec-
+essary <a onclick="expand('x5')">(+)</a></h2>
+      <div id="x5" style="display: none">
+      <p>
+        The reason behind this goal is similar to (2). The privacy of buyers is given
+        priority, but other parties such as merchants still benefit from it, for example,
+        by keeping details about the merchant’s financials hidden from competitors.
+      </p>
+      </div>
+
+      <h2>6. Be usable <a onclick="expand('x6')">(+)</a></h2>
+      <div id="x6" style="display: none">
+      <p>
+Specifically it must be usable for non-expert customers. Usability also
+applies to the integration with merchants, and informs choices about the
+architecture, such as encapsulating procedures that require cryptographic
+operations into an isolated component with a simple API.
+      </p>
+      </div>
+
+      <h2>7. Be efficient <a onclick="expand('x7')">(+)</a></h2>
+      <div id="x7" style="display: none">
+      <p>
+Approaches such as proof-of-work are ruled out by this requirement. Effi-
+ciency is necessary for GNU Taler to be used for micropayments.
+      </p>
+      </div>
+
+      <h2>8. Avoid single points of failure <a onclick="expand('x8')">(+)</a></h2>
+      <div id="x8" style="display: none">
+      <p>
+While the design we present later is rather centralized, avoiding single
+points of failure is still a goal. This manifests in architectural choices such
+as the isolation of certain components, and auditing procedures.
+      </p>
+      </div>
+
+      <h2>9. Foster competition <a onclick="expand('x9')">(+)</a></h2>
+      <div id="x9" style="display: none">
+      <p>
+It must be relatively easy for competitors to join the systems. While the
+barriers for this in traditional financial systems are rather high, the technical
+burden for new competitors to join must be minimized. Another design
+choice that supports this is to split the whole system into smaller compo-
+nents that can be operated, developed and improved upon independently,
+instead of having one completely monolithic system.
+      </p>
+      </div>
+
+    </div>
+    <div class="col">
+      <img class="img-fluid" src="../images/diagram-complex.png">
+    </div>
+  </div>
+</div>
+
+{% endblock body_content %}
-- 
cgit v1.2.3