diff options
author | Christian Grothoff <christian@grothoff.org> | 2019-06-27 13:20:31 +0200 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2019-06-27 13:20:31 +0200 |
commit | 9e7994ad4cadc91d91648716bc121022dc113495 (patch) | |
tree | e6fcb3b8f127bc4e8ec0c61cfb95eb0543e67279 /principles.html.j2 | |
parent | c59f9d3b6f4805eace9f2345a4f7f1d0e9344b96 (diff) | |
download | www-9e7994ad4cadc91d91648716bc121022dc113495.tar.gz www-9e7994ad4cadc91d91648716bc121022dc113495.tar.bz2 www-9e7994ad4cadc91d91648716bc121022dc113495.zip |
update footer, rename design to princiles
Diffstat (limited to 'principles.html.j2')
-rw-r--r-- | principles.html.j2 | 149 |
1 files changed, 149 insertions, 0 deletions
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 %} |