From 6fd5c929848e59a669b3a30eac8c09a18f5b4e8a Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Mon, 1 Jun 2020 17:15:18 +0200 Subject: principles edits based on collected feedback --- template/principles.html.j2 | 134 +++++++++++++++++++++++++++----------------- 1 file changed, 84 insertions(+), 50 deletions(-) (limited to 'template') diff --git a/template/principles.html.j2 b/template/principles.html.j2 index 02dea048..1a741f4d 100644 --- a/template/principles.html.j2 +++ b/template/principles.html.j2 @@ -28,25 +28,29 @@

-

{{ _("1. Free Software implementation") }}

+

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

{{ _(

{% 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 %}

@@ -58,35 +62,37 @@ {{_(

{% 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 %}

-

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

+

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

{{_(

{% 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 %}

@@ -98,22 +104,30 @@ {{_(

{% 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 %}

-

{{ _("5. Only disclose the minimal amount of information necessary") }}

+

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

{{_(

{% 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 %}

@@ -124,10 +138,16 @@ {{_(

{% 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 %}

@@ -138,9 +158,12 @@ {{_(

{% 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