From 6fd5c929848e59a669b3a30eac8c09a18f5b4e8a Mon Sep 17 00:00:00 2001
From: Christian Grothoff
{% trans %} - GNU Taler must be Free Software. - For merchants, our Free Software - reference implementation prevents vendor lock-in. As - the software of the payment provider itself is free, countries can - deploy the payment system without compromising sovereignty. + 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 Software - as the wallet software can be made to run on a variety of platforms, and - the absence of user-hostile features such as tracking or telemetry can easily be - assured. + 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 %}
{% trans %} - Privacy should be guaranteed via technical measures, as opposed to mere - policies. Especially with micropayments for online publications, a disproportionate - amount of rather private data about buyers would be revealed, if the - payment system does not have privacy protections. + 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 %} - 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. + 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 %}
{% trans %} - As a payment system must be legal to operate and use, it must comply - with regulatory requirements such as anti money laundering. - Furthermore, we consider levying of taxes as - beneficial to society, and fair taxation requires income transparency. + 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 %}
{% trans %} - 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. + 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 %}
{% trans %} - 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. + 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 %}
{% trans %} - 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. + 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 Advanced Programming Interfaces (APIs) + to allow frictionless integrations between GNU Taler and other projects. {% endtrans %}
{% trans %} - Approaches such as proof-of-work are ruled out by this - requirement. Efficiency is necessary for GNU Taler to be used for - micropayments. + 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 %}
@@ -151,10 +174,17 @@{% trans %} - Taler should tolerate failure of individual components and systems, - including malicious operators compromising core secrets. - This manifests in architectural choices such - as the isolation of certain components, and auditing procedures. + 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 %}
@@ -165,11 +195,15 @@{% trans %} - It must be relatively easy for competitors to deploy interoperable alternatives. While the - barriers for this in traditional financial systems are rather high, the technical - burden for new competitors to join must be minimized. A design - choice that supports this is to split the whole system into smaller components - that can be operated, developed and improved upon independently, + 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. + {% endtrans %} + + {% trans %} + 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 %}
-- cgit v1.2.3