Conference PaperPDF Available

Towards an Architecture for Pseudonymous E-Commerce Applying Privacy by Design to Online Shopping

Authors:

Abstract and Figures

In this paper we apply privacy by design in e-commerce. We outline the requirements of a privacy-aware online shopping platform that satisfies the principle of data minimization and we suggest several architectures for building such a platform. We then compare them according to four dimensions: privacy threats, transparency, usability and compatibility with existing business models. Based on the comparison, we aim to build the selected platform in the next step.
Content may be subject to copyright.
cbe doi:10.18420/sicherheit2018_01
H. Langweg, M. Meier, B.C. Witt, D. Reinhardt et al. (Hrsg.): Sicherheit 2018,
Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2018 1
Towards an Architecture for Pseudonymous E-Commerce
Applying Privacy by Design to Online Shopping
Sebastian Pape
1
, Daniel Tasche
2
, Iulia Bastys
13
, Akos Grosz
1
, Jörg Lässig
2
, Kai Rannenberg
1
Abstract: In this paper we apply privacy by design in e-commerce. We outline the requirements of
a privacy-aware online shopping platform that satisfies the principle of data minimization and we
suggest several architectures for building such a platform. We then compare them according to four
dimensions: privacy threats, transparency, usability and compatibility with existing business models.
Based on the comparison, we aim to build the selected platform in the next step.
Keywords: privacy by design; pseudonymity; data minimisation; online shopping; e-commerce
1 Introduction
E-commerce is playing an increasingly important role for operators of shopping platforms
and their customers. The estimated revenue for the German e-commerce market in 2017
amounts to
e
55 billion, while recent statistics forecast 58 million users and a market volume
of
e
78 billion in 2021 [
St16
]. Shopping platform operators are collecting customer data, as
personalized offers and recommendations lead to higher revenues. Despite an increase in
public’s awareness on the issue of data protection and growing concerns about the usage of
their data, currently e-commerce users have no alternative to disclosing personal data and
revealing shopping behavior [
Jo16
]. A recent study reveals that 50% of online services
send full information about the users’ baskets to Paypal (if PayPal was selected as payment
method), which in turn forwards the information, who purchased what and where, to a
third-party specialized in data aggregation [
Pr16
]. At least in Europe, these issues begin
to be addressed through several regulations and directives. The General Data Protection
Regulation (GDPR), planned to be applied in May 2018 in the EU countries, requires data
protection by design and by default: “The controller shall implement appropriate technical
and organisational measures, such as pseudonymisation, which are designed to implement
data-protection principles, such as data minimisation [. . . ] in order to [. . . ] protect the
rights of data subjects” [
Re16
]. Therefore, we aim to improve the processes in e-commerce
in respect to the data protection principles pseudonymisation and data minimisation.
The e-shopping platform could track the user’s online activity through IP address, third
party web-tracking [
MM12
], browser fingerprinting [
Ec10
], canvas fingerprinting [
Ac14
],
1Goethe University, Chair of Mobile Business & Multilateral Security , firstname.lastname@m-chair.de
2University of Applied Sciences Zittau/Görlitz, {d.tasche,j.laessig}@hszg.de
3Chalmers University of Technology, Gothenburg, Swedenbastys@chalmers.se
2 Sebastian Pape, Daniel Tasche, Iulia Bastys, Akos Grosz, Jörg Lässig, Kai Rannenberg
or evercookies [
Ac14
]. We do not investigate them in this paper, as previous work has
already suggested different countermeasures [DMS04, PCM13, Ba13, LRB16].
Following these requirements, we make a step forward in preserving customer’s privacy
in online shopping, by describing an e-commerce platform that satisfies the principles of
data minimization and pseudonymization (Section 3). We then suggest several architectures
for building such a platform (Section 4) and compare them based on the privacy threat
analysis methodology LINDDUN [
WJ15
], but also with respect to usability, transparency
and compatibility to existing business models (Section 5).
2 Related Work
Growing concern about user traceability when making electronic payments propelled
efforts in the area of privacy-preserving e-commerce. Initial work mainly concentrates on
anonymous electronic payment methods through cryptographic mechanisms such as blind
signatures [
Ch83
,
Ch85
,
CFN90
]. Aiello et al. [
AIR01
] describe a cryptographic protocol
for anonymous shopping of digital goods based on priced oblivious-transfer and private
information retrieval [
Ch95
]. In their setting, the customer makes an initial deposit which
is later used to retrieve the desired items. Besides the initial deposit and the interaction
with the platform, the online shop learns nothing else. In particular, it does not learn what
or how much is purchased, nor when the buyer runs out of credit. While interesting, this
approach is not feasible for deployment, as the customer would have to download the
entire encrypted database. More recent work brings several improvements to the underlying
protocols [
RR01
,
CDN09
,
CDN10
,
HOG11
], but they still only focus on digital goods,
while our interest is in achieving customer privacy when purchasing physical goods.
A first step towards anonymous and pseudonymous e-commerce addresses the problem of
purchasing goods with digital assets in a privacy-friendly manner [
Sa14
,
GGM16
,
Go17
].
Goldfeder et al. [
Go17
] introduce a series of escrow protocols to use when buying physical
products online and paying with Bitcoin. While some of these protocols satisfy strong
security properties, the buyer is still required to provide the seller with an address for
delivering the goods, breaking to some extent buyer anonymity. Even though the seller does
not learn the exact address of the buyer (as the address of a friend or of a post office can be
provided instead), the seller learns the location where the product has to be dispatched.
3 System Overview
First, we give a brief overview of the involved parties and the relevant data.
Involved parties. The system consists of the following five parties:
The User is a (registered) customer interested in purchasing goods online from Shop.
Shop is the party that sells the (physical) goods through a platform accessible via Internet.
The payment provider Pay collects the payment from User and transfers it to Shop.
The logistics provider Shipping delivers the purchased goods from Shop to User.
ID-Provider is a third-party responsible for managing the user’s profile.
Towards an Architecture for Pseudonymous E-Commerce 3
In order to prevent the Shop from collecting customers’ private data and creating dossiers
that reveal shopping behavior, we introduce a trusted third party in the system, ID-Provider,
that increases the usability and the privacy of the architecture. It is responsible with
managing the User’s real and generated identities. A customer registers with ID-Provider
with the real identity, and receives from ID-Provider a new generated identity, a pseudonym
for logging in with Shop. Basically it acts as an authentication provider with pseudonymous
identities, single sign on system for online shops and shopping process management system
that connects the stakeholder for one shopping procedure. ID-Provider increases the usability
for the User as well as the privacy of the overall shopping process. We require the user to
provide the real identity in order to prevent system abuse. The pseudonym can be lifted in
case of proved misbehavior. User can use the same pseudonym on multiple online platforms,
or can create several pseudonyms, one for every platform, or even one for every purchase on
the same platform.
User data. For a successful purchase, the user needs to provide the following information:
Product data refers to the products selected by User for purchase.
Total value refers to the purchasing price of the selected products plus additional payment
and shipping charges to User.
Payment data represents the data needed for a successful payment. Depending on the
selected payment method this can be name, full address, bank account or credit card
number, or even an anonymous payment method as sketched in Section 2. In general,
banks and financial service providers require more information about a payment than just
the bank account and the total value.
Delivery data represents the information the delivery service Shipping needs for a
successful delivery to User. In most cases, this is the name and address of User. However,
other options are container freight stations and poste restante delivery, which do not
necessarily require the same information.
The identifiability of the User and the linkability of purchases by Pay and Shipping depends
on the chosen payment and delivery methods and applies to all architecture scenarios we
will further discuss (Section 4). We assume that none of the parties collude, as collusion
between Shop and any of ID-Provider,Pay or Shipping is sufficient for User profiling.
System requirements
A representation of a current e-shopping process is depicted in Figure 1. In general, Shop
collects the User’s data required for payment processing and package delivery. While it
is possible to use a payment provider, such as Paypal [
Pa17
], and not provide Shop with
any payment information, in most cases, the payment provider offers Shop a possibility to
manage the payments and allows it to access the user’s payment data.
As already discussed in Section 1, we ignore other customer tracking possibilities and
focus our analysis on the data provided by User to the other parties. If a privacy-friendly
online shopping platform would exist, the users could try to protect themselves via technical
measures or legislation could protect the users by banning tracking without their consent.
4 Sebastian Pape, Daniel Tasche, Iulia Bastys, Akos Grosz, Jörg Lässig, Kai Rannenberg
Fig. 1: Traditional Shopping Process in Business Process Modeling Notation [Ob11]
Since the login process will not differ much for the proposed architectures, the data in
focus are product data, the value of the products, payment data and shipping data. When
designing the pseudonymous e-commerce architecture, we aim for the principle of minimum
disclosure under the constraints that the usability of the system should be comparable to
the current systems in practice and that the process should be as transparent as possible
to the user. Additionally, as discussed in Section 1, to promote a widespread use of our
architecture, the shop providers business model should be respected. To chose our basic
architecture, we consider the following dimensions for requirements and comparison:
Privacy. Shop should learn only the user’s activity on the platform, i.e. the purchased
products and their total value. The vendor does not learn payment or shipping data. Pay
should learn nothing except for the amount to be payed by the user to the vendor and
the payment data from the user. More specifically, the payment service does not learn
the products the user purchased, but only their total value.Shipping should learn only the
shipping data, but not the content (purchased products) of the package(s) to be delivered.
For the privacy analysis we apply LINDDUN, a privacy threat analysis methodology [
De11
,
WJ15
] which supports analysts in eliciting privacy requirements – similar to the security
threat modeling framework STRIDE [
Sh14
]. Since we have a manageable number of
entities in the context of our architecture scenarios, we don’t run into the risk of threat
explosion and can use the LINDDUN privacy analysis framework to systematically account
for privacy specific threats. It is based on the graphical representation of the system’s
abstract representation by a data flow diagram (DFD) and the subsequent mapping of the
framework’s six high-level threats to each DFD element. Therefore, we model the process
from checkout via payment to the delivery procedure of the products in a DFD. For each
entity, we investigate the threats and map them to the elements in the DFD. In the following,
we briefly discuss the privacy threats we are going to analyze.
Towards an Architecture for Pseudonymous E-Commerce 5
Since the user should be able to shop pseudonymously, we consider the identifiability of the
user (e.g. by payment or delivery data) as the main threat. In that context it is also important
which parties hold which data. Depending on the party, information on purchased products,
the value of the purchased products,payment data and delivery data is necessary for
providing the service. As discussed, in particular the last data is suitable to revoke the User’s
pseudonymity. Therefore, we consider the disclosure of this data as another threat. Even if
the User is not directly identifiable, linkability of two (or more) purchases of a user could
reveal sensitive information leading to identification or at least the building of a meaningful
profile. We further investigate which of the parties is able to detect login,purchase,payment
and delivery events which could also be used to profile the User. Detectablility of one of the
events does not mean the corresponding data is revealed, but in most cases the involved party
can be identified (e.g. User did payment with Pay but neither amount nor payment data can
be seen). Unawareness and non-compliance are out of the scope, as they are more related to
the user interface and the entities’ policies which are independent of our system architecture
process. We are also not regarding non-repudiation for this paper since we consider it more
related to contracting and legal aspects than to the architecture of our shopping platform.
Usability. Many aspects concerning the usability will not depend on the system’s archi-
tecture, but on proper user interfaces allowing the user to manage his data in a easy and
transparent way. However, in order to allow the user to easily use the system from different
clients (e.g. computer, tablet, smart phone, . . . ), the user should not store information
such as a cryptographic key. Additionally, the speed of the system should be comparable
to existing systems, thus complex cryptographic protocols which delay the process too
much can not be used. As a consequence, certain privacy enhancing technologies such
as attribute based credentials [
SKR12
] do not come into play, because they make use of
cryptographic keys, which the user would have to store on a smartcard. We compare the
different architectures based on the effort the user needs to take for.
Transparency. A natural data flow which allows the user to easily understand which data
is provided to whom for which purpose contributes to a transparent system. Since the user
interface is out of the scope of this work, transparency of the different architectures will
depend only on data flows.
Compatibility to existing business models. Analogous to attribute based creden-
tials [
Sa15
], we assume that when preserving the online shop providers’ business models, a
broad distribution of our platform can be more easily achieved. Certainly, this does not mean
that the shop providers should be allowed to collect all data they want. But allowing them to
keep profiles for pseudonyms and sending e.g. newsletters (via ID-Provider) to users who
gave consent would certainly be helpful for the adoption of pseudonymous e-commerce.
4 Architecture Variants
In this section we describe the three architectures, we considered for implementation.
For an easier comparison, we also analyzed the current shopping process. The standard
architecture allows the Shop to gather a big volume of data about its users. In order to
6 Sebastian Pape, Daniel Tasche, Iulia Bastys, Akos Grosz, Jörg Lässig, Kai Rannenberg
avoid this, we suggest three architectures, two of them make use of public-key infrastructure
(see Sections 4.2 and 4.3) and a third one without encryption but self data hosting (see
Section 4.4). All scenarios involve an ID-Provider for managing the user’s profile.
For the following analysis, we abstract from the login process and from confirmations as far
as possible. Although other variants exists, we assume the User selects the products, pays
and gets them delivered afterwards. Special care has to taken that Pay and Shipping providers
do not pass the User’s data to the Shop, e.g. by offering an administrative user interface,
where payment data is listed or sending tracking information of the delivered packages. Each
architecture’s description follows the following template: We describe the process of every
scenario and briefly discuss advantages and disadvantages. The corresponding data flow
from selecting the products, checkout, payment and delivery process is depicted in Fig. 2.
The analyzed privacy threats described in Section 3 are listed in Tab. 1. For each privacy
threat (from Sect. 3) we denote the scenarios where it exists. For some of the analyzed
threats, it depends on the users. If users don’t want the shop to link their payments, they
can use a new pseudonym for each purchase. For payment and shipping it depends on the
kind of service the user chooses. Clearly, it makes a difference whether they are paying with
anonymous electronic payment or by providing their credit card data. For shipping they
could ask for home delivery or use a container freight station. We denote these threats in
brackets in Tab. 1.
4.1 A: Current Shopping Process
The standard shopping process is depicted in BPMN in Figure 1 and has already been
described. Figure 2a shows the data flow diagram. The Shop collects all information about
the user, and thus can identify the user and can link all shopping activities. The identifiability
of the User and the linkability of purchases by Pay and Shipping depends on the chosen
payment or delivery method. The highest privacy threat for the User is the Shop because of
the possibility to disclose the User’s payment and delivery data as well as profiling the User.
4.2 B: Shop Stores Encrypted Data
In this scenario, the user reveals only his real identity (name) to ID-Provider when registering.
The ID-Provider acts as single-sign-on login service, to allow the user to log in several Shops
without further registration. Additionally, ID-Provider provides public keys for payment and
shipping provider. Shipping and payment data is stored encrypted on the Shops server. The
data flow of this scenario is depicted in Figure 2b.
The User initiates the process by select products. The Shop gets the product data and stores
it. In the checkout process, the User decides on a payment and shipping provider. The user
gets the public keys for any provider he wants to use, encrypts the payment respectively
delivery data and sends it to the Shop. Subsequently, the Shop initiates the payment process
by forwarding the encrypted banking details along with the amount to be payed to Pay.
After successfully decrypting the payment data and completing the payment transaction,
Towards an Architecture for Pseudonymous E-Commerce 7
A. User
1.select
products
B. Shop
3.payment
C. Pay
4.delivery
D. Shipping
2.checkout
I. product data
II.delivery data II. payment data
(a) Current architecture A
A. User
1.select
products
I. product data
B. Shop
4.payment
C. Pay
6.delivery
D. Shipping
E. ID-Provider
3.decrypt
payment
data
IV. payment data
5.decrypt
delivery
data
V. delivery data
2.checkout
III. delivery data II. payment data
(b) Architecture B
A. User
1.select
products
I. product data
B. Shop
4.payment
C. Pay
6.delivery
D. Shipping
E. ID-Provider
3.decrypt
payment
data
IV. payment data
5.decrypt
delivery
data
V. delivery data
2.checkout
III.delivery data II. payment data
(c) Architecture C
A. User
1.select
products I. product data
B. Shop
3.payment C. Pay
4.deliveryD. Shipping
E. ID-Provider
2.checkout
II.payment dataIII. delivery data
(d) Architecture D
Fig. 2: Data flow diagram
Pay sends a confirmation of payment to Shop. Upon confirmation, Shop starts the delivery
process and sends the package labeled with the Users encrypted address to Shipping. After
successfully decrypting the delivery data, Shipping proceeds with delivering the package
and provides Shop with a confirmation of delivery. In this architecture Shop is not able to
identify the user and can not disclose payment and delivery data. Since there is a possibility
to use one pseudonym for each shopping process, the shop is also not able to link the
purchases of an user unless the User allows it. The ID-Provider only knows the real identity
of the user, but can not disclose payment or delivery information and also does not learn
anything about the purchase process. However, the ID-Provider is able to detect the login
process. The information distribution of Pay and Shipping are not affected. Therefore, the
same conditions apply as for the standard architecture.
Advantages and disadvantages.
+ID-Provider does not learn methods User uses for payment.
+The Pay and Shipping services do not learn the virtual identity of User.
The ID-Provider is able to detect logins in the store.
Key management: It is difficult for the User to encrypt the payment and delivery data.
8 Sebastian Pape, Daniel Tasche, Iulia Bastys, Akos Grosz, Jörg Lässig, Kai Rannenberg
Tab. 1: Privacy Threats Mapped to Architecture Variants from Sect. 4
Threat
Entity Shop Pay Ship Identity Provider
Identifiability A (ABCD)2(ABCD)3BCD
Disclosure shopping cart A B C D
Disclosure total value A B C D A B C D
Disclosure payment data A A B C D
Disclosure delivery data A A B C D
Linkability purchase A(BCD)1(ABCD)2(ABCD)3C
Detectablility login A B C D B C D
Detectablility purchase A B C D A B C D A B C D C
Detectablility payment A B C D A B C D C
Detectablility delivery A B C D A B C D C
1Depends on the user’s choice. 2Depends on user’s payment 3Depends on user’s shipping
Either this is done in the browser (e.g. with Javascript) or by an App, but the user has to
trust the party providing the code.
4.3 C: ID-Provider Stores Encrypted Data
This architecture is similar to architecture B. The only change is that the (encrypted)
payment and delivery data is stored at the ID-Provider. As a consequence, instead of directly
delivering the data to Pay and Shipping, the Shop refers them to the ID-Provider where they
need to authenticate and ask for the User’s data. Therefore, the data flow itself is very similar
to the one of architecture B (see 4.2) as depicted in Figure 2c. In this scenario, ID-Provider
controls the shopping process. It knows the identity of the user and has information about
where the user shops but does neither know the payment or delivery data since they are
encrypted nor any details of the shopping content. Shop does not know the real identity of
the user nor the payment or delivery details. The data distribution or possible disclosure
from Pay and Shipping are unchanged.
Advantages and disadvantages.
+ID-Provider does not learn the payment or delivery data of the User.
If the User does not perform the encryption himself, then he has to trust ID-Provider to
provide him with the correct public keys of the payment and logistics services.
ID-Provider learns the Shop where the User makes his purchases.
One more point of failure: ID-Provider is involved in multiple transactions.
4.4 D: User Gets Redirected to 3rd Parties
In this scenario, ID-Provider solely acts as a single-sign-on service and certification authority.
All the information required for each of the steps of the pseudonymised shopping process
is stored by the User. He initiates the process by selecting the products. The Shop gets
Towards an Architecture for Pseudonymous E-Commerce 9
the product data and stores it. In the checkout process, the User decides on a payment and
shipping provider. Subsequently, the Shop redirects the User for the payment process and
the User delivers his payment data directly to Pay.Pay sends a confirmation of payment
back to Shop. Upon confirmation, the Shop redirects the User for the delivery process and
the User delivers his delivery data directly to Shipping.Shipping receives the package from
Shop with an identifier to link it to the address and proceeds with delivering the package
and provides Shop with a confirmation of delivery. Figure 2d shows the data flow. Since
the User has full control about his profile data, Shop does neither know the User’s identity
nor the payment or delivery data. The information distribution of Pay and Shipping are not
affected. Therefore, the same conditions apply as for the standard scenario.
Advantages and disadvantages.
+The User is fully in control of his personal information.
+Only necessary data is provided to each party.
+Only communication needs to be encrypted.
Additional tools have to be provided for Users to host their information.
A lot of transactional load is put on the User. In particular, the User has to check that he is
providing the information to the correct party, e.g. by checking cryptographic certificates.
The payment process has to work instantly, otherwise additional communication is needed
to synchronise payment with shipping processes.
5 Architecture comparison
In this section we compare the previously described architectures on the four dimensions
described in Section 3: privacy, usability, transparency, and compatibility.
Privacy. Every involved party should learn only information about the activity belonging
to its area of responsibility. In the standard scenario the Shop holds every information about
the User’s identity. As described in Sect. 4, all proposed architectures consider the principle
of minimum disclosure. They differ only in the information provided to the ID-Provider.
In each scenario the User has the possibility to create several shopping pseudonyms. If
he uses one for every shopping process, the store could not link several purchases. This
applies to all architectures. The linkability of the purchase and identifiablity of the User
on Pays and Shipping’s side depends on the payment and shipping methods and is not an
architectural aspect. ID-Provider could link the purchases in Scenario C because ID-Provider
manages the checkout process. In the other scenarios ID-Provider acts as a real identity
provider and just manages the login process. Therefore, the detectability of a purchase, a
payment and a delivery applies to Scenario C, but not to Scenario B and Scenario D.
Usability. Every architecture has the registration at ID-Provider and the managing of
pseudonyms in common. That means compared to the standard scenario one has to maintain
data not on Shop’s side but on ID-Providers side. As a compensation for managing the
profiles, the User would not need to register at any Shop anymore.
Architecture B and C come with additional effort since the Users have to encrypt their
data. In particular, in architecture B, Users face the problem that they might not want to
10 Sebastian Pape, Daniel Tasche, Iulia Bastys, Akos Grosz, Jörg Lässig, Kai Rannenberg
trust the Shop’s App or Javascript-code making it difficult to encrypt. On the other hand in
architecture C, the user has to register at the ID-Provider anyway and it seems reasonable
to rely, e.g. on an App or Javascript-code on a web page. Architecture D asks the user to
provide his payment and delivery data for each purchase again. This could be mitigated by
making use of the The PaymentRequest API [
Ba17
]. However, since the recommendation is
quite new, it will take some time until this has been adapted. For the authentication and
single sign-on the X.509 standard could be used but needs some extensions to provide
special user information. Therefore, Dash et al. [
Da17
] show an architecture proposal for an
identity management architecture as a service. Additionally, since the Shop redirects the
User to Pay and Shipping, the User has to check for each of the providers that Shop was
directing her to the correct entity and not to a forged one to get the User’s data.
Transparency. Despite sharing payment and delivery data directly with the Shop the
standard architecture is quite transparent, because the User should be aware of sharing
this data with the Shop. Although, the user might not be aware that this information might
be shared with or is accessible by 3rd party service providers (e.g. webhoster, payment
provider). The same holds for architecture D, where the Users need to provide their data to
each entity directly. Architectures B and C, lack a bit of transparency, because it is harder
for the user to assess how and from whom the encrypted data will be processed. However,
it’s up to the respective entity to inform the User in a supporting way.
Compatibility. The basic business processes of the involved parties are not broken by
this architectures. However, by not disclosing the Users identity and therefore contact
information to Shop,Shop needs to rely on ID-Provider to forward e.g. newsletters or special
offers to the User. In case of misuse or disputes, ID-Provider is needed to reveal the User’s
identity. Pay and Shipping need to adjust their processes, in order to not reveal the Users
data to Shop. However, there is no large difference here between architectures B, C, and D.
Final Architecture. Table 2 shows an overview of all attributes concerning the four
analyzed architectures. While architectures B and D are favorable in respect to privacy and
transparency, our focus when defining the requirements was to put emphasis on usability.
Improved privacy should not complicate the shopping process for the user. The slight
disadvantage in transparency from architecture C to D does not outweigh the disadvantage of
architecture D that Users need to provide their data for each purchase again or alternatively
have additional accounts (and logins) at payment and shipping providers. Therefore, we
believe architecture C to be the most feasible option.
Privacy Usability Transparency Compatibility
A - o + ++
B ++ + o +
C + ++ o +
D ++ o + +
Tab. 2: Comparison of the several architectures.
Towards an Architecture for Pseudonymous E-Commerce 11
6 Conclusion and Future Work
In the context of pseudonymous online shopping, we presented and assessed three different
architectures and compared them to the existing architecture. So far, the proof of concept
shows, that a pseudonymous e-commerce process can be set up in a usable and privacy-
friendly way. The User data is no longer on Shop’s side but split to several parties that are
involved in the shopping process.
We plan to add more processes to the shopping system such as returning goods and writing
invoices. Around this, several legal and technical issues need to be resolved, e.g. how the
Shop can issue an invoice to a pseudonym. Even though the PaymentRequest API only
supports non-normative encryption of data fields and might also expose payments methods
(cf. [
Ba17
, Section 19.2]), it might be helpful in storing payment and delivery data in the
User’s computer to avoid creating a centralized database.
Future work includes the implementation of certain restrictions for Users. For example,
only Users above certain age or in certain geographical regions can access certain products.
The next steps also contain the detailed description of the used protocol.
7 Acknowledgments
The SIOC project [
SI
] is supported by the German Federal Ministry of Education and
Research’s (BMBF) program "Datenschutz: selbstbestimmt in der digitalen Welt".
References
[Ac14]
Acar, Gunes; Eubank, Christian; Englehardt, Steven; Juarez, Marc; Narayanan, Arvind;
Diaz, Claudia: The web never forgets: Persistent tracking mechanisms in the wild. In:
CCS. 2014.
[AIR01]
Aiello, William; Ishai, Yuval; Reingold, Omer: Priced Oblivious Transfer: How to Sell
Digital Goods. In: EUROCRYPT. 2001.
[Ba13]
Bau, Jason; Mayer, Jonathan; Paskov, Hristo; Mitchell, John C: A promising direction for
web tracking countermeasures. W2SP, 2013.
[Ba17]
Bateman, Adrian; Koch, Zach; McElmurry, Roy; Denicola, Domenic; Cáceres, Marcos: ,
Payment Request API. https://www.w3.org/TR/2017/CR-payment- request-20170921/,
2017. W3C Candidate Recommendation 21 September 2017.
[CDN09]
Camenisch, Jan; Dubovitskaya, Maria; Neven, Gregory: Oblivious transfer with access
control. In: CCS. 2009.
[CDN10]
Camenisch, Jan; Dubovitskaya, Maria; Neven, Gregory: Unlinkable priced oblivious
transfer with rechargeable wallets. In: FC. 2010.
[CFN90]
Chaum, David; Fiat, Amos; Naor, Moni: Untraceable electronic cash. In: CRYPTO. 1990.
[Ch83] Chaum, David: Blind signatures for untraceable payments. In: CRYPTO. 1983.
[Ch85]
Chaum, David: Security without identification: Transaction systems to make big brother
obsolete. CACM, 1985.
[Ch95]
Chor, Benny; Goldreich, Oded; Kushilevitz, Eyal; Sudan, Madhu: Private information
retrieval. In: FOCS. 1995.
[Da17]
Dash, Pritam; Rabensteiner, Christof; Hörandner, Felix; Roth, Simon: Towards Privacy-
Preserving and User-Centric Identity Management as a Service. In (Fritsch, Lothar;
12 Sebastian Pape, Daniel Tasche, Iulia Bastys, Akos Grosz, Jörg Lässig, Kai Rannenberg
Roßnagel, Heiko; Hühnlein, Detlef, eds): Open Identity Summit 2017. Gesellschaft für
Informatik, Bonn, pp. 105–116, 2017.
[De11]
Deng, Mina; Wuyts, Kim; Scandariato, Riccardo; Preneel, Bart; Joosen, Wouter: A
privacy threat analysis framework: supporting the elicitation and fulfillment of privacy
requirements. Requirements Engineering, 2011.
[DMS04]
Dingledine, Roger; Mathewson, Nick; Syverson, Paul: Tor: The second-generation onion
router. Technical report, Naval Research Lab Washington DC, 2004.
[Ec10] Eckersley, Peter: How unique is your web browser? In: PETS. 2010.
[GGM16]
Garman, Christina; Green, Matthew; Miers, Ian: Accountable privacy for decentralized
anonymous payments. In: FC. 2016.
[Go17]
Goldfeder, Steven; Bonneau, Joseph; Gennaro, Rosario; Narayanan, Arvind: Escrow
protocols for cryptocurrencies: How to buy physical goods using Bitcoin. 2017.
[HOG11]
Henry, Ryan; Olumofin, Femi; Goldberg, Ian: Practical PIR for electronic commerce. In:
CCS. 2011.
[Jo16]
Jourova, Vera: , How does the data protection reform strengthen citiziens’
rights? http://ec.europa.eu/justice/data-protection/document/review2012/
factsheets/factsheet_dp_reform_citizens_rights_2016_en.pdf, 2016.
[LRB16]
Laperdrix, Pierre; Rudametkin, Walter; Baudry, Benoit: Beauty and the beast: Diverting
modern web browsers to build unique browser fingerprints. In: IEEE S&P. 2016.
[MM12]
Mayer, Jonathan R; Mitchell, John C: Third-party web tracking: Policy and technology.
In: IEEE S&P. pp. 413–427, 2012.
[Ob11] Object Management Group: , Notation (BPMN) version 2.0. OMG Specification, 2011.
[Pa17] Paypal: , Paypal Website. https://www.paypal.com, 2017.
[PCM13]
Perry, Mike; Clark, Erinn; Murdoch, Steven: The design and implementation of the
Tor Browser. Technical report, The Tor Project, 2013. https://www.torproject.org/
projects/torbrowser/design/.
[Pr16]
Preibusch, Sören; Peetz, Thomas; Acar, Gunes; Berendt, Bettina: Shopping for privacy:
Purchase details leaked to PayPal. Electronic Commerce Research and Applications, 2016.
[Re16]
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April
2016 on the protection of natural persons with regard to the processing of personal data
and on the free movement of such data, and repealing Directive 95/46/EC (General Data
Protection Regulation) (Text with EEA relevance). Official Journal of the European Union,
L 119/1, http://data.europa.eu/eli/reg/2016/679/oj, 2016.
[RR01]
Ray, Indrakshi; Ray, Indrajit: An Anomymous Fair Exchange E-commerce Protocol. In:
IPDPS. 2001.
[Sa14]
Sasson, Eli Ben; Chiesa, Alessandro; Garman, Christina; Green, Matthew; Miers, Ian;
Tromer, Eran; Virza, Madars: Zerocash: Decentralized anonymous payments from bitcoin.
In: IEEE S&P. 2014.
[Sa15]
Sabouri, Ahmad: Understanding the Determinants of Privacy-ABC Technologies Adoption
by Service Providers. In: Open and Big Data Management and Innovation : 14th IFIP WG
6.11 Conference on e-Business, e-Services, and e-Society, I3E 2015. 2015.
[Sh14] Shostack, Adam: Threat modeling: Designing for security. 2014.
[SI] SIOC project website. https://sioc.eu/.
[SKR12]
Sabouri, Ahmad; Krontiris, Ioannis; Rannenberg, Kai: Attribute-Based Credentials for
Trust (ABC4Trust). In: TrustBus. 2012.
[St16]
Statista: , E-Commerce in Deutschland. https://de.statista.com/outlook/243/137/
ecommerce/deutschland/, 2016.
[WJ15] Wuyts, Kim; Joosen, Wouter: LINDDUN privacy threat modeling: a tutorial. 2015.
All websites have been last accessed on Dec. 11th, 2017.
... For that purpose, we suggested four different architectures for building such a platform as shown in Fig. 4.5. The intend was to minimize data across all parties [157], in particular the online-shop does not need to learn the identity of the user, a payment provider, and delivery service only need to learn payment or delivery information respectively, but both of them do not need to know details about the purchase. This way, the user could shop pseudonymously, but none of the involved parties learns who bought what. ...
... Data Flow Diagram for Different Architectures in E-Commerce[157] ...
... 5: Privacy Threats Mapped to Architecture Variants in E-Commerce[157] ...
Thesis
Full-text available
In order to address security and privacy problems in practice, it is very important to have a solid elicitation of requirements, before trying to address the problem. In this thesis, specific challenges of the areas of social engineering, security management and privacy enhancing technologies are analyzed: Social Engineering: An overview of existing tools usable for social engineering is provided and defenses against social engineering are analyzed. Serious games are proposed as a more pleasant way to raise employees’ awareness and to train them. Security Management: Specific requirements for small and medium sized energy providers are analyzed and a set of tools to support them in assessing security risks and improving their security is proposed. Larger enterprises are supported by a method to collect security key performance indicators for different subsidiaries and with a risk assessment method for apps on mobile devices. Furthermore, a method to select a secure cloud provider – the currently most popular form of outsourcing – is provided. Privacy Enhancing Technologies: Relevant factors for the users’ adoption of privacy enhancing technologies are identified and economic incentives and hindrances for companies are discussed. Privacy by design is applied to integrate privacy into the use cases e-commerce and internet of things.
... On the one hand, there are rules of the country of origin and, on the other hand, there is the Electronic Commerce Directive given by the EU. Pape et al. (2018) outlined the requirements of a privacy-aware online shopping platform and suggested several architectures for building such a platform. They compared them according to four dimensions as follows: privacy threats, transparency, usability and compatibility with existing business models. ...
Article
Purpose This paper aims to consider the question of changes brought to consumers’ trust and security issues by the implementation of the General Data Protection Regulation (GDPR) in electronic commerce. Design/methodology/approach Online shopping policies in Poland and Ukraine are compared from the perspective of four factors as follows: application of terms of service and privacy policy, usage of online payment systems, presence in price comparison engines and grade of secure sockets layer security certificates. Comparison is conducted within the framework of three research questions (complemented by eight hypotheses) set to reveal whether: policies of personal data protection and server security for online stores in both countries are the same; all online stores in both countries obey the existing e-commerce rules; e-commerce policies in the two countries differ significantly. The sample for analysis contains 40 Polish and 40 Ukrainian online stores, representing four industries, namely, electronics, entertainment, fashion and goods for children. Findings The research allowed to reveal major differences in the privacy policy of the two countries, caused, mainly, by the absence of GDPR in Ukraine. It also disclosed much stronger cooperation of online stores and price comparison engines in Poland compared to Ukraine. At the same time, research results allow to state that server security in both countries is on the same rather high level and that online stores use transparent and safe methods of online payment. Research limitations/implications This research opens a way to other, expanded observations which will include more countries and larger scopes of data. Its main limitation is that GDPR influence is only studied in two countries, not in all countries where it is implemented. Originality/value This research contributes from security and trust perspectives by analyzing the situation in two countries as follows: the EU member (Poland) and a non-EU country (Ukraine). The value of exploring the situation of Ukrainian e-commerce consists of understanding how online stores function without implementing the GDPR. Observation of shopbots application allows drawing an important conclusion of the necessity for online stores to cooperate with such services. It was also revealed that consumers’ trust in both countries depends a lot on the payment methods applied by an online store and on the ease of use of these methods.
Conference Paper
Decentralized ledger-based currencies such as Bitcoin provide a means to construct payment systems without requiring a trusted bank. Removing this trust assumption comes at the significant cost of transaction privacy. A number of academic works have sought to improve the privacy offered by ledger-based currencies using anonymous electronic cash (e-cash) techniques. Unfortunately, this strong degree of privacy creates new regulatory concerns, since the new private transactions cannot be subject to the same controls used to prevent individuals from conducting illegal transactions such as money laundering. We propose an initial approach to addressing this issue by adding privacy preserving policy-enforcement mechanisms that guarantee regulatory compliance, allow selective user tracing, and admit tracing of tainted coins (e.g., ransom payments). To accomplish this new functionality we also provide improved definitions for Zerocash and, of independent interest, an efficient construction for simulation sound zk-SNARKs.
Conference Paper
As using online services penetrates deeper in our everyday life, lots of trust-sensitive transactions are carried out electronically. In this regard, a big challenge is to deal with proper user authentication and access control without threatening the users’ privacy. However, commonly used strong authentication schemes fail to address important privacy requirements. In this paper, we focus on an emerging type of digital certificates, known as Privacy-preserving Attribute-based Credentials (Privacy-ABCs), which allow privacy and security go hand-in-hand. So far, there has been no systematic study on the potential factors that have influence on the adoption of Privacy-ABCs by service providers. Thus, we developed a conceptual model of the relevant factors based on well-established theories and our practical experience with trialing Privacy-ABCs, and evaluated the model through expert surveys.
Conference Paper
The rapid growth of communication infrastructures and enterprise software solutions has caused electronic services to penetrate into our everyday life. So it is not far from reality that many personal and trust-sensitive transactions happen online. In this regard, one of the biggest challenges to deal with will be proper user authentication and access control, as strong authentication and authorization techniques used nowadays are double-edged swords: while they can protect service providers by offering a satisfactory level of resilience against unauthorized accesses, most of these technologies have the drawback of threatening the clients’ privacy.
Article
We present the first large-scale studies of three advanced web tracking mechanisms - canvas fingerprinting, evercookies and use of "cookie syncing" in conjunction with evercookies. Canvas fingerprinting, a recently developed form of browser fingerprinting, has not previously been reported in the wild; our results show that over 5% of the top 100,000 websites employ it. We then present the first automated study of evercookies and respawning and the discovery of a new evercookie vector, IndexedDB. Turning to cookie syncing, we present novel techniques for detection and analysing ID flows and we quantify the amplification of privacy-intrusive tracking practices due to cookie syncing. Our evaluation of the defensive techniques used by privacy-aware users finds that there exist subtle pitfalls --- such as failing to clear state on multiple browsers at once - in which a single lapse in judgement can shatter privacy defenses. This suggests that even sophisticated users face great difficulties in evading tracking techniques.
Article
In the early days of the web, content was designed and hosted by a single person, group, or organization. No longer. Webpages are increasingly composed of content from myriad unrelated "third-party" websites in the business of advertising, analytics, social networking, and more. Third-party services have tremendous value: they support free content and facilitate web innovation. But third-party services come at a privacy cost: researchers, civil society organizations, and policymakers have increasingly called attention to how third parties can track a user's browsing activities across websites. This paper surveys the current policy debate surrounding third-party web tracking and explains the relevant technology. It also presents the FourthParty web measurement platform and studies we have conducted with it. Our aim is to inform re-searchers with essential background and tools for contributing to public understanding and policy debates about web tracking.
Conference Paper
We investigate the degree to which modern web browsers are subject to “device fingerprinting” via the version and configuration information that they will transmit to websites upon request. We implemented one possible fingerprinting algorithm, and collected these fingerprints from a large sample of browsers that visited our test side, panopticlick.eff.org . We observe that the distribution of our fingerprint contains at least 18.1 bits of entropy, meaning that if we pick a browser at random, at best we expect that only one in 286,777 other browsers will share its fingerprint. Among browsers that support Flash or Java, the situation is worse, with the average browser carrying at least 18.8 bits of identifying information. 94.2% of browsers with Flash or Java were unique in our sample. By observing returning visitors, we estimate how rapidly browser fingerprints might change over time. In our sample, fingerprints changed quite rapidly, but even a simple heuristic was usually able to guess when a fingerprint was an “upgraded” version of a previously observed browser’s fingerprint, with 99.1% of guesses correct and a false positive rate of only 0.86%. We discuss what privacy threat browser fingerprinting poses in practice, and what countermeasures may be appropriate to prevent it. There is a tradeoff between protection against fingerprintability and certain kinds of debuggability, which in current browsers is weighted heavily against privacy. Paradoxically, anti-fingerprinting privacy technologies can be self-defeating if they are not used by a sufficient number of people; we show that some privacy measures currently fall victim to this paradox, but others do not.