{% extends "common/base.j2" %} {% block body_content %}

{{ _("GNU Taler: Design Principles") }}

{% trans %} When designing GNU Taler, we had the following design principles in mind: {% endtrans %}

{{ _("1. Free/Libre Software") }}

{{ _(

{% trans %} GNU Taler must be Free/Libre Software. For merchants, Free/Libre Software prevents vendor lock-in meaning merchants can easily choose another service provider to process their payments. For countries, Free/Libre software means GNU Taler can not compromise sovereignty by imposing restrictions or requirements. And for exchange operators, transparency is crucial to satisfy Kerckhoff's principle and to establish public confidence. {% endtrans %}

{% trans %} Customers benefit from Free/Libre Software because anyone is free to modify the wallet software support additional platforms. The source code must be available and make it easy to verify that user-hostile features such as tracking or telemetry are absent. {% endtrans %}

{{ _("2. Protect the privacy of buyers") }}

{{_(

{% trans %} Privacy is most meaningful when it is guaranteed via technical measures, as opposed to mere policies. Without a technical layer providing privacy-by-default, financial transactions reveal unnecessary levels of personal or private data. This would be especially true when making micropayments for online publications. Thus, GNU Taler must protect the privacy of buyers to avoid facilitating totalitarian control over the population. {% endtrans %} {% trans %} Limited private data, such as the shipping address for a physical delivery, may need to be collected according to business needs and protected according to local laws. In this case, GNU Taler must enable deletion of such data as soon as it is no longer required. {% endtrans %}

{{ _("3. Auditability - enable the state to tax income and crack down on illegal business activities") }}

{{_(

{% trans %} As a payment system must comply with local laws in order to operate legally, GNU Taler must be designed to comply with these requirements. GNU Taler must provide an audit trail for investigators operating under the law. Furthermore, we consider levying of taxes as beneficial to society, and fair taxation requires income transparency. Thus, GNU Taler must enable authorities to track income. {% endtrans %}

{{ _("4. Prevent payment fraud") }}

{{_(

{% trans %} GNU Taler must mitigate the most common sources of payment fraud. We must follow best practices in software design, 3rd party design guidelines that prevent confusion and misleading user interfaces, and must have others inspect our publicly available code. Furthermore, GNU Taler must provide extensive cryptographic evidence for all key processes to enable all parties to precisely attribute bad behavior. {% endtrans %}

{{ _("5. Collect the minimum information necessary") }}

{{_(

{% trans %} The privacy of buyers is given particular priority as part of principle (2). However, other parties - such as merchants - also must have data protection. Generally, GNU Taler must collect the minimum information necessary: data that is not collected or is no longer stored can not be compromised. {% endtrans %}

{{ _("6. Be usable") }}

{{_(

{% trans %} GNU Taler must be usable for non-expert customers including end-users of a GNU Taler wallet, merchants who wish to accept payments using GNU Taler, and 3rd party application developers for e-commerce and other platforms. GNU Taler must follow best-practices usability guidelines and incorporate feedback from experts and users. Free/Libre software also requires Free/Libre documentation to allow for informed choices. GNU Taler must provide well-documented Application Programming Interfaces (APIs) to allow frictionless integrations between GNU Taler and other projects. {% endtrans %}

{{ _("7. Be efficient")}}

{{_(

{% trans %} GNU Taler must be designed to be efficient. Quite simply, efficiency means fewer things to break, and it means more transactions per second and lowers our environmental impact. Efficiency is also critical for GNU Taler to be used for micropayments. Therefore certain expensive primitives, such as proof-of-work, must not be used by GNU Taler. {% endtrans %}

{{ _("8. Fault-tolerant design")}}

{{_(

{% trans %} Malicious operators, fat fingers, computer glitches, gremlins. Things go wrong. GNU Taler must be designed to tolerate failure of individual components and systems. Where the system can continue running safely, it will continue running safely. Where it must halt an operation, other operations must not be needlessly pulled offline. Where systems fail, they must fail gracefully. GNU Taler must have a plan to recover from malicious operators compromising core secrets. {% endtrans %}

{{ _("9. Foster competition")}}

{{_(

{% trans %} It must be relatively easy for competitors to deploy interoperable alternatives. The barriers for this in traditional financial systems are rather high and outside of our control. However, GNU Taler must minimize the technical burden for new competitors to enter the market. GNU Taler must enable a diverse set of operators, breaking up the current system where only a few global companies dominate the market. An example for a design choice that supports this is to split the whole system into smaller components that can be operated, developed and improved upon independently, instead of having one completely monolithic system. {% endtrans %}

{% endblock body_content %}