diff options
Diffstat (limited to 'design.html.j2')
| -rw-r--r-- | design.html.j2 | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/design.html.j2 b/design.html.j2 new file mode 100644 index 00000000..896dbe5e --- /dev/null +++ b/design.html.j2 @@ -0,0 +1,150 @@ +{% 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 %} |