[GNUnet-SVN] [taler-www] branch stable updated (3d05a2a -> b68abec)

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a change to branch stable
in repository www.

    from 3d05a2a  add Libra link
     add a5b4f15  expand glossary to explain zombie coins
     add b68abec  add more images

No new revisions were added by this update.

Summary of changes:
 glossary.html.j2       |  41 +++++++++++++++++++++++++++++++++++++++++
 images/buy.jpg         | Bin 0 -> 138098 bytes
 images/buy.medium.jpg  | Bin 0 -> 61721 bytes
 images/gdpr.jpg        | Bin 0 -> 135295 bytes
 images/gdpr.medium.jpg | Bin 0 -> 66861 bytes
 principles.html.j2     |   2 ++
 6 files changed, 43 insertions(+)
 create mode 100644 images/buy.jpg
 create mode 100644 images/buy.medium.jpg
 create mode 100644 images/gdpr.jpg
 create mode 100644 images/gdpr.medium.jpg

diff --git a/glossary.html.j2 b/glossary.html.j2
index 997f19b..2736935 100644
--- a/glossary.html.j2
+++ b/glossary.html.j2
@@ -57,6 +57,20 @@
      Taler's payment service provider.  Issues electronic `coins` during 
`withdrawal` and redeems them when they are `deposited` by merchants.
     {% endtrans %}
   </dd>
+<dt>{{ _("expired") }}</dt>
+  <dd>
+    {% trans %}
+     Various operations come with time limits. In particular, `denomination 
keys`
+     come with strict time limits for the various operations involving the
+     `coin` issued under the `denomination`. The most important limit is the
+     `deposit` expiration, which specifies until when wallets are allowed to
+     use the coin in `deposit` or `refreshing` operations. There is also a 
"legal"
+     expiration, which specifies how long the exchange keeps records beyond the
+     `deposit` expiration time.  This latter expiration matters for legal 
disputes
+     in courts and also creates an upper limit for `refreshing` operations on
+     special `zombie coin`.
+    {% endtrans %}
+  </dd>
 <dt>{{ _("extension") }}</dt>
   <dd>
     {% trans %}
@@ -98,6 +112,14 @@
      a `coin` is owned by the entity that knows the private key of the coin
     {% endtrans %}
   </dd>
+<dt>{{ _("payback") }}</dt>
+  <dd>
+    {% trans %}
+     operation by which an exchange returns the value of coins affected
+     by a `revocation` to their `owner`, either by allowing the owner to
+     withdraw new coins or wiring funds back to the bank account of the `owner`
+    {% endtrans %}
+  </dd>
 <dt>{{ _("proof") }}</dt>
   <dd>
     {% trans %}
@@ -128,6 +150,12 @@
      operation by which a merchant steps back from the right to funds that he 
obtained from a `deposit` operation, giving the right to the funds back to the 
customer
     {% endtrans %}
   </dd>
+<dt>{{ _("revocation") }}</dt>
+  <dd>
+    {% trans %}
+     exceptional operation by which an exchange withdraws a denomination from 
circulation, either because the signing key was compromised or because the 
exchange is going out of operation; unspent coins of a revoked denomination are 
subjected to payback.
+    {% endtrans %}
+  </dd>
 <dt>{{ _("sharing") }}</dt>
   <dd>
     {% trans %}
@@ -188,6 +216,19 @@
      operation by which a `wallet` can convert funds from a reserve to fresh 
coins
     {% endtrans %}
   </dd>
+<dt>{{ _("zombie coin") }}</dt>
+  <dd>
+    {% trans %}
+     a `coin` is a zombie coin if the coin was (1) used as the `dirty` coin
+     in `refreshing`, (2) the `denomination` of the `fresh` coins created 
during the
+     `refreshing` was subject to `revocation`, resulting in the `fresh` coin
+     from the refresh operation being subjected to `payback`; as a result,
+     the formerly `dirty` coin is eligible for
+     `refreshing`, even if the dirty coin's denomination is `expired` for
+     `deposit` operations (but not if it is expired past the legal
+     data retention requirement).
+    {% endtrans %}
+  </dd>
 </dt>
 </div>
 {% endblock body_content %}
diff --git a/images/buy.jpg b/images/buy.jpg
new file mode 100644
index 0000000..80d294d
Binary files /dev/null and b/images/buy.jpg differ
diff --git a/images/buy.medium.jpg b/images/buy.medium.jpg
new file mode 100644
index 0000000..84be648
Binary files /dev/null and b/images/buy.medium.jpg differ
diff --git a/images/gdpr.jpg b/images/gdpr.jpg
new file mode 100644
index 0000000..765dfea
Binary files /dev/null and b/images/gdpr.jpg differ
diff --git a/images/gdpr.medium.jpg b/images/gdpr.medium.jpg
new file mode 100644
index 0000000..665a18e
Binary files /dev/null and b/images/gdpr.medium.jpg differ
diff --git a/principles.html.j2 b/principles.html.j2
index 78a90ca..a482ee2 100644
--- a/principles.html.j2
+++ b/principles.html.j2
@@ -89,6 +89,7 @@ h2 {
   <div class="row">
     <div class="col-lg-12">
       <h2>5. Only disclose the minimal amount of information necessary</h2>
+      <img style="width:20vw;float:left;padding:15px" 
src="../images/gdpr.medium.png" alt="Privacy by design, privacy by default, 
General Data Protection Regulation (GDPR) compliant"></a>
       <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,
@@ -99,6 +100,7 @@ h2 {
   <div class="row">
     <div class="col-lg-12">
       <h2>6. Be usable</h2>
+      <img style="width:20vw;float:right;padding:15px" 
src="../images/buy.medium.jpg" alt="Buy with one click"></a>
       <p>
 Specifically it must be usable for non-expert customers. Usability also
 applies to the integration with merchants, and informs choices about the

-- 
To stop receiving notification emails like this one, please contact
address@hidden.