Re: Security concerns: OGHAM SPACE MARK

From: Philippe Verdy <>
Date: Mon, 20 Jul 2015 18:40:51 +0200

Bank transactions do not send in the same field amounts that contain
operations to compute. Also they limit the kind of digits they accept for
A change of sign is a different kind of transaction with different
responsabilities, so signs are prohibited, they are replaced by a separate
codification of the transaction type.

So the risk may only exist when presenting a signed number to a user and
asking him to accept the transaction.

There are simialr issues when amounts are using grouping separators and
ambiguously use the decimal separator with a precision counting as many
digits as there are digits in groups (for most locales, groups are made
with 3 digits, so prices always avoid using formats with 3 decimals and
most currencies have 0 or 2 decimals of precision). This could be a problem
in locales grouping digits by group of 2. If group separators are used to
show a price to a user in a UI, it is strongly suggested to avoid anything
else than a (narrow) space. If the document will be printed you may avoid
all separators and replace the decimal sepator by the currency symbol, or
use a modified typography to render the decimals (e.g. in superscript or
smaller font size).

But the most common confusion when presenting prices to users, is to not
clearly state if taxes and additional fees will be applied or have been
included, or will have to be paid after the purchase when receiving the
product (e.g. buying a product in Australia from Europe: you accept the
price in AUD, you know that there will be bank fees to process the change
operation, you pay the price to the seller, later your bank performs the
change operation and applies a new currency rate plus fees, and you have a
second line of payment in your bank account, then a week later you receive
the product but to get it you must first pay the import taxes and VAT to
the customs (via the postal or delivery service, plus sometimes a new fee
to the devlivery service that had to advance the custom taxes and acts as
an intermediate). The total price is much higher than that was advertized.
Some sellers (notably on the Internet) do not explain clearly that these
products will cost more and what to expect, even if they target customers
in other countries in their own language as if they had a local branch in
that country.

Banks are protected from these errors, but not customers.

2015-07-20 17:46 GMT+02:00 "Jörg Knappen" <>:

> I stumbled over a very strange snippet of javascript code, where an
> apparent
> minus sign is interpreted as a space here:
> Imagine such kind of behaviour in bank transactions ...
> --Jörg Knappen
Received on Mon Jul 20 2015 - 11:42:47 CDT

This archive was generated by hypermail 2.2.0 : Mon Jul 20 2015 - 11:42:48 CDT