Sonia Ben Mokhtar
email: sonia.benmokhtar@liris.cnrs.fr

Antoine Boutet
email: antoine.boutet@insa-lyon.fr

Pascal Felber
email: pascal.felber@unine.ch

Marcelo Pasin
email: marcelo.pasin@unine.ch

Rafael Pires
email: rafael.pires@unine.ch

Valerio Schiavoni
email: valerio.schiavoni@unine.ch

X-Search: Revisiting Private Web Search using Intel SGX

Keywords: Middleware, security, SGX, web search, privacy

The exploitation of user search queries by search engines is at the heart of their economic model. As consequence, offering private Web search functionalities is essential to the users who care about their privacy. Nowadays, there exists no satisfactory approach to enable users to access search engines in a privacy-preserving way. Existing solutions are either too costly due to the heavy use of cryptographic mechanisms (e.g., private information retrieval protocols), subject to attacks (e.g., Tor, TrackMeNot, GooPIR) or rely on weak adversarial models (e.g., PEAS). This paper introduces X-Search, a novel private Web search mechanism building on the disruptive Software Guard Extensions (SGX) proposed by Intel. We compare X-Search to its closest competitors, Tor and PEAS, using a dataset of real web search queries. Our evaluation shows that: (1) X-Search offers stronger privacy guarantees than its competitors as it operates under a stronger adversarial model; (2) it better resists state-of-theart re-identification attacks; and (3) from the performance perspective, X-Search outperforms its competitors both in terms of latency and throughput by orders of magnitude.

INTRODUCTION

Web search is with no doubt the most widely used online service, with more than 3.5 billion queries sent on a daily basis to Google alone. These queries are generally stored by search engines to analyze user behavior and to personalize responses according to profiles inferred from the past queries of the users [START_REF] Hannak | Measuring Personalization of Web Search[END_REF][START_REF] Amy | Google's PageRank and beyond: The science of search engine rankings[END_REF]. They are at heart of the economic model of online services, which heavily relies on (personalized) advertising [START_REF] Yang | Analyzing the relationship between organic and sponsored search advertising: Positive, negative, or zero interdependence[END_REF]. However, as pointed out by numerous studies, the collection and exploitation of search queries opens a number of privacy threats as they can disclose sensitive information about individuals (e.g., their age, sex, religious or political preferences, sexual orientation) [START_REF] Castelluccia | Private information disclosure from web searches[END_REF].

To deal with this issue, a number of solutions enabling the users to query search engines in a privacy preserving manner have been proposed in the literature. These solutions can be classified in three categories according to the guarantees they offer to the users.

The first category of solutions are those enforcing unlinkability between a user and her search query. The most popular approaches in this category are anonymous communication protocols (e.g., Tor [START_REF] Dingledine | Tor: The second-generation onion router[END_REF], Dissent [START_REF] Corrigan | Dissent: accountable anonymous group messaging[END_REF][START_REF] Isaac Wolinsky | Dissent in Numbers: Making Strong Anonymity Scale[END_REF], RAC [START_REF] Ben Mokhtar | Rac: A freerider-resilient, scalable, anonymous communication protocol[END_REF]). These solutions are however limited for two main reasons: first, they typically suffer from poor performance because of the heavy cryptographic mechanisms they rely on; second, despite ensuring anonymity of the requester, it has been shown in [START_REF] Sai | Web search query privacy: Evaluating query obfuscation and anonymizing networks1[END_REF] that the actual content of search queries may be sufficient to link back to the identity of the user.

To overcome this limitation, a second category of solutions aim at enforcing indistinguishability between user profiles/queries. To that end, they obfuscate user preferences/profile in such a way that the search engine cannot distinguish between a user's real interests and fake ones (e.g., Track me not [START_REF] Daniel | TrackMeNot: Resisting surveillance in web search. Lessons from the Identity Trail: Anonymity, Privacy[END_REF], GooPIR [START_REF] Domingo-Ferrer | h(k)-Private information retrieval from privacyuncooperative queryable databases[END_REF]). These approaches generally operate by sending fake queries (also called dummy queries) on behalf of the user. It has been shown [START_REF] Petit | SimAttack: Private Web Search under Fire[END_REF], however, that the external resources used for generating fake queries (e.g., RSS feeds, dictionaries) makes it possible for search engines to easily distinguish fake from real traffic. Combination of unlinkability and indistinguishability has also been proposed in the literature, yet the only existing solution that we are aware of (PEAS [START_REF] Petit | PEAS: Private, Efficient and Accurate Web Search[END_REF]) assumes a weak adversarial model of non-colluding proxy servers.

The last category of solutions are those enabling private information retrieval (PIR), e.g., [START_REF] Lindell | Private web search with malicious adversaries[END_REF][START_REF] Pang | Privacy-preserving similarity-based text retrieval[END_REF]). These approaches rely on specialized search engines implementing cryptographic techniques (e.g., homomorphic encryption) that enable to answer a user request without having access to its content. These techniques are, however, still unpractical due to their limited performance with response times in the order of seconds for very large data stores [START_REF] Aguilar-Melchor | XPIR: Private information retrieval for everyone[END_REF], which is the case of search engines.

Based on these considerations, it appears clearly that to fully support privacy-preserving Web search one must address two main challenges. The first one is to provide a practical and secure unlinkability protocol, i.e., a protocol enabling the protection of the identity of the requester in a more realistic adversarial model, without compromising the interactiveness between the user and the search engine. The second one is to provide an effective indistinguishability protocol that generates realistic fake queries, i.e., difficult to distinguish from real queries.

This paper contributes X-Search, a novel privacy proxy enabling Internet users to access Web search engines in a privacy-preserving manner. X-Search relies on Intel software guard extensions (SGX) [START_REF] Costan | Intel® SGX Explained[END_REF], a hardware technology that provides a trusted execution environment able to perform secure computations within an "enclave". Instead of submitting her queries directly to the search engine, a user sends them to the X-Search proxy to execute them on her behalf. The proxy executes attested code in a trusted SGX enclave (see §2.3 for details on the guarantees provided by SGX). The queries are encrypted while outside the enclave, and only accessible as plain text from within. The X-Search proxy then generates an obfuscated query by aggregating k random past queries and the original one using the logical OR operator in such a way that the search engine is not able to distinguish which one is the original query. As the obfuscated scheme can alter the results returned by the search engine by mixing results for the original query with results for the additional aggregated past queries, the X-Search proxy filters results to only forward to the user the results related to the initial query.

We evaluate X-Search from three perspectives: privacy, accuracy, and performance. From the privacy perspective, we analytically show that X-Search offers stronger privacy guarantees than its competitors as it operates under a stronger adversarial model. Furthermore, we experimentally demonstrate using a data set of real search queries that X-Search is more resilient to state-of-the-art re-identification attacks than PEAS (by 30% in average). From the accuracy perspective, we show that the impact of the obfuscation scheme of X-Search remains limited. For instance, with two fake queries in the obfuscated query, the user retrieves more than 80% of the results returned for the initial query. From the performance perspective, we show that X-Search outperforms its competitors both in terms of latency and throughput. Specifically, the throughput of X-Search is one order of magnitude higher than the one of PEAS and two orders of magnitude higher than the one of Tor.

The contributions of X-Search are as follows. First, we present a novel architecture to allow privacy-preserving Web searches that exploits Intel SGX to operate under stronger adversarial models than existing systems in literature. Second, we contribute a novel query obfuscation mechanism. Third, we present the implementation choices of our full prototype. Finally, we contribute an extensive evaluation, both analytically and experimentally using real-world datasets.

The remainder of the paper is organized as follows. We first introduce background concepts and overview related work in Section 2. Then we present the considered adversary model in Section 3 before presenting our X-Search proposed protocol in Section 4. Finally, we describe the considered experimental setup and the evaluation of X-Search in Section 5 and Section 6, respectively. Section 7 presents our conclusions.

BACKGROUND AND RELATED WORK

We start by describing in this section the related work in private Web search (Section 2.1). Then, we discuss the limitations of existing solutions (Section 2.2). Finally, we present Intel software guard extensions (SGX) and discuss how this novel technology can be used to improve the state of research in the field of private Web search (Section 2.3). 2.1.1 Enforcing unlinkability. This category of solutions includes a set of protocols enabling users to send their search queries anonymously to a search engine, thus enforcing unlinkability between the user identity (e.g., IP address) and her query.

Private Web Search

The most popular protocol among these solutions is Tor [START_REF] Dingledine | Tor: The second-generation onion router[END_REF], an implementation of the Onion Routing protocol [START_REF] Goldschlag | Onion routing[END_REF]. Similarly to Onion Routing, Tor sends each query through multiple nodes using a cryptographic protocol. In this protocol, queries are encrypted using multiple keys of randomly selected nodes (creating an "onion" with multiple layers) and routed through these nodes. Then, each node deciphers the received cipher text (hence removing the outer-most layer of the onion) and forwards it to the next node until the onion reaches the exit node. The exit node retrieves the query and sends it to the search engine on behalf of the user. This protocol assumes the participating relays to faithfully forward the onions, which might not be true as some may behave selfishly (e.g., by dropping onions) or even maliciously (e.g., by injecting fake traffic to slow down the system).

RAC [START_REF] Ben Mokhtar | Rac: A freerider-resilient, scalable, anonymous communication protocol[END_REF] overcome these limitations, by enabling anonymous communication in presence of malicious and selfish nodes. In this protocol, nodes are organized on several virtual rings such that, for a given ring, a node has a predecessor node and a successor node. A node might be part of several rings and thus have multiple predecessors and successors. To ensure that no message is dropped by a freerider, nodes have to broadcast all messages they relay. Broadcast messages have to circulate through all nodes in the ring such that if a node does not receive a message from one of its predecessors, it considers this predecessor as a freerider. The modifications made by RAC suffer from performance limitations, achieving a throughput that is orders of magnitude lower than Tor.

Another robust solution to anonymous communication is the Dissent protocol [START_REF] Corrigan | Dissent: accountable anonymous group messaging[END_REF][START_REF] Isaac Wolinsky | Dissent in Numbers: Making Strong Anonymity Scale[END_REF]. This protocol enforces accountability in presence of malicious and selfish participants. However, its performance is even worse than the one of RAC as it is a combination of two heavy cryptographic protocols: the dining cryptographers protocol (DC-NET) [START_REF] Chaum | The dining cryptographers problem: Unconditional sender and recipient untraceability[END_REF] and a data mining protocol used to permute a set of fixed-length messages with cryptographically strong anonymity [START_REF] Brickell | Efficient anonymitypreserving data collection[END_REF].

In addition to the performance issue, protocols enforcing unlinkability have also been shown not to resist reidentification attacks [START_REF] Petit | SimAttack: Private Web Search under Fire[END_REF]. Indeed, the issue comes from the fact that search queries themselves disclose enough information for breaking the unlinkability property.

Enforcing indistinguishability.

To protect users against re-identification attacks, solutions enforcing indistinguishability have been proposed. The aim of these solutions is to avoid search engines distinguishing between a user's real interests and fake ones, hence protecting her privacy. This is generally achieved either by generating fake queries (e.g., TrackMeNot [START_REF] Daniel | TrackMeNot: Resisting surveillance in web search. Lessons from the Identity Trail: Anonymity, Privacy[END_REF], GooPIR [START_REF] Domingo-Ferrer | h(k)-Private information retrieval from privacyuncooperative queryable databases[END_REF]) or by altering the user's query (e.g., QueryScrambler [START_REF] Arampatzis | A query scrambler for search privacy on the internet[END_REF]).

TrackMeNot is a Firefox plugin that periodically generates fake queries and send them to the search engine on behalf of the user and independently of her real queries. Fake queries in TrackMeNot are generated using RSS feeds.

GooPIR introduces k fake queries inside the user's real query. All these queries (i.e., the real one and the k fake ones) are separated by the logical or operator and sent to the search engine. Fake queries in GooPIR are generated by using randomly selected keywords from a dictionary. QueryScrambler protects users by replacing their queries by semantically related queries. More precisely, for each user query, it generates a set of related queries by generalizing the concepts used in the initial query. Then, by merging and filtering all the results obtained with these related queries, it retrieves the most plausible results for the initial query.

PEAS improves over existing solutions by combing an unlinkability protocol with an indistinguishability protocol. The former is based on two non-colluding proxy servers. The first one handles user identities without having access to their requests, while the second generates fake queries, and send them to the search engine on behalf of the user. To generate fake queries, PEAS uses a co-occurrence matrix built from past user queries.

One of the major limitation of these solutions is that it is still easy to discern the fake queriesfrom real ones, as shown by re-identification attacks [START_REF] Petit | SimAttack: Private Web Search under Fire[END_REF]. We highlight this issue in Figure 1. The show the CCDF (i.e., Complementary Cumulative Distribution Function) of the maximum similarity between fake queries generated by PEAS (i.e., based on the co-occurrence of terms in past queries) and TrackMeNot (i.e., based on RSS feeds) and past queries on the AOL dataset (see Section 5.4 metric). This result shows that in both cases most of the fake queries are significantly different from real queries.

Alternative Search

Engines. This category of solutions build alternative search engines generally based on Private Information Retrieval (PIR) thus enforcing privacyby-design. In these systems, users access information stored on the distant server without revealing to the latter what information they access. The only information known by the search engine is that the user has sent a query. In general, PIR protocols consist of three algorithms: the constructions of protected queries (keywords are at least encrypted), the execution of the information retrieval (preventing the search engine to access the query and its results), and finally the reconstruction of the result list. Part of these algorithms is performed on the clients, the other part on the distant server. These generally rely on heavy and unpractical [START_REF] Aguilar-Melchor | XPIR: Private information retrieval for everyone[END_REF] cryptographic protocols, especially when the accessed data stores contain millions of documents, the normal case for today's search engines.

Open Challenges in Private Web Search

From the analysis of state of art private Web search solutions, we distinguish two major challenges: one for enforcing unlinkability and one for enforcing indistinguishability. The main open challenge for enforcing unlinkability is to design efficient protocols that resist strong adversaries. Indeed, existing protocols are either efficient but assume honest but curious servers (e.g., Tor, PEAS) or robust to malicious adversaries but have unpractical performance (e.g., Dissent, RAC).

In term of indistinguishability, the main open challenge is to better resist re-identification attacks by effectively hiding the original query among fake queries. This requires the generation of realistic fake queries that are as close as possible to real queries.

The remaining of this section shows how to leverage Intel Software Guard Extensions and address the above two challenges.

Intel Software Guard Extensions

Cloud software runs in multitenant computing nodes, remotely maintained by third parties. From the clients' point of view, the environment to remotely run their software can be compromised in several ways. The third party or the person in charge of managing its hardware may be malicious. System managers have total access privileges on their hardware to potentially access or tamper with any stored information. Besides, the remote machine may run compromised operating systems, possibly executed by another (malicious) tenant. It is therefore hard to trust software running in the clouds.

Homomorphic encryption [START_REF] Gentry | Fully Homomorphic Encryption Using Ideal Lattices[END_REF] is an appealing solution for untrusted environments. A user encrypts data, send it to an untrusted server. It is still able to process the ciphertext without having access to its content. The algorithms proposed so far prove that the concept is sound but impractical because of their enormous complexity. Preliminary yet partial solutions promise to improve the current situation [START_REF] Naehrig | Can Homomorphic Encryption Be Practical?[END_REF].

To overcome this limitation, several hardware manufacturers extended their architectures with some form of trusted execution environment (TEE). In a nutshell, a TEE can certify what software it runs, and data stored inside it can only be accessed by its own software. With TEEs, users do not need to trust the infrastructure provider's execution environment, because it can do no harm to their data, but only the TEE manufacturer.

We use a TEE to ensure the confidentiality and integrity of the X-Search proxy. It is the responsability of the client to ensure that a certified proxy is running within a trustworthy TEE. The communication between client and proxy is then encrypted, and the user's real interests are only accessible in the client domain and inside the TEE. In the following, we present Intel's SGX [START_REF] Mckeen | Innovative instructions and software model for isolated execution[END_REF], our platform of choice and TEE to implement the X-Search proxy.

Intel calls an enclave a TEE created with SGX. Enclaves are created and destroyed using specific privileged system calls. When an enclave is created, SGX allocates a memory region that is protected from all accesses from outside the enclave itself, including kernel, hypervisor and peripheral DMA. Applications can interact with enclaves via procedure calls, in both ways. Parameters and results are copied in and out enclaved memory when a call crosses the enclave border. Intel offers a software development kit to define and handle in-and out-calls and to manage the enclaves' lifecycle.

The CPU keeps for each enclave a page cache and ensures that each page is assigned to exactly one enclave. System software, although untrusted, is responsible for assigning pages to enclaves. An initial set of pages is prepared by the system software, by assigning enclave pages with unencrypted data and code in it. The CPU keeps a cryptographic hash for the memory pages assigned to each enclave. After all initial pages are loaded into the enclave, the system software issues an instruction to mark the enclave as initialized. At that moment the memory hash, or measurement hash, is computed. From this point on, loading unencrypted pages is disabled and application software can enter the protected environment through the enclave interface.

SGX offers instructions for managing keys and for signing certificates of an enclave. Communication between a remote entity and an enclave is done through a local, untrusted software proxy. The enclave can send its certificate to the remote entity, which can then verify it with an appropriate authority. An authentic certificate and a correct measurement hash attest that the correct program has been loaded inside an authentic enclave. This process is also known as attestation. As certificates are signed within enclaves, remote entities can verify that it was not forged nor modified by an untrusted proxy, and trusted channels can be built (using untrusted components).

Access to enclave memory is prevented by hardware, and all enclaves in a processor can have up to approximately 90MB of a protected memory called EPC (enclave page cache). Paging can still be used to access larger address spaces. Enclave data residing in the processor's internal cache are hashed and encrypted before flushed to the EPC. Memory checks are made through a chain of a stateful hash codes using random numbers created every time a page is encrypted. The chain is stored in untrusted memory, and its root is kept in the CPU, inaccessible from outside, what prevents any tampering attacks in memory, including replay. Paging is completely handled by untrusted software, in the local operating system.

Improving Security with SGX

SGX has been successfully used to improve the security and privacy of other systems. Code attestation mechanism coupled with the trusted environment provide an assurance that can enforce security guarantees in a plethora of systems, a few of those described next.

Hoekstra et al. [START_REF] Hoekstra | Using Innovative Instructions to Create Trustworthy Software Solutions[END_REF] show how SGX improves the security of sensitive code and data within three scenarios. First, they use enclaves in the client-side to store shared secrets with financial institutions, and to generate one-time passwords based on such secrets. Second, an enterprise-grade digital rights management system that stores document encryption keys within user enclaves. Such keys are distributed on demand, and discarded by the enclaves after use. The documents pass through the enclave for decryption, which in turn generates encrypted bitmaps using the GPU symmetric key. Third, a video-conferencing application with IP-connected enclaves that exchange encrypted media content and interact with the local hardware using encrypted protocols. These systems prevent malicious software (including high-privilege ones) from gaining access to the private data.

Verifiable confidential cloud computing (VC3) is a MapReduce implementation with data confidentiality and integrity for both code and data that guarantees that the distributed computation globally ran correctly to completion and was not tampered with [START_REF] Schuster | VC3: Trustworthy data analytics in the cloud using SGX[END_REF]. To execute map and reduce tasks, VC3 instantiates enclaves with encrypted code in it. It implements a key distribution protocol such that guarantees that any enclave that contributes to the job runs the correct code and shares the necessary keys for decrypting code and data. All data sent to tasks is encrypted, as well as all data produced by the tasks. Mapper and reducer tasks generate extra encrypted hashes that are used to verify that they properly processed all their input data. Leveraging enclaves, VC3 supports a threat model with powerful adversaries, that may control all cloud software and hardware, except for the physical processors used in the tasks computations.

SCBR (secure content-based routing) implements a contentbased publish/subscribe engine [START_REF] Pires | Secure Content-Based Routing Using Intel Software Guard Extensions[END_REF] where all message filtering is done inside secure enclaves. All messages are encrypted when outside enclaves, and the filters operate on plaintext headers. It uses a hybrid encryption scheme with different keys for header and payload to avoid sending all data through the enclave boundary. This improves performance and reduces the enclave memory footprint. An experimental evaluation shows that SCBR adds small overheads when compared to insecure plaintext matching outside enclaves.

Kim at al. [START_REF] Kim | A first step towards leveraging commodity trusted execution environments for network applications[END_REF] explored the possibility of using enclaves to provide security and privacy in network applications. They initially demonstrate how to use enclaves to prevent softwaredefined inter-domain routers to disclose their routing policies or how the Tor anonymity network [START_REF] Dingledine | Tor: The second-generation onion router[END_REF] can be strengthened to run its directory authorities to attest each other. Attackers can still launch denial-of-service attacks but they cannot alter the directory behavior. Also, by putting onion routers within enclaves, they can attest their integrity and their admission can be done automatically so directory authorities can be eliminated, and the routers can simply keep track of their membership in a distributed hash table. Finally, they present how enclaves can be used to securely introduce in-network functionality into TLS sessions.

TrustJs is a framework for trustworthy execution of security-sensitive JavaScript inside commodity browsers [START_REF] Goltzsche | TrustJS: Trusted Client-side Execution of JavaScript[END_REF]. It leverages enclaves to protect the client-side execution of JavaScript, enabling a flexible partitioning of web application code. Being attested by the server, the enclaved interpreter can be used to offload its computation, which results in lower latencies in the user experience and lower performance demand for the application servers.

Recent work investigate the resilience of SGX enclaves against side-channel attacks [START_REF] Weichbrodt | AsyncShock: Exploiting Synchronisation Bugs in Intel SGX Enclaves[END_REF][START_REF] Xu | Controlled-channel attacks: Deterministic side channels for untrusted operating systems[END_REF]. This problem is orthogonal to the one investigated by this paper, and thus considered outside of the scope.

ADVERSARY MODEL

As further detailed in the following section, the protocol presented in this paper involves three premises: the client side, the X-Search proxy nodes running on cloud platforms and the search engine.

We assume that the code and the platform on which client nodes run are trusted. Then, as further presented in the following section, our protocol relies on X-Search proxy nodes running on public cloud platforms. We assume that these nodes are untrusted and can behave in a Byzantine manner [START_REF] Lamport | The Byzantine generals problem[END_REF], that is they can arbitrarily deviate from a correct behaviour (i.e., they can be subject to a failure, a bug or even behave maliciously). Finally, we assume that the search engine is honest but curious [START_REF] Goldreich | Cryptography and Cryptographic Protocols[END_REF]. This means that the search engine behaves correctly when it comes to fetching answers to a specific request but it may collect and exploit in all possible ways the information they receive from clients. In particular, we assume that the search engine was able to collect as preliminary information about each user in the system a set of past queries. This preliminary information is stored in user profile structures.

Moreover, we also assume that if the search engine identifies that the client is relying on a private web search mechanism (e.g., an anonymous communication protocol or X-Search), it may run state-of-the-art re-identification attacks (e.g., [START_REF] Gervais | Quantifying Web-Search Privacy[END_REF]) in order to re-associate the received request to a known user profile. We further assume that the search engine may collude with proxy nodes (e.g., TOR relays or proxy nodes in X-Search) in order to learn more information about the anonymous client.

X-SEARCH

We start this section by presenting an overview of our X-Search protocol (Section 4.1). Then, we detail how the unlinkability is ensured (Section 4.2). Finally, we introduce the obfuscation and filtering mechanisms used to provide indistinguishability (Section 4.3).

Protocol Overview

To efficiently protect users during Web search, X-Search combines unlinkability and indistinguishability. As previously discussed in Section 2 these two schemes are complementary as the former hides the identity of the requesting user while the latter hides her query. Figure 2 depicts the architecture and the execution flow of X-Search. Specifically, the user interacts with the search engine through an X-Search proxy node hosted on untrusted public cloud services. We assume the X-Search proxy to be deployed on physical nodes with available SGX instructions, a scenario that we expect to be common in a near future.

As this proxy node acts as an intermediate node between the search engine and the user, it hides the user identity (i.e., her IP address). The proxy node is also in charge of obfuscating the user queries, and filtering the results returned from the search engine before forwarding them back to the user.

More precisely, the user starts by sending her query Qu to the X-Search proxy (Figure 2 -). Then, the proxy node generates a new obfuscated query. To achieve that, the proxy retrieves k random past queries Qp1, ..., Q pk () and aggregates them with the original query in a random order using the logical OR operator. Next, the proxy stores the initial query in the table of past queries () and sends one single obfuscated query to the search engine (). The search engine is queried by the proxy without using end-to-end encryption 2 . Contrary to state of the art indistinguishability protocols, X-Search uses as fake queries past queries sent by real users. This allows to have fake queries that are effectively indistinguishable from the user's real one. This is possible because past queries are securely stored inside the TEE with no correlation to the identity of their originating users, which prevents any malicious entity from exploiting them.

As the obfuscated query can alter the results returned by the search engine, e.g. by mixing results for the original query with results for the additional aggregated past queries, the proxy node includes a filtering step. Once the search engine sends back the results to the X-Search proxy (), the filtering removes the results returned by the search engine that are not associated to the original query. Finally, the remaining results are returned to the user (). These results are tampered by the proxy to remove any URL redirection used for analytics for instance.

We note that the X-Search proxy node does not maintain individual profile structures associated to each user. Instead, it only updates a table containing the last x past queries. To improve performance, the proxy uses multiples threads. The query table is kept in memory and shared among all threads. Moreover, the user sends her query to the proxy node through an encrypted tunnel with an end point inside the SGX enclave. Consequently, the protection of the original query is ensured from the client until inside the TEE of the proxy node. Once outside from the proxy in flight toward the search engine, the original query of the user is protected thanks to the used obfuscation mechanism.

Enforcing Unlinkability

The X-Search system offers to end users search unlinkability by relying on a query broker. This broker runs within the client's domain, such as a local daemon process executing alongside the client's Web browser. The broker is in charge of the SGX attestation step. When the user issues a Web search query, her Web client first connects to the local broker. Then, the broker encrypts the request and forwards the cipher to an X-Search node hosted in an untrusted cloud provider. The X-Search node receiving the cipher generates the obfuscated query as further detailed in the following section. Before sending out the obfuscated query, the original one is securely stored in the SGX reserved memory. When the search engine sends back the response to the X-Search node, the latter filters out the relevant results, i.e., those related to the original user query, encrypts them and delivers them backward to the broker. Finally, the broker decrypts the result and delivers it upward to the Web client.

Enforcing Indistinguishability

To enforce indistinguishability, X-Search relies on an obfuscation mechanism. This mechanism (Algorithm 1) aims at hiding the user queries among multiple fake queries. More precisely, the proposed obfuscation mechanism randomly aggregates the original query with k fake queries separated with logical OR operators (lines 2-8). These fake queries come from the table of past queries maintained in the private memory of the X-Search proxy (Algorithm 1, variable H). Indeed, to avoid building irrelevant fake queries and possibly easily identifiable by the adversary as fake (as discussed in Section 2.2), the obfuscation mechanism of X-Search leverages real past queries chosen at random. Using real past queries ensures that each sub-query of the obfuscated query can be mapped by an adversary conducting a re-identification attack to an existing user profile, thereby making the task of re-identification more complicated to perform.

As an SGX enclave has approximately 90MB of private memory (Section 2.3), we need to bound the memory usage of the X-Search proxy by limiting the size of H to only keep the x last queries sent by users. This size limitation acts as a sliding window where only the most recent x queries are exploited. Once the obfuscated query is generated, the initial query is stored in the history (line 9). This obfuscation mechanism impacts the results returned by the search engine. Indeed, the results of the search engine Algorithm 1: Generation of an obfuscated query input: Q : initial query, H : history of queries (H = Q0, ..., Qm), k : the number of fake queries. obfuscatedQuery ← ∅ ; 10 contain a mix of answers corresponding to (k + 1) queries (i.e., k fake queries and the initial one). Consequently, the X-Search proxy filters the returned results to remove those which are not related to the initial query. To do this filtering step, the X-Search node exploits the initial query and the associated fake queries. Algorithm 2 describes this filtering process. For each result r from the result set, the algorithm determines if it corresponds to the initial query as following. A similarity score is assigned to each query (lines 5-6) based on the title and the description of the result. The function nbCommonWords(q, e) computes the number of common words between a query q and an element e. A result r is considered related to the initial query, and hence forwarded to the user, if the initial query has the largest score (lines 7-8).

Algorithm 2: Results filtering.

input: Qu : initial query, pastQuery = {Qp1, . . . , Q pk } : set of past queries, R : set of results for

Qu ∨ Qp1 ∨ • • • ∨ Q pk . R ← ∅ ; 1 q + ← {Qu, Qp1, . . . , Q pk } ; 2 for r ∈ R do 3 for qi ∈ q + do 4 score[qi] ← nbCommonWords(qi, title(r)) 5 + nbCommonWords(qi, desc(r)); 6 if score[Qu] = max q i ∈q + score[qi] then 7 R ← R ∪ {r} ; 8 return R ;

EXPERIMENTAL SETUP

In this section we present the experimental setup we used to evaluate X-Search. This comprises: the dataset we used, the comparison baselines we compared against, the evaluation methodology and the metrics used to assess the performance of X-Search.

Web Search Dataset

To assess X-Search, we use a real world Web search dataset from the AOL query logs [START_REF] Pass | A Picture of Search[END_REF]. This dataset contains approximately 21 million queries, formulated by 650,000 unique users over three months (from March to May of 2006). For the sake of comparison, we use the same methodology as described in [START_REF] Petit | PEAS: Private, Efficient and Accurate Web Search[END_REF] to focus our evaluation on the 100 most active users, as they are the most exposed to an adversary willing to unveil their identities. Indeed, the most active users have exposed more preliminary information to the search engine through their past querying activity. To reflect this preliminary information collected by the search engine, we built an off-line profile for each user. To do that, we split the dataset in a training set to build these user profiles, and a testing set to apply and to evaluate the privacy of X-Search. The training set contained two thirds of user queries and the testing set the remaining ones.

Comparison Baselines

We compare the robustness and quality of X-Search against two baselines from the state-of-the art, namely Tor [START_REF] Dingledine | Tor: The second-generation onion router[END_REF] and PEAS [START_REF] Petit | PEAS: Private, Efficient and Accurate Web Search[END_REF]. As described in Section 2.1.1, Tor leverages a proxy chain to provide unlinkability. More precisely, this solution uses encryption schemes to hide the identity of a user from the search engine perspective. PEAS, in turn, combines unlinkability and indistinguishability by hiding the identity of the requesting user as well as obfuscating the original query with fake queries. Specifically, the unlinkability property is ensured by a proxy composed of two trusted nodes relaying the original queries while the obfuscation is achieved locally on the client by aggregating in a random order k fake queries with the original one. These fake queries are generated from the graph of co-occurrence between terms in the history of user queries. Lastly, we also consider a Direct baseline solution, for which the users send directly their queries to the search engine without any protection. We do not compare X-Search against PIR-based solutions because they require to use crypto-based search engines.

Methodology

This section presents the methodology adopted to evaluate X-Search. We assess X-Search along three dimensions: the offered privacy (i.e., the protection of users' queries), the achieved accuracy (i.e., the quality of the results returned by X-Search), and the pure system performance (i.e., the efficiency of X-Search in terms of throughput, latency and memory usage).

Privacy.

To evaluate privacy, we leverage SimAttack [START_REF] Petit | SimAttack: Private Web Search under Fire[END_REF] a re-identification attack for which the code is available and that has been shown to outperform previous attacks including a machine learning attack presented in [START_REF] Sai | Web search query privacy: Evaluating query obfuscation and anonymizing networks1[END_REF]. To run this attack, we assume that the attacker holds a set of user profiles built from the learning part of the dataset. Then, we protect each query of the testing part using X-Search before sending it to the search engine. Then, for each obfuscated query, the attack tries to re-identify both the requesting user and the initial query among fake ones.

More precisely, SimAttack is based on a similarity metric sim(q, Pu) that characterizes the proximity between a query q and a user profile Pu. This profile represents the preliminary information associated to user u collected by the adversary. This preliminary information can be viewed as the history of queries of the users before they protect their Web search activities. In our case, Pu contains queries that belong to the training set of user u. The similarity metric used by SimAttack accounts the cosine similarity of q and all queries part of the user profile Pu, and returns the exponential smoothing of all these similarities ranked in ascending order. We empirically set the smoothing factor at 0.5 as it provides the best performances.

To achieve the re-identification from the obfuscated query of X-Search, we compute the similarity metric for each subquery embedded in the obfuscated query and each user for which the adversary has a profile. If only one couple of query and user have the highest similarities, SimAttack returns this couple corresponding to the initial query and to the initial requester. Otherwise, the attack is unsuccessful.

Accuracy.

The obfuscation mechanism of X-Search (i.e., adding past queries) impacts the results returned by a search engine. Consequently, we evaluate the capacity of X-Search to filter results not related to the initial query before forwarding them back to the user. To achieve that, for a given initial query, we compare results returned by the search engine for this query and the results returned for the associated obfuscated query after the filtering step.

Our experiments use the Bing search engine. Search queries are directed to the http://www.bing.com/search=q? address.

As the OR operator implemented by Bing only works with single-word queries, we simulated the execution of an obfuscated query Q obf = Qp0 OR ... OR Qu OR ... OR Q pk by submitting each sub-query Qpi and Qu independently and by merging the (k + 1) result sets. To circumvent the query×day limit imposed by Bing, for each value of k (i.e., the number of fake queries), we run the experiment on a random subset of the testing set composed of 100 queries. Unless otherwise specified, we consider the first 20 results in our accuracy-related experiments.

Performance.

To evaluate the performances of X-Search from a system perspective, we implemented a fullyfunctioning prototype. Our implementation uses C++ and rely on the Intel SGX SDK (v1.8) libraries and tools [20]. The prototype is deployed on a machine with an Intel® Core i7-6700 processor [START_REF]Intel® Core i[END_REF] and 8 GiB RAM running on Ubuntu 14.04.1 LTS (kernel 4.2.0-42-generic).

The main performance bottlenecks when using intel SGX are known to be the transitions between trusted and untrusted modes (inside/outside the enclaves) and the intensive usage of memory, with two stages: (i) when exceeding the processor's last cache level, which requires cache eviction and the consequent cryptographic and integrity checks; and

(ii) when exceeding the EPC size, triggering memory swaps scheduled by the underlying operating system. An excessive memory usage can be caused by the management of the past queries inside the enclave's protected memory. We evaluate this aspect of X-Search in Section 6.3. Furthermore, in order to avoid unnecessary and costly mode transitions, we limit the enclave interface to allow only essential operations that deal with sensitive information. Procedure calls made by the vulnerable code are called ecalls (enclave calls), whereas the ones made the enclave trusted code are called ocalls (outside calls). The enclave interface offered by the X-Search node is as follows:

ecalls init( parameters )
Setup options for X-Search. request( sock, buff, len ) Provision of data to the enclave, coming from the given socket. ocalls sock connect( host, port ) Performs the DNS lookup and connection to server, returns the socket file descriptor.

send( sock, buff, len )

Sends data through the given socket. recv( sock, buff, len )

Receives data from the given socket. close( sock )

Close socket file descriptor.

We measured the system capacity by observing latency for increasing throughput configurations when X-Search was configured to reply immediatly to requests. Memory usage was assessed by populating the past queries store inside the enclave with a real dataset and observing its occupancy. Finally, we measured respone times considering the complete chain, including the search engine delays. Results are described in Section 6.3.

Metrics

We consider three types of metrics in our evaluation. The privacy metric measures the level of protection offered by X-Search and its ability to preserve the users' privacy. The accuracy metric, in turn, assesses the quality of the query results provided to users according to their original queries. Lastly, system metrics evaluate the performance and the effectiveness of our solution.

Privacy.

To assess the privacy we consider the reidentification rate. This rate aims to retrieve for each protected query, both the content of the initial query and the identity of the associated user. The re-identification rate is defined as follow: re-identif ication rate = |Q id | |Q| where Q id is the set of correctly re-identified queries (i.e., re-identification of both the initial query and the associated user), while Q is the set of original queries sent by users. This metric is defined between [0, 1] where 0 represents the best solution (i.e., no re-identification) and 1 represents the worst solution (i.e., all queries are re-identified).

Accuracy.

The evaluation of the accuracy consists in comparing the lists of results associated to the original query and the results returned with the obfuscated query aggregating the original query and fake ones. To measure the accuracy, we consider the precision (i.e., correctness) and the recall (i.e., completeness) as defined below:

precision = |Ror ∩ Rxs| |Rxs| recall = |Ror ∩ Rxs| |Ror|
where Ror is the set of results returned by the search engine for the original query, and Rxs the set of results returned by X-Search. Both metrics are in [0, 1]. The best accuracy is provided with a precision and a recall at 1.

System Metrics.

To evaluate the behavior of X-Search from a systems perspective, we consider the following metrics. First, we measure the throughput (requests/second) to assess the scalability of X-Search by measuring its capability to operate properly (adequate response times) even with a growing number of users requesting the service. Second, looking at occupancy (in MB) using a memory profiler we assess the efficiency of our working prototype. Finally, we look at the latency to serve the search results back to the users once they send their queries.

EVALUATION

This section presents the experimental evaluation of X-Search over three dimensions: the privacy, the accuracy and the system performance, respectively described in Sections 6.1, 6.2, and 6.3. Our evaluation draws the following conclusions: (1) X-Search better resists state-of-the-art re-identification attack, (2) it has a limited impact on the accuracy of the results returned to users, and (3) systemwise, it outperforms its competitors, sometimes by orders of magnitude.

Privacy

We start by evaluating the capacity of X-Search to preserve the user privacy and to improve user protection compared to PEAS. To this end, we measure the robustness of X-Search against a classical re-identification attack. Figure 3 shows the re-identification rate for PEAS and X-Search for different values of fake requests, i.e., k. Results for k = 0 represent the re-identification rate for a solution enforcing only unlinkability (e.g., Tor). In this case (i.e., without query obfuscation), an adversary using only the history of user queries as preliminary information, is able to re-associate almost 40% of novel queries to their originating user. This confirms that unlikability solutions alone are not sufficient to effectively protect users against re-identification attacks. Adding only one fake query drops this re-identification rate to 16% for X-Search and almost 20% for PEAS. This difference comes from the fake query generation process. Indeed, using real past queries makes X-Search more robust to the re-identification attack as all sub-queries of the obfuscated query can be mapped to past queries of other users, which creates confusion from the attacker side. On the contrary, generating fake queries based on the co-occurrence of terms does not ensure PEAS to build fake queries closer to a user profile than the original one.

The re-identification rate decreases accordingly to k (i.e., the number of fake queries). For all value of k, X-Search provides a better protection to the users (i.e., 1-re-identification rate) than PEAS. The improvement of X-Search over PEAS varies from 23% for k = 1 to 35% for k = 7.

Accuracy

The accuracy of X-Search can be measured by evaluating the impact of the obfuscation and the filtering mechanisms on the search results returned to users. Specifically, we study if the filtering mechanism is able to remove results related to the fake queries while keeping the ones related to the initial query. Figure 4 depicts the precision and the recall of X-Search according to an increasing value of k. As expected, these curves show that both the recall and the precision slightly decrease according to k. However, the results returned to users are still accurate. For instance with k = 2, the value of the recall is higher than 80%. This means that more than 80% of the results returned to users with X-Search are the same results as the ones returned if the original query was sent directly to the search engine. Moreover, the measured precision in this case is higher than 80%, which means that only around 20% of the results returned to users can be associated to a fake query and not to the initial query. These numbers confirm that X-Search preserves the quality of the results returned by the search engine.

System Performance

We evaluate the system performance of X-Search to answer the following questions: (1) is our implementation fast? ( 2) is it memory-efficient and can it be executed within the current SGX memory limitations? and ( 3) is it usable and responsive to end-users?. We begin by looking at the throughput/latency ratio of the X-Search proxy. To perform this experiment, we iteratively increase the rate at which requests are directed toward the X-Search proxy, until the point where the latency to handle each request becomes too high. For this experiment, we rely on the wrk2 workload generator [START_REF][END_REF] to measure the throughput and latency based on the request rates issued to the X-Search proxy. Note that these measurements are taken without actually hitting the web search engine, to better understand the saturation point of the proxy. We compare against Tor and PEAS. 3 These results are presented in Figure 5. We plot the number of requests per second and the observed latency per request on the x-axis and y-axis, respectively. Due to the different magnitude of performances, this plot uses a log-log scale.

We observe that X-Search scales well, and it is capable of serving up to 25, 000 requests/sec with sub-second latencies. Instead, PEAS deteriorates much faster, with as few as 1000 requests/sec being served with a sub-second latency. In our experiments, Tor performs very poorly: handling as few as 100 requests/sec at an average reply latency of 8.86 milliseconds, around 10× slower than X-Search serving 1000 requests/sec. This result confirms our implementation to be fast and scalable. Next, we investigate how much memory is required by the obfuscation scheme. For this experiment, we used a much larger dataset than the one described in Section 5. Specifically, we use all the 6 millions unique queries available in the AOL dataset. We leverage Valgrind's Massif [START_REF] Seward | Valgrind 3.3 -Advanced Debugging and Profiling for GNU/Linux Applications[END_REF] to trace and profile the heap memory allocations executed by the xsearch process. Figure 6 presents our result. Observing the trend of the X-Search curve, it is clear that the EPC size is largely sufficient to store at least 1M queries, a number that can support with ease the obfuscation mechanism.

We complete this part of the evaluation by evaluating the user-perceived performance of the system, e.g. the end-to-end latency of a Web query from the submission to the reception of the results. Due to rate limiting schemes adopted by the Bing's search engine, in this experiment we only issue 100 queries, picked at random between the AOL dataset. We compare the observed latency between three different scenarios:

(1) the client contacting directly the web engine (hence without any privacy guarantees), (2) the same set of queries being routed via the Tor network, and finally (3) using X-Search. Figure 7 presents the results as a Cumulative Distribution Function (CDF) of the measured round-trip network latencies. We can observe that X-Search allows for much faster replies: the median response time is 0.577 seconds, and the 99 th percentile is 0.873 seconds. The results over the Tor network are surprisingly bad from a user-perspective: the median time to route a Web search over the onion routers was 1.06 seconds at the time of our experiments (May 2017), while the 99 th of the queries complete in up to 3 seconds. 4The Tor network largely exceeds well-known usability margins [START_REF] Palmer | Web Site Usability, Design, and Performance Metrics[END_REF], while X-Search offers a usable and secure browsing experience.

CONCLUSION

User behavior tracking by major service providers is one of the main privacy threats in today's Internet. This is particularly the case with search engines, as they are among the most widely used online services and search queries reveal sensitive information about individual users, such as their age, sex, or religious or political preferences. Solutions exist in the literature for enabling users to access Web search engines in privacy-preserving way. However, these solutions either do not resist malicious adversaries or are robust but have poor performance.

In this paper, we proposed a novel architecture for privacypreserving Web search, which relies on a trusted execution environment (Intel SGX) to support stronger adversarial models than existing solutions. Our system, X-Search, operates as a proxy which stores and leverages user past queries within a protected SGX enclave and generates obfuscated queries on behalf of the user. It does so by aggregating random past queries in such a way that the search engine is not able to distinguish which one is the original query, but still provides relevant results for the user. Upon receiving a response from the search engine, the X-Search proxy filters results to only forward those related to the initial query.

We have implemented a working prototype and evaluated it both analytically and experimentally using real-world datasets. Our observations indicate that X-Search can indeed provide accurate results without disclosing personal information about individual users. Most importantly, X-Search does so with a throughput that is orders of magnitude higher than its competitors, i.e., the PEAS and Tor protocols.

Figure 2 :

 2 Figure 2: The X-Search architecture and execution flow.

1 index 5 else 6 obfuscatedQuery 7 index ← index - 1 ; 8 H

 156718 ← random(k + 1) ; 2 while sizeof(obfuscatedQuery ) <= k do 3 if index = 0 then 4 obfuscatedQuery ← OR(Q) ; ← OR(H[random(m)]) ;

9

 9

Figure 3 :

 3 Figure 3: X-Search reduces the number of deanonymized queries compared to PEAS.

Figure 4 :

 4 Figure 4: Results returned by X-Search are close to results associated to the original query.

Figure 5 :

 5 Figure 5: Latency/tput rate comparison for X-Search proxy, PEAS and Tor.

Figure 6 :

 6 Figure 6: X-Search: memory usage. The memory allowed for a single enclave can fit more than 1M queries before hitting the SGX EPC's memory limits.

Figure 7 :

 7 Figure 7: User-perceived web search round-trip time for 100 queries with X-Search, over the Tor network and directly contacting the web search engine.

  Private Web search has been an active research area in the last decade in order to counterbalance the numerous threats open due to the oversharing of users' search queries by search engines. This research field is likely to gain even more attention due to the recent legislation change in the United States, which enable ISPs to sell user browsing history without their consent.

1 In this context, existing solutions to private Web search can be classified in three main categories. The first two categories (presented respectively in Sections 2.1.1 and 2.1.2) enable clients to use existing search engines while offering them additional privacy guarantees. The third category (see in Section 2.1.3) includes alternative search engines implementing specific privacy-preserving protocols.

http://www.nbcnews.com/news/us-news/trump-signs-measure-letisps-sell-your-data-without-consent-n742316

Using HTTPS could be also supported by the SGX enclave.

Note that PEAS and Tor require custom clients to forge messages following their protocol, whereas X-Search can be used with thirdparty clients issuing regular HTTP requests, such as wget or curl.

We could not conduct a similar experiment using PEAS due to a bug in the code.

ACKNOWLEDGMENTS

The research leading to these results has received funding from the European Commission, Information and Communication Technologies, H2020-ICT-2015 under grant agreement number 690111 (SecureCloud project). Rafael Pires is also sponsored by CNPq, National Counsel of Technological and Scientific Development, Brazil.


Stephan Foldes
email: foldes.istvan@mta.renyi.hu

come

Comments on the notion of information system in the Budapest Convention on Cybercrime, the EU directive, and selected penal codes

Stephan Foldes* August 2017

1. International instruments and national legislation. The penal codes of a number of countries having ratified the Convention on Cybercrime signed in Budapest in 2001 (the Convention),1 or bound by Directive 2013/40/EU of the European Parliament and Commission on attacks against information systems (the Directive),2 now contain provisions which criminalize certain acts directed at information systems or computer data (illegal system access or interference, data interception or interference, and making available certain tools for these offences). Both the Convention and the Directive provide definitions for the relevant concepts of " system" and " data" that appear as objects or instruments of cybercrime. In their national legislation the states bound by the Convention or the Directive are free to extend these notions of system and data, but not to restrict them. The Convention presently binds 55 countries, of which 26 are members of the European Union. (Ireland and Sweden signed the Convention but did not ratify it, while Denmark is not bound by the Directive.3 ) Most of the non-EU members of the Council of Europe also signed and ratified the Convention (the Russian Federation being a significant exception), as did some non-European countries like Japan, Canada and the USA. Thus a good number of countries are bound by both the Convention and the EU Directive. Among these we shall examine certain provisions of the penal codes of France, Germany, Austria and Hungary.

2. Relationship between systems and data. The primary functional relationship between information systems and data is one of unavoidable instrumentality. Data is not like water, which has many uses requiring neither aqueducts nor artificial reservoirs. In order to be useful, data in any significant quantity requires information systems. But an information system typically does not only process, store or transmit datait also requires data for its very operation. It is a fundamental thesis of computer science that programswhich contain the instructions that a machine executes when it processes dataare data themselves.4

3. Concern with data preceded concern with systems. The concern of the law with data and information historically preceded its concern with systems. Among the earliest legal provisions of modern times is § 20 of the Austrian Constitution of 25 April 1848 (Pillersdorfsche Verfassung) that guarantees the secrecy of mail. 5 In the Convention, signed in 2001, and certainly in the Directive of 2013, the concern with data has no priority over the concern with systems. Such an evolution of priorities in French legislation since the late seventies was already noted by Chilstein. 6 The Directive's dominant concern with systems is also clear from its title. 7 The Directive requires the criminalisation of five offences (Articles 3-7), corresponding precisely to those defined in Title 1 of the Convention (Articles 2-6), containing no provisions for computer-related forgery and fraud, content-related offences or copyright infringements as in Titles 2 to 4 of the Convention. These five offences in the Directive, in the order in which they appear there, are (i) illegal access to a system, (ii) illegal system interference, (iii) illegal data interference, (iv) illegal interception of data transmissions, (v) making available of tools for illegal access, interference or interception.

4. Focus on system interference. Undoubtedly the most direct attacks against an information system are within the ambit of the system interference provisions (Art. 5 of the Convention and Art. 4 of the Directive); this offence is also our central concern in this note. Illegal access provisions criminalise a behaviour of endangerment; the materialization of the danger may result in system (or data) interference or influencing data, or the unwanted availability of proprietory data to others. According to both the Convention and the Directive, system interference needs to be criminalised in national law only if committed by influencing data.

Influencing data means " inputting, transmitting, damaging, deleting, deteriorating, altering or suppressing" computer data, both in the Convention and the Directive. National legislation may go beyond and not require that the interference be accomplished by influencing data, but it should not restrict the modes of influencing data allowing criminal prosecution. (Although in some cases, because of the overlapping of the types of data influencing action enumerated, a less than complete enumeration of data influencing behaviours may not prevent national courts from interpreting formally narrower offences in national law in a way to give full effect to the provisions of the Convention and the Directiveas Chilstein points out in the case of data influencing behaviours criminalised by the French penal code. 8 In some cases, however, the national provisons may be too narrow to allow the courts to fill the gap. 9 ) 5. Systems and data int he Convention and the Directive. The definitions of what is meant by computer system and data are not identical but fairly consistent between the Convention, the Directive, andas we shall see belowthe notions adopted by some of the penal codes of the implementing states. The Convention's terms of " computer system" and " computer data" are rendered in the equally official French text of the Convention by " système informatique" and " données infomatiques" . The English term " computer" refers to a device, a computing machine, while the French term " informatique" seems to be more abstract and processoriented. (In the academic context " informatique"when used as a noun and not an adjective is commonly translated as "computer science" or " computing science" .) This minor difference seems to be resolved by the the adoption of " information system" and " système d'information" in the English and French versions of the Directive.

6. Automatism and programmability. Both the Convention and the Directive define systems (computer systems and information systems, respectively) in terms of devices that process data, automatically and pursuant to a program. Presumably stressing the program-determined nature of data processing was deemed necessary as the drafters of the Convention (which the Directive later recognized as " the legal framework of reference for combating cybercrime" 10 ) deemed that "automati" means nothing more than" without direct human intervention" 11 . Devices processing data without direct human intervention would include non-programmable mechanical devices measuring and recording physical data, thus requiring that processing be done " pursuant to a program" is indeed an additional differentia specifica of the definition. 12 As programs are themselves data containing instructions for devices, the system definitions refer to data in two different ways: data that the systems process and data that carry the instructions for processing. Man-made programs may indeed be considered a form of indirect human intervention. 13 7. System notions in penal codes: France, Germany, Austria, Hungary. Comparing the system interference offences in the penal codes of France, Germany, Austria and Hungary, we first note that the automatic nature of the processing that information systems perform is explicit in the term" système de traitement automatique de données (STAD)" used in the French Code pénal. Taking a more formal approach, the Hungarian Büntető Törvénykönyv (Btk.) 14 contains a separate interpretation clause 15 defining the term "információs rendszer" (information system) similarly to the Convention, but using the term "installation" instead of "device", requiring automatism explicitly, bypassing the notion of being driven by a program, and explicitly including data storage and transmission among the possible functions of the system. The system concepts of the Austrian and German penal codes (both referred to as Strafgesetzbuch, StGB) differ in that the German code uses a broader system notion. The Austrian penal code, 16 without providing a definition or using a terminology that would explain the concept, simply refers to " Computersystem" , whichaccording to its usual technical meaningwould certainly evoke the notions of automatism and being driven by programs. The German penal code 17 uses the more general term of Datenverarbeitungsanlage (data processing installation) -"Anlage" similar to the genus proximum of the Hungarian definition -, but without requiring automatism, thus extending the criminalisation to attacks against systems whose functioning might involve direct human intervention. It also explicitly includes passive data storage devices (Datenträger) that do not need to be part of the processing system, or even connected or related thereto. 18 Finally, we note that unlike the Convention and the Directive, none of the four penal codes refer explicitly to the functioning of the systems according to programs, although the national courts would probably not view rare but conceivable cases of interference with non-programmable installations as constituting system interference. 9. System notion of Directive includes data required for purposes of the system. To be distinguished from the data that an information system as a device or group of devices is designed to process, data necessitated by the system in order to function, more precisely "computer data stored, processed, retrieved or transmitted by that device or group of devices for the purposes of its or their operation, use, protection and maintenance" also come within the ambit of the definition of systems in the Directive (Article 2), which thus extends the "device only" system notion of the Convention. However, this extension of the system conceptnot appearing explicitly in the penal codes of France, Germany, Austria or Hungary seems to make more inclusive only the offence of illegal system access, not that of system interference, which according to the Directive can already only be committed by influencing data. (Use of the means of influencing data is also a constitutive element of the offence of system interference in the Austrian penal code 19 Only the title of § 303b (Computersabotage) suggests a link that may after all be required with the processing devices, in order that an interference with the storage devices be held to constitute the offence and sanctioned as such 19 With a rather limited number of criminalised data influencing behaviours behaviours as we observed above (See above Comment 5. Focus on system interference) system access, system and data interference, as well as interception offences (in the sense of Articles 3-6 of the Directive, in infringing security measures, in influencing data, or as a technical means used in interception, respectively). In fact, while the Directive explicitly includes data as an instument of crime for both the system and data interference offences,which by the minimum rule principle of Article 1 need not be a constitutive element in provisions enacted by national legislation -, there is not and should not be any requirement that information systems be used as a means of committing any of the offences described in the Directive. The penal codes of EU member state parties to the Convention of course must and do also contain offences in which computer systems are an essential element of crime as instrumenta sceleris, but in these offences the criminal attack is not against computer systems.

11. Telecommunication systems. Originating in society's basic concern for privacy and the secrecy of non-public communications, criminal law first came to protect telecommunication systems, and computer systems subsequently. A much noted case in the late seventies in Canada 20 ,a signatory later of the Budapest Convention -, in which students at the University of Alberta interfering with the university's computer system were prosecuted, demonstrated that such interference may not be punishable under penal provisons protecting telecommunication systems. In that case the key distinction was teleological, the Supreme Court of Canada holding that " the function of the computer is not the channelling of information to outside recipients" , rather, the computer is " to permit the making of complex calculations, to process and correlate information and to store it and enable it to be retrieved" . The Convention and the Directive do not define computer systems by their purpose, but by the technical functions that they are able to perform and do perform. On the other hand it appears that telecommunication systems relying on digital technology should be included in the information system notion of cybercrime legislation enacted in implementation of the Convention and the Directive. Hungarian legal doctrine seems to support this inclusion, 21 which would be also in accordance with European legislators' explicit concern for availability, privacy and security in the area of communications, expressed in the EU Directive. 22

  Limited role of systems as instrumenta sceleris in the Directive. As opposed to the Convention, the Directive is only concerned with systems as instruments of crime to the extent that data required for purposes of the system may be used as a means to commit illegal

	(Störung der Funktionsfähigkeit eines
	Computersystems, StGB 126b), but not required by the penal codes of Hungary [Btk. 423. §
	(2) a) ], Germany [Strafgesetzbuch § 303b (1) 3.] or France (Code pénal, Article 323-2).
	10. 16 Bundesgesetz vom 23. Jänner 1974 über die mit gerichtlicher Strafe bedrohten Handlungen
	https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10002296 17 https://www.gesetze-im-internet.de/stgb/StGB.pdf 18

http://www.coe.int/en/web/conventions/full-list/-/conventions/treaty/185

http://eur-lex.europa.eu/eli/dir/2013/40/oj

Recitals of the Directive, (32)

Viewing program as data was an idea present in Turing's mathematical model of the not-yet-built computer. See A.M. Turing, On computable numbers, Proc. London Mathematical Soc. 1937, Section 6: The universal computing machine

Verfassungsurkunde des österreichischen Kaiserstaates vom 25. April 1848, § 20. Das Briefgeheimnis ist unverletzlich.

D. Chilstein, Législation sur la cybercriminalité en France. Revue internationalede droit comparé. Vol. 62 No. 2,2010, pp. 553-606. See pages 554-556.

See also: Recitals of the Directive, system concerns in (1)-(6) versus data concerns in (6), (9) and (14)