{% 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</h1>
    </div>
  </div>
  <div class="row">
    <div class="col">
      <p>The complete design of GNU Taler is comprehensively described in a <a href="thesis.pdf">PhD Thesis by Florian Dold</a>.</p>
      <p>When designing GNU Taler, we had the following design goals 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 %}