Re: [Taler] Taler Android UX

[Christian Grothoff]

On 4/13/20 7:58 PM, Torsten Grote wrote:
> On 2020-04-09 15:25, Christian Grothoff wrote:
>> That sounds a bit too much like a dark pattern for really strongly 
>> forcing people onto our pre-selected exchange.
> 
> Well, there is a balance to be struck between promoting competition in
> the exchange market and making the app easy to use.

Maybe ;-).

> For you the logical thing to do is of course to show exchange selection
> at least for the first withdrawal, but for the ordinary user who doesn't
> even know what an exchange is, this could very easily be the reason why
> why don't perform the withdrawal, stop using and uninstall the app.
> Since we won't integrate analytics into the wallet, we'll never now.

Well, I'd hope we'll do some usability studies eventually. ;-)

> My suggestion was merely meant to make things as easy as possible for a
> new user who is already overwhelmed by using a new application.

Sure, I get that.

>> Sure, having an audited/trusted exchange default pre-selected in
>> that dialog can make sense so that the user only has to click on
>> 'next'. But skipping it entirely and immediately going ToS without
>> even giving a hint that there could be another choice seems fishy.
> 
> What you *could* do is show an onboarding dialog already the *first*
> time the user withdraws and tell them what an exchange is (as this is
> apparently required knowledge) and that they can change it here.

I'm not in principle against adding a first-timer explainer at this
particular point, but Belen may differ ;-).

> But I would really recommend not forcing exchange selection upon the
> user. 

Even if all that is required is clicking "select"?
(The exchange list can totally have a pre-selected sane value to be
simply accepted as default.)

> Maybe Belen also has an opinion here?
>
>> However, the rounding loss 
>> is largely theoretical: if the exchange offers denominations that
>> are at or below the smallest unit you can wire-transfer (like 1
>> cent), the rounding loss will always be zero and can be
>> ignored/hidden. But an exchange could also only offer say 50 cent
>> coins as the smallest unit, and then it would become "substantial".
> 
> Ah good to know. So I am seeing the rounding loss all the time only
> because our test exchange offers few denominations.
> 
> Btw. is there a difference between a coin and a denominations?

A coin is an individual "token" that has an original value based on the
coin's denomination, as well as a remaining value (based on how the coin
has been used for spending/refunding/refreshing).  A coin is uniquely
identified by its Eddsa public key, and becomes valid when it is
(blind-)signed by an RSA *denomination* key.

A denomination key is an RSA public/private key pair.
All coins signed by the same denomination key have the
same original value (i.e. EUR:1). Denominations also come with a fee
structure (withdraw, deposit, refresh, refund) and expiration structure
(withdraw, deposit, legal) that applies to all coins of that
denomination. The fee and expiration structures MUST NOT change during
the lifetime of the denomination.

We _also_ (internally, sometimes) use the term "denomination type" for
all denominations that share the same original value and fee structure
(but differ in the specific RSA key and expiration structure).
Basically, an exchange configuration will specify the denomination
*types*, and then denomination (keys) with overlapping denomination
lifetimes will be created for that exchange.

Note that it is possible to have the same valuation (i.e. EUR:1), but
change the fee structure for that valuation. That would create a coin
with the same value, but different fees and thus different denominations
and different denomination types.

>> Refresh can be for change, but also when coins expire, or when 
>> transactions are aborted due to network failures. So not just for 
>> getting change, but _mostly_.
> 
> Good to know, so the coin expiration doesn't mean that they will be
> lost, but that I (or my wallet) need to refresh them before they expire?

Right, the wallet MUST do this automatically, unless it cannot because
it is offline for a long time before the expiration.

> Having to pay for network failures doesn't sound good btw.

Well, it's for a rather permanent type of network failure, where the
merchant never comes back. If the network fails and you simply re-play
the purchase, there is of course no loss in that case.

>> So an exchange operator COULD decide to 
>> only charge deposit fees to make the consumer never see any fees 
>> explicitly.
> 
> That sounds sensible.
> 
>> However, then malicious consumers could do (pointless) 
>> withdraw-refresh-refresh-refresh-refresh and basically try to 
>> "bankrupt" the exchange operator that way.
> 
> I guess it would need a lot of malicious consumers to achieve that and
> imagine that one could put other defenses against that in place.

Tricky, due to customer's anonymity you don't really have any good way
to do accounting, and no good way to tell legitimate from illegitimate
requests. And of course we cannot simply NOT answer requests either.

>> In summary: the costs are sometimes substantially different 
>> (bandwidth, computation and storage), and it is also conceivable
>> that an exchange or central bank may set fees for marketing or
>> policy reasons that do not even match the costs.
> 
> Thanks a lot for explaining!
> 
>> Wire fees are charged per wire transfer. The merchant(s) specify how
>>  often they want to be paid (hourly, daily, weekly, every 42h, 
>> whatever), and that's how often the aggregation wire fee will be 
>> charged.
> 
> So do these fees only affect merchants? Do we even need to show them in
> a consumer wallet?

Well, it's of course more difficult ;-). Merchants can specify that they
are willing to pay certain "reasonable" wire fees. Say 20 cents. If the
wire fees are at or below that value (or say 10 cents), customers won't
see them. But imagine an exchange charges 1 EUR for wire transfers. Then
the merchant will go and say: sorry, that's excessive, I don't like to
pay 1 EUR for the wire transfer. Dear customer, please pay a *share* of
the 80 cents that is above the 20 cents that I'm willing to cover. Here,
the merchant
additionally specifies an amortization factor (a factor of 40 means that
the 80 cents are to be amortized over 40 customers). Then, each customer
would have to contribute 2 cents in wire fees. But possibly not exactly
2 cents, if there is room from the deposit fees...

So very complicated, but ultimately there to protect the merchant
against the (largely theoretical) attack of an exchange charging
excessive wire fees.

>> Closing fees are ONLY charged to customers that create a reserve 
>> (wire money to the exchange) but then never withdraw the coins.
> 
> Interesting. Should we maybe have little info buttons next to the fee
> labels with these explanations?

Yes. Little info buttons, but then likely jumping to walls of text with
the explanations ;-(.
>> I suspect the WebExtensions wallet isn't even ToS-aware at all at 
>> this point. Also the exchange can't "enforce" this, because it 
>> doesn't get anything when the user accepts the ToS. The system
>> design says the exchange must offer it, and wallets MUST collect the 
>> 'acceptance' from the customer before proceeding.
> 
> Good to know. Thanks for explaining!

Sure.

-Christian

signature.asc
Description: OpenPGP digital signature