Jaromir Dobias
email: jaromir.dobias@tu-dresden.de

Privacy Effects of Web Bugs Amplified by Web 2.0

Keywords: Secret Tracking, Social Network, Surveillance, Web 2.0, Web Bugs, Web Privacy

Web bugs are Web-based 1 digital tracking objects enabling third parties to monitor access to the content, in which they are embedded. Web bugs are commonly used by advertisers to monitor web users. The negative impact of web bugs on the privacy of users is known for over a decade. In recent years, Web 2.0 technologies have introduced social aspects into the online media, enhancing the ability of ordinary users to act as the content providers. However, this has also allowed endusers to place web bugs online. This has not only increased the number of potential initiators of monitoring of web surfing behaviour, but also potentially introduced new privacy threats. This paper presents a study on end-user induced web bugs. Our experimental results indicate that, in the light of Web 2.0 technologies, the well-known concept of web bugs leads to new privacy-related problems.

Introduction

Web bugs are Web-based digital tracking objects enabling third parties to monitor access to the content, in which they are embedded (e.g., webpages, e-mails or other electronic documents). They have been utilised for several years by Internet marketing or advertising companies for the purpose of tracking and profiling users visiting bugged webpages and analysing their behaviour.

Web bugs are based on a simple mechanism: an HTTP request sent to the tracking server when the tracked content is accessed (see Section 3). This effect can be induced automatically, e.g., by opening webpage or e-mail in a Web browser, e-mail in an e-mail client 2 or document in a text processor, on condition that an external object (e.g., image, script, style sheet, web banner, audio/video stream, etc.) is embedded inside the opened content.

The existence of a significant amount of scientific papers concerning web bugs [START_REF] Alsaid | Detecting Web Bugs with Bugnosis: Privacy Advocacy through Education[END_REF][START_REF] Martin | Hidden Surveillance by Web Sites: Web Bugs in Contemporary Use[END_REF][START_REF] Nichols | Big Brother is Watching: An Update on Web Bugs[END_REF][START_REF]Use of internet cookies and web bugs on commerce web sites raises privacy and security concerns[END_REF][START_REF] Smith | Synchronizing Cookies with Email addresses[END_REF][START_REF] Smith | The Web Bug FAQ[END_REF] indicates that web bugs are already an old and well-known problem.

Observer Content provider

Observer's image-hosting server <IMG> HTML tag pointing to the image Fig. 1. This figure illustrates observer's deployment of the web bug in the form of an external advertising image. The observer embeds an IMG element in the webpage pointing out to the external location of the image under the observer's control.

However, these studies primarily deal with the 'old' World Wide Web, now known as Web 1.0, and hence do not reflect fundamental changes in the nature of the Web environment introduced by Web 2.0 technologies. In general, web bugs can be utilised for the establishment of a tracking infrastructure across multiple servers, without the need to incorporate tracking functionality to every single server hosting the tracked content. We have discovered that web bugs in Web 2.0 environments (which we will call Web 2.0 bugs), such as online Social Network Sites (SNS), have significantly different properties than traditional web bugs on webpages in the classical Web 1.0 environment. Web 1.0 bugs are usually tracking devices introduced by, or on request of, an (observer ), such as a net marketing company or a web analytics company on a web site of a (content provider ). A practical example might be a content provider intentionally hosting advertising banners loaded from external location under observer's control (see Fig. 1). This allows the observer to monitor access to the content provider's content which embeds the advertising banner. In this model, the content provider provides (dynamic) content, and the observer is only capable of keeping track that the content is visited by end-users. There is relation between the entity initiating the tracking device and the entity hosting content. This is different with Web 2.0 bugs. If the web bug tracking mechanism is employed into a Web 2.0 environment, the more dynamic creation of content comes into play. Web 2.0 applications are characterized by the fact that endusers are not only consumers, but can also be producers; they can contribute content. Secondly, in Web 2.0 applications end-users can not only contribute content to their own 'domain', but they can also contribute to content provided by others.

Hence, in Web 2.0 environment the technical concept of web bugs can be employed by ordinary users for tracking access to content provided by themselves, as well as provided by others, without these others being aware of the introduction of the tracking mechanism. This shift of monitoring web behaviour by (commercial) entities to end-users 'spying' on each other motivated this research. This paper explores the world of Web 2.0 bugs to study the possibilities of user induced Web 2.0 bugs and explore the privacy effects of those Web 2.0 bugs. The study is set up as a real-world experiments in which we developed a Web 2.0 bug and tested its operation in a real-world Web 2.0 environment.

Outline The remainder of this paper is organized as follows. Section 2 describes existing work related to web bugs. Section 3 describes Web 2.0 bugs and describes the basic settings of the experiments. The results of our experiments are presented in Section 4. Section 5 summarizes the study and presents our conclusions.

Related Work

The term "web bug" was introduced by Richard M. Smith. In his 1999 report, The Web Bug FAQ [START_REF] Smith | The Web Bug FAQ[END_REF], he defines web bug as ". . . a graphics on a Web page or in an Email message that is designed to monitor who is reading the Web page or Email message". Even though this definition is not incorrect, it omits a wide scale of additional Web-based objects, which can also be used for tracking purposes utilising the same tracking mechanism as web bugs. Additionally, Smith's definition neglects other types of multimedia integrating external Web-based objects, which makes them prone to tracking via web bugs as well (e.g., e-mail clients, word processors, RSS readers, interpreters of Flash content and others). It is therefore necessary to extend the definition of web bugs beyond utilising images for tracking purposes and to include that webpages and e-mails are not the only environments for tracking via web bugs today.

Shortly after releasing his report on web bugs, Smith demonstrated that it is also possible to deploy persistent cookies by web bugs in order to link user requests to their e-mail addresses [START_REF] Smith | Synchronizing Cookies with Email addresses[END_REF]. After spreading the word about privacy invasive capabilities of web bugs, security researchers, legal scholars, governmental agencies and privacy-aware individuals started to address this problem [START_REF] Martin | Hidden Surveillance by Web Sites: Web Bugs in Contemporary Use[END_REF][START_REF] Nichols | Big Brother is Watching: An Update on Web Bugs[END_REF][START_REF]Use of internet cookies and web bugs on commerce web sites raises privacy and security concerns[END_REF].

Trying to raise public awareness, a research team from the University of Denver developed a web bug detection tool called Bugnosis [START_REF] Bugnosis | [END_REF]. The tool was primarily developed for journalists and policy makers. The authors of Bugnosis hoped, that these two groups might better understand potential threat and privacy impacts of web bugs than the ordinary users and inform the public of the risks and initiate corresponding counteractions.

The idea of warning users against web bugs when browsing websites by Bugnosis was successful at the time, proven by the fact that the tool was installed by more than 100,000 users. The essential problem, however, was that Bugnosis was capable of generating warning messages only, without any defensive steps actively enhancing user privacy. Another problem was, that the Bugnosis only dealt with external embedded images with specific properties3 . Last but not least, Bugnosis was developed as an extension plugin for Internet Explorer 5 without support for other browsers or environments. Therefore, Bugnosis is an unsuitable solution for eliminating the privacy threats caused by modern day web bugs.

Even though there are currently some solutions available to disable web bugs [START_REF] Ghostery | [END_REF][START_REF]Web bug detector[END_REF], none of them deals with the threat of individual users utilising web bugs. As we will see, Web 2.0 bugs introduce novel threats that warrant novel defenses. An observer, who wants to track access to a particular webpage, just embeds an external object to the content on the page to be monitored, just like in the case of Web 1.0 bugs. However, in this case the observer is not a company, but an individual end-user.

Next, when an arbitrary visitor opens the webpage containing the embedded object, the visitor's browser automatically generates an HTTP request to retrieve the data of that object from the object-hosting server (see Fig. 2). 4 Each HTTP request incorporates attributes which are to some extent specific to the visitor and which can thus be used for differentiating a particular visitor from others. The HTTP request incorporates:

Observer

Content provider

Observer's image-hosting server Visitor

1. GET Web page 3. GET Object 2.
4.

V V V5. V Fig. 2. This figure illustrates tracking via web bugs (image is used in this case). The fingerprint icon symbolises visitor-specific attributes which are contained in each visitor's HTTP request. Paths 3 and 5 depict the side effect caused by the web bug enabling the observer to track the visitor.

-Time when the visitor accessed the tracked webpage; -IP address of the device which loaded the webpage 5 ; -The URL of the tracked webpage6 ; -The URL of the external object (including URL parameters); -The type of browser accessing the webpage7 ; -Cookie (previously stored in the user's browser by the web bug).

The visitor-specific identifiers contained in the visitor's HTTP requests can be collected on the object-hosting server (step 3 in Figure 2) as soon as he visits the tracked webpage (step 1 in Figure 2). The observer can collect tracked identifiers from each visitor of the tracked webpage on the object-hosting server and secretly monitor access to the tracked webpage (step 5 in Figure 2).

Key Aspects of Tracking by Individual Users

Nowadays, there are many free public Web-hosting services enabling users to deploy server-side scripts (for instance written in PHP, ASP, or Ruby) on the web. Ordinary web users acting as observers can take advantage of these services and use them hosting the web bugs and collect information about the visitors of the tracked sites. This makes deploying web bugs much easier because it is unnecessary for the observer to run their own dedicated server with public IP address.

The observer might additionally use an anonymisation service to upload the script, deploy the web bugs and afterwards collect the tracked data from visitors of the tracked content. This allows the observer to cover his identity, which is usually not the case when the tracking is done by dedicated Internet marketing or advertising company.

Internet marketing or advertising companies usually host the tracked content directly on devices under their own control.

In contrast, an individual user acting as an observer exploits the fact, that he himself can embed external objects to existing online content and that these objects are loaded from a remote location under his control. Therefore, web bugs provide a covert side-channel enabling individual users to track the content indirectly without the involvement of the content provider. The content providers in this case provide an environment prone to embedding tracking devices. It allows the observer to covertly track other users that interact within the environment created by the content provider.

The motives behind tracking performed by individual users may also differ from those of typical Internet marketing or advertising companies. While such companies are primarily motivated by economical interests, tracking performed by individual users may be driven by motivations such as jealousness (e.g., a jealous husband tracking his wife), sexual motives (e.g., deviants tracking their potential victims), hate (e.g., members of extreme organisations tracking their enemies), etc.

Background of the Experiment

In our experiment, we used an image object for tracking access to selected webpages. The PHP script (see Listing 1.1) was used for logging the data from the HTTP requests. When an arbitrary user accessed the tracked webpage, his browser generated an HTTP request pointing to the location of the embedded image. As soon as the PHP script was activated by the incoming request, it logged the data corresponding to the request and sent back the data of the image.

The PHP script was titled index.php and stored in the directory called logo.gif. The advantage of this solution was that the PHP script was activated with a URL in the form of "www.example.org/logo.gif", even though logo.gif actually activated a PHP script. This way of implementing a web bug makes unnecessary to reconfigure any settings of the object-hosting server, thus allowing the web bug to be hosted on any public web server facilitating PHP scripts.

This solution did not affect the user experience in any way when communicating with the tracked webpage and hence raised no suspicion about the tracking.

In our experiment, web bugs were deployed to selected locations in an experimental social networking platform, the social network MySpace and a public profile in a university information system. 8 . Afterwards the tracked data was collected and analysed for the purpose of this experiment.

Results

Web Bugs in the Experimental Social Networking Platform

Several selected forums were tracked by web bugs in the experimental social networking platform 9 . We used images for tracking 10 , which were embedded to selected forums via comments. User access to the tracked forums were logged by the PHP script displayed in Listing 1.1. 8 We are aware that these experiments are not compliant with the EU data protection regulation which prohibits the processing of personal data without a legitimate purpose. We have not informed the users of the various systems that we were collecting personal data, nor have we provided information about the purposes. On the other hand, this is similar to how real web bug exploits would operate. 9 The Slovak experimental social networking platform kyberia.eu served as a basis for the initial phase of our experiments. 10 The image as a binary object is not necessary for activation of the web bug tracking mechanism. Only the HTML tag IMG pointing to the location of tracking script matters.

Users' accesses were logged as long as our comments containing web bugs were displayed to visitors of the tracked forums. The number of displayed comments were adjusted individually by each user of the experimental social networking platform, and therefore, the older our comments with embedded web bug became, the more often user access not detected via web bug.

The situation was different in forums under our administration. We embedded web bugs directly into the content of the main topic of some forums under our administration. That guaranteed that the tracking was not dependent on the comments of users in that forums which enabled us to detect each user's access to these forums.

Linkage of nicknames Thanks to built-in function of the experimental SNS enabling users to see nickname of a user lastly visiting a particular forum and time of his visit, tracked records from users were linked to their nicknames based on the time correlation (see Listing 1.2 and 1.3).

The arrival time of the user's request was extracted locally on the PHP hosting server by using the PHP date command. The extracted time did not always precisely correspond to the last-visited time displayed in the social networking platform (due to communication delay and/or desynchronised clocks). However, this information was sufficient for manual linkage of tracked records to users' nicknames. Visitor-identifying information Once the tracked record was linked to a user's nickname, further information about the user was extracted. This included WHOIS information derived from the user's IP address, information about the user's browser extracted from the User-Agent header (providing information identifying the underlying operating system) and information on the URL of the forum tracked by the web bug.

After having assembled this information, we were able to estimate the geographical location of the user and/or (in few cases) the institution from which the user was connecting. That provided us with an interesting picture of the real persons behind the nicknames.

Statistical information

As far as each logged record included time information, it gave us a statistical view on how many users accessed a particular forum in a particular time frame. Based on this data, it was derived which users spent more time on the tracked forum compared to the others, exposing the users' interest in a particular topic discussed in the tracked forum.

Further leaked information Web bugs deployed to an experimental social networking platform allowed us to detect access to tracked forums via Google Cache and Google Translator. In the first case we detected which keywords a user used before visiting the forum (see Listing 1.411 ). In the second case, we detected the language, which the forum was translated to by the user (see Listing 1.5 12 ). According to further information provided by the WHOIS service, the request came from a device residing in the country for which the translation was requested. Based on this information, we assume that someone from the particular foreign country was interested in the topic presented in the tracked forum. h t t p : / / t r a n s l a t e . g o o g l e u s e r c o n t e n t . com/ t r a n s l a t e c ? h l=XX&s l=YY&u=h t t p : / / example . o r g / forum007& prev=/ s e a r c h%3Fq%3DZZZZZ%26 h l%3DXX%26s a%3DG &r u r l=t r a n s l a t e . g o o g l e .XX&usg=ALkJrhhjb8ybR1X4 Listing 1.5. Detected request on translation of the tracked forum (from Referer)

From this experience we learned that web bugs can also reveal very specific actions of the user in case of accessing the tracked content by exploiting the data embedded in HTTP headers (searched keywords in this case).

Note 1. The experimental SNS is primarily targeted for relatively homogeneous group of users, both geographically and linguistically, and therefore request for translation coming from the foreign IP address was considered unusual.

User profiles

We aimed our research on the user profiles as well as a potential resource of data trackable via web bugs. We embedded web bugs to profiles of selected users in the experimental SNS by adding comments with external pictures. Next we collected the same type of data as we did in forums before. this case however, the data collected by tracking user visits were not related to a specific topic, but rather to specific identity (the profile owner).

Based on the information on users' last visit also incorporated in user profiles, we discovered, that the most frequent visitor of a particular user profile in experimental SNS is the owner of the profile himself. The second interesting finding (specific to the platform) was, that most users visit their own profiles at least once per session. This is probably caused by the design of the platform, which provides access to profile-management functions in the profile interface only.

Most information gained from the profiles of the tracked users originated from owners of the profiles themselves. This involved information on their ISPs, types of browsers, operating systems used and information on how often and when do they access their profiles.

We also detected other users visiting some tracked profiles on a regular basis. We concluded that those users are interested in the particular tracked profiles.

Web Bugs in MySpace

The experimental SNS described in section 4.1 was an easy target for web bugs. It was mainly due to its open and transparent design enabling registered users to gain a lot of information on activities and interests of other users by means of functions built in the SNS. Another reason for that can be geographic, national and linguistic homogeneity within the community of the experimental SNS and relatively small number of its active users (up to 10,000 members). Therefore we changed focus to a more established, and potentially more 'secure' environment, the well-known social network -MySpace. We deployed the web bug to a single profile hosted on MySpace, whose owner agreed to take part in our research. We intentionally selected this participant because he also had an account in the experimental social networking platform.

Based on the correlation among the tracked data gained from both of his profiles, we detected access to participant's MySpace profile from users accessing his profile previously in the experimental social networking platform. Furthermore, we were able to link visitors of the tracked MySpace profile to their nicknames from the experimental social networking profile. This deanonymisation of the MySpace visitors was possible because we already had sufficient information gained from the experimental social networking platform. Another reason facilitating linking identities was that the set of all potential different identities detected was small enough to find highly probable correlations. The detection of unique identities and linkage would be much more easier, if we would utilise cookie mechanism assigning unique identifier to each new visitor detected. However in our experiments we decided to avoid using cookies because we were interested in the capabilities of simple tracking devices.

Web Bugs in the Public Profile of the University Information System

In our last experiment, we embedded the web bug to the author's profile in the local university information system, which gave us technical capability to monitor access to it. We were unable to link detected access to our profile with any of the data previously tracked from MySpace or experimental social networking platform. In other words, none of the users visiting the experimental social network site or the tracked MySpace profile visited the author's profile in the University information system (at least, we could not establish plausible links on the basis of the collected data in the experiments). It is important to mention that users of the University information system are identified by their real names while a user-selected nicknames are used for identifying users in the experimental SNS. If a user visiting the author's experimental SNS profile and author's profile in the University information system were detected, it might indicate that it is a user aware of author's real identity and his partial identity related to experimental SNS.

On the other hand, we were able to estimate the probable location of the visitors (at least the country), nationality and operating systems and platforms used by the visitors. We were also able to detect visitors interested in the content of the author's profile by detecting repeated requests from the same source.

In two particular cases, we were able to link the tracked data to requests from identifiable individuals. That was possible because in those cases we had additional information (gained from other channel, i.e. not via web bugs) that an individual, whose identity was known to us, was accessing our profile within a certain time-frame. As far as no further requests from other users visiting our profile within that specific time-frame were detected, we concluded that the intercepted requests originated from the particular identifiable individual. Hence, we were able to link information on the intercepted IP addresses, types of the operating systems and browsers to a natural living person.

Overall findings

An interesting overall findings of the experiments conducted are, that the information gained by web bugs, relates to (1) the content published in the tracked media, (2) the time span of tracking, (3) the amount of resources tracked by web bugs and (4) the ability of the observer to link tracked requests each other as well as to link them with other user-related information.

Another interesting finding is that in order to find a link among actions performed by a particular user it is not necessary for the intercepted traces (i.e., tracked data in the log file) of the user's actions to be equipped with a globally unique identifier (e.g., session ID contained in the cookie). It is sufficient to have a set of (not necessarily unique) attributes assuring uniqueness within the specific domain (e.g., combination of the IP address together with HTTP referer unique within a specific time-frame).

Conclusion

Emerging Web 2.0 applications, such as SNSs, contain more and more userrelated data and provide enhanced tools supporting interaction among users. That on the other hand also provides a suitable environment for tracking users. In this paper we aimed to experimentally explore potential privacy effects of web bugs amplified by Web 2.0 technologies.

Our small-scale experiments show that the well-known tracking mechanism of web bugs, can be exploited in previously unexplored way -by ordinary users spying other users in Web 2.0 environments. Unlike Internet marketing or advertising companies, who have been known as the most common employers of web bugs, the motivation of users to track other users can go beyond marketing and advertising interests, and thus lead to new potential privacy threats.

We decided to call web bug amplified by Web 2.0 technologies 'Web 2.0 bug' as the term for generalised version of the already known problem. For Web 2.0 bug it is common that it can be exploited by individual users in order to track other users by means of Web 2.0 technologies. Moreover, any Web 2.0 based external object embedded in some content which generates HTTP request automatically when the corresponding content is opened by a visitor can be seen as a potential Web 2.0 bug. Additionally, aside from the webpages or emails also other content-providing media must be concerned as an environment suitable for Web 2.0 bug tracking. The text documents, presentation documents, spreadsheets and other types of media allowing external objects to be embedded can also be used for Web 2.0 bug tracking.

The crucial problem is that Web 2.0 bugs exploit a core principle of hypertext -the interconnection of documents -which provides the foundation for Web technologies. Diminishing or eliminating these privacy-impairing effects of the Web 2.0 bugs is therefore difficult.

The most vulnerable applications with respect to Web 2.0 bugs are nowadays SNSs because of their massive concentration of user-related data and user interaction. However, Web 2.0 bugs themselves can not influence functionality of SNSs and therefore are usually underestimated and overlooked by providers of SNSs, which was also experienced in our experiments. On the contrary, as we showed in this paper, Web 2.0 bugs can cause a huge damage to privacy of the users of such sites, especially in case that any user has in fact the ability to perform tracking of other users.

For elimination or mitigation of this problem it is therefore necessary to take into account both points of view -(1) the Web 2.0-based application as well as (2) the user of a the Web 2.0-based application as a potential victim of Web 2.0 bug tracking.

Web 2.0-based applications (especially SNSs as currently the most sensitive environment prone to Web 2.0 bug tracking) should be designed in such a way, that the external content embedded by users does not automatically trigger the Web 2.0 bug tracking mechanism when accessed by visitors. The visitor accessing potentially risky content should be informed about the risk of being tracked by Web 2.0 bugs. Moreover, such risky actions should require visitor's consent. Some existing SNSs (e.g., Facebook ) partially solve this problem by creating thumbnail of an external object (e.g., image or video stream), storing this thumbnail on trusted servers and embedding the thumbnail in place of the external object itself. The original external object behind the thumbnail is loaded from its external location on visitor's demand only (e.g., by clicking the play button) which reduces the set of potentially tracked visitors to those wittingly interacting with the remote content.

The user should have a privacy-enhancing tool available which would provide him a user-level protection against Web 2.0 bugs. This is especially important for those cases, when a particular Web 2.0 application itself does not provide protect its users against Web 2.0 bugs. The privacy-enhancing tool should keep track on user's actions and warn the user in case that user's action would cause Web 2.0 bug tracking effect. In such a case the user should be asked whether the external object should be loaded and if his decision should be permanent or temporary concerning the particular object. The user should be able to manage his privacy and specify which domains are trusted for the user. Moreover, the user should also be able to switch among several modes of operation: the (deny all ) and (accept all ) modes should enable the user to implicitly deny all traffic potentially having Web 2.0 bug tracking effect (in the deny all case) or accept all traffic regardless of the potential Web 2.0 bug tracking effects (in the accept all case). The (accept trusted/ask untrusted ) mode should load all content considered by the user as trusted and ask the user what to do with untrusted content 13 . Last but not least, the (accept trusted/deny untrusted ) mode should automatically accept all content considered by the user as trusted and deny untrusted content without asking the user.

Currently, the Privacy Dashboard [START_REF]Primelife privacy dashboard[END_REF] developed under the project PrimeLife seems to be a promising solution dealing with the problem of Web 2.0 bugs. The Privacy Dashboard is an extension plugin for Firefox web browser which helps the user to track, what kind of information websites collect about the user. It enables the user to see e.g. which external websites are used by the currently visited website, if there are some invisible images on the website or if the website enables third parties to track the user across the web. Additionally, it enables the user to block content from external resources and thus proactively disable the Web 2.0 tracking effect.

However, even the current version of Privacy Dashboard 14 does not deal with all aspects of Web 2.0 bugs discussed in this paper. Therefore, building more advanced privacy-enhancing mechanisms solving the problem of Web 2.0 bugs comprehensively remains a challenging task for the future.

Listing 1 . 1 .

 11 <?php $time = date ( "H: i : s -d .m. y" ) ; $ i p = $ SERVER [ "REMOTE ADDR" ] ; $ r e f = $ SERVER [ "HTTP REFERER" ] ; $ r e q = $ SERVER [ 'REQUEST URI ' ] ; $ a g t = $ SERVER [ 'HTTP USER AGENT ' ] ; $data = "---\n [ TIME : ] " . $time . " \n" ; $data = $data . " [ IP : ] " . $ i p . " \n" ; $data = $data . " [REFERRER : ] " . $ r e f . " \n" ; $data = $data . " [BUG LOCATION : ] " . $ r e q . " \n" ; $data = $data . " [AGENT : ] " . $ a g t . " ] \ n" ; $ l o g F i l e = " l o g g e r . l o g " ; $ h a n d l e r = fopen ( $ l o g F i l e , ' a ' ) o r die ( " e r r o r " ) ; f w r i t e ( $ h a n d l e r , $data ) ; f c l o s e ( $ h a n d l e r ) ; $ p i c = " . / i c o n . g i f " ;header ( "Cache-C o n t r o l : no-cache , must-r e v a l i d a t e " ) ; header ( "Pragma : no-c a c h e " ) ; header ( " Content-Type : image / g i f " ) ; header ( " Content-Length : " . f i l e s i z e ( $ p i c ) ) ; r e a d f i l e ( $ p i c ) ; ?> PHP script intercepting data from web bugs.

Listing 1 . 2 .Listing 1 . 3 .

 1213 Last visited information available for each forum of the experimental social networking platform [ TIME : ] 1 3 : 3 7 : 0 1 -2 3 . 0 6 . 1 0 [ IP : ] 1 . 2 . 3 . 4 [REFERRER : ] h t t p : / / example . o r g / forum007 [BUG LOCATION : ] / l o g o . g i f /? i d=bug-in-forum007 [AGENT : ] M o z i l l a / 5 . 0 ( X11 ; U; Linux x 8 6 6 4 ; en-US ; rv : 1 . 9 . 2 . 6 ) Gecko /20100628 Ubuntu / 1 0 . 0 4 ( l u c i d ) F i r e f o x / 3 . 6 . 6 ] . . . Tracked record captured by the PHP script linkable to nickname023

  h t t p : / / webcache . g o o g l e u s e r c o n t e n t . com/ s e a r c h ? q= c a c h e : FE7 fiAerdEJ : example . o r g / forum007+XXX+YYY&cd=1&h l=ZZ Listing 1.4. Detected keywords of search request and access via Google Cache

Bugnosis detected web bugs by evaluating additional properties of images, such as length of the URL, domain of the external image, unique appearance on the webpage, etc[START_REF] Alsaid | Detecting Web Bugs with Bugnosis: Privacy Advocacy through Education[END_REF].

It is assumed that an ordinary modern Web browser is used, which automatically loads images and other external objects embedded on a user requested webpage.

Even if the IP address is not specifically associated to the the user's device (user can be behind NAT, VPN, proxy, anonymisation network, etc.), it can reveal some context-dependent information (see Section 4) disclosing information about the visitor.

[START_REF] Smith | The Web Bug FAQ[END_REF] This information, extracted from the referer field of HTTP header can be easily spoofed or removed by the user. In our experiment, we detected however only minor cases in which users intentionally modified this header field (see Section 4

).[START_REF]Primelife privacy dashboard[END_REF] This information is extracted from the User Agent field of the HTTP header.Though it can be easily modified by the user, it provided interesting information as well (see Section 4).

Data was anonymised. Strings "XXX" and "YYY" substitute keywords and "ZZ" substitutes country code.

Data was anonymised. "XX" substitutes code of the targeted language, "YY" substitutes code of source language and "ZZZZZ" substitutes keyword which navigated user to tracked forum.

has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement No. 216483 for the project PrimeLife. they are based on Web technologies. 2 This behaviour is implicitly disabled by the most of the modern e-mail clients.


Sebastian Haas
email: haas@iig.uni-freiburg.de

Ralph Herkenhöner
email: ralph.herkenhoener@uni-passau.de

Denis Royer
email: d.royer@sirrix.com

Ammar Alkassar

Hermann De Meer

Günter Müller

Supporting semi-automated compliance control by a system design based on the concept of separation of concerns

Manual compliance audits of information systems tend to be time consuming. This leads to the problem that actual systems are not audited properly and do not comply to data protection laws or cannot be proven to comply. As a result, personal data of the data subject are potentially threatened with loss and misuse. Automatic compliance control is able to reduce the effort of compliance checks. However, current approaches are facing several drawbacks, e.g. the effort of employing cryptographic hardware on every single subsystem. In this paper a system design is presented that is able to circumvent several drawbacks of existing solutions thereby supporting and going beyond existing mechanisms for automated compliance control.

Introduction

With respect to privacy of data subjects, several countries already have established laws and regulations that obligate companies to have extensive measures, which ensure proper and secure handling of personal data (PD). However, recent incidents of data loss1 raise the question why these companies have failed in fulfilling this obligation. The given incidents indicate that weak or ineffective data protection is employed by those companies and that the law enforcement is deficient in detecting the lack of data protection. The latter points show that the current procedures of inspecting the compliance to data protection laws seem to be ineffective and improper. This implication is supported by statistics that cast serious doubt on the effectiveness of governmental inspections.

For example, in 2009, 2.2 governmental inspectors were responsible for 100,000 companies in Germany resulting in an average data protection audit every 39,400 years per company. 2 With regard to the increasing automated processing of personal data, by storing data sets in databases and making these accessible via the internet, such as in online social networks or in government-driven databases (e.g. central data storages of health cards), this issue poses a significant threat to information privacy.

Privacy can also be considered as an economic problem [START_REF] Varian | Economic Aspects of Personal Privacy[END_REF]. Thus, assuming that an economically driven company weighs the costs of losing PD (personal data) against the costs of implementing effective measures against data loss. Only an increase in the value and a reduction in the cost of effective data protection can help to improve this situation. Introducing adequate sanctions for not complying with the data protection laws is limited by the effectiveness of law enforcement (i.e. inspection). Hence, increasing the efficiency of compliance audits is a crucial task. Our solution propagates a system design supporting automatic compliance checks, offering companies a tool to maintain and prove their compliance.

Employing the design science paradigm [START_REF] Hevner | Design Science in Information Systems Research[END_REF] as research framework, this paper presents a schema for data protection supporting automated compliance control that transfers Dijkstra's concept of separation of concerns [START_REF] Dijkstra | On the role of scientific thought[END_REF] into the domain of data protection (data protection schema and implementation as primary artifacts). The approach has been successfully instantiated as a prototype for mobile health-care services, in which sensitive PD of patients, such as names, addresses, and medical information are processed.

In this paper, the considered scenario is settled in the eHealth domain of home care services. Figure 1a depicts a usual data flow for a home care service. Here, nurses transmit PD d to the storage service from which a nursing service is able to retrieve the data. The storage service has the following functions: receiving data with associated policies and storing both embedding data in answer documents and transmitting them to legitimate receivers. As there is no further computation, there is no need for the storage service to access any of the unencrypted PD. The storage service is composed of several complex sub-systems (e.g. load balancers, web servers, databases etc.) or could be a cloud storage database.

The problem addressed in this paper is that current auditing mechanisms for data protection (manual or automated) fail to achieve their goals for complex systems like the described storage service. There is a need for reducing the effort of compliance audits, without decreasing their coverage. This paper is structured as follows: Following the introduction, Section 2 presents the related work in the domain. Next, Section 3 depicts the developed system for supporting automated compliance control, whose implementation is presented in Section 4. Section 5 discusses the resulting system, including potential attack scenarios and its capabilities. Section 6 summarizes the findings and gives an outlook on future research opportunities.

Related Work

By employing automated compliance checks, e.g. by using compliance patterns [Gho007], necessary and verified business process models can be achieved [Lui07], which addresses the issue of compliance on the organizational level.

Compliance on the technical level can be achieved by two complementary approaches: by employing a-priori mechanisms that enforce the compliance of a system before or at runtime, or by posterior controlling that checks compliance after runtime. However, it can be argued that a-priori policy enforcement (e.g., usage control [START_REF] Park | The UCON ABC usage control model[END_REF] and compliance engineering [START_REF] Höhn | Rubacon: automated support for model-based compliance engineering ICSE 08[END_REF]) is too inflexible in some scenarios [START_REF] Povey | Optimistic security: a new access control paradigm[END_REF][START_REF] Etalle | A posteriori compliance control[END_REF]. Furthermore, posterior controlling is currently under heavy research (e.g. [CC07, [START_REF] Etalle | A posteriori compliance control[END_REF][START_REF] Accorsi | Automated Privacy Audits to Complement the Notion of Control for Identity Management[END_REF]). Approaches in this area have in common that log files of a system are used to create a formal model of the usage of PD. Afterwards, the model is used to check, whether the usage was legitimate in relation to a set policy. This approach can be combined with a rollback mechanism for the enforcement of data integrity [START_REF] Povey | Optimistic security: a new access control paradigm[END_REF].

While these approaches are well suited in theory, there are several drawbacks when applying them to real word systems: a) The reconstructed model is an abstraction of a complex system which might be inaccurate to a certain degree. This is due to, e.g., limited reconstruction capabilities or log inconsistencies. b) A model can only be considered complete, if logs from every component and every layer (i.e. OS, middleware, application, etc.) are used for reconstruction. Otherwise vulnerabilities in the system design or the implementation might lead to unspecified and unlogged behavior of the system. c) Furthermore, in order to ensure authentic logs, secure logging has to be employed on every single subsystem. Any of these drawbacks might render the result of an automated compliance check unusable, as there is no proof that the reconstruction reflects the actual processing of PD.

Applicable measuring points for compliance checks, regarding data protection, are points of enforcement of data access and transfer. Internal data processing is usually regulated by access control mechanisms [PS06] while data transfer is secured by security gateways [START_REF] Gruschka | WS-SecurityPolicy Decision and Enforcement for Web Service Firewalls[END_REF] and the application of layer firewalls [START_REF] Scott | Abstracting application-level web security[END_REF] and semantic firewalls [START_REF] Ashri | Towards a Semantic Web Security Infrastructure[END_REF].

All these approaches are similar in that they enforce security policies that must be compliant with the respective laws. Thus, even with a compliant policy an incompliant transmission might be allowed and will stay undetected if decision or enforcement of the policy fails. If a security system has complete and audit proof logging, they can be extended by compliance checks [START_REF] Uszok | Applying KAoS Services to Ensure Policy Compliance for Semantic Web Services Workflow Composition and Enactment[END_REF]. For retrieving data, these approaches are very similar to our approach. As innovation, our approach assumes that the provider of the sorting service is not a trusted party for storing data. Thus, personal data is protected by using encryption mechanisms against access by the provider of the storage service. Such features are not supported by current approaches.

inSel: An approach supporting automated compliance control

The essence of our work is the reduction of the number of components, which must be audited for a meaningful compliance check, and the creation of a trustworthy logging environment. This is achieved applying Dijkstra's concept of separation of concerns to separate security functions from data processing and storage functions. This is done by introducing our solution inSel (informational self-determination), implementing the security functions in a dedicated security gateway as a barrier for PD (cf. Figure 1b). inSel's purpose is that unencrypted PD text is held off from large parts of the system and access to it will be logged in a secure environment. The main benefit of using this approach is that compliance checks are reduced to checks of the proxy and its secure logs.

Compliance Control Schema

The schema underlying inSel uses three functions: identify which separates PD from other data, substitute which encrypts PD and leaves other data as it is and resubstitute which recovers the original form of PD. substitute and re-substitute are logging access to data. Limitations and applicability are discussed in Section 5.

When correctly applying the schema and adjusting identify, no unencrypted PD is passed to the storage service and every access to PD is logged. A compliance check therefore is reduced to a) a proof of the correct functioning of the proxy as well as b) a check of the respective access logs. Assuming that the correct functioning is correctly described in a model, proof a) is divided into two parts. The first part consists of checking that the schema has been employed this can be done for example by using a trusted computing platform [START_REF]Trusted Computing Group: TPM main specification[END_REF] and a certificate of a trusted third party (TTP), showing that the implementation matches the schema. This only has to be done once, as long as the schema and the employed software do not change. Secondly, the correct adjustment of identify must be proven. This is done manually by a TTP and has to be repeated for every transmission protocol used. b) can be proved by either using manual methods or automatic approaches mentioned in the related work section. Both approaches can be reduced to a check on the log files of the proxy as the proof of a) states that there is only encrypted PD in the background system.

Three use cases for compliance

To show the ability for supporting compliance control, three real world use cases were selected.

First, the most general and common case is the performance reliability. Purpose of this case is to prove normal operation and, in any case of potential data misuse, to provide evidence on data access and performed operations. To achieve this, there has to be a consistent and audit proof documentation of the data access by subject, object, time and purpose. For reasons of data protection, there has to be access control and consistent and audit proof access documentation.

The second use case is the inspection of commissioned data processing. In this case, the data is processed by a third party on behalf of the data controller. To take the German law as an example, the data controller (principal) has to inspect the data processor (agent) for divergence from normal operation. For the reason of data minimization these inspections have to be random (not consistently) but still on a regular basis. A good strategy for triggering the inspection is to do it from both the data controller's and the data processor's side. This minimizes the risk that one single party is able to prevent the inspection of specific operations. Again, a consistent and audit proof documentation of the data access including denied access requests by subject, object, time and purpose is required. Also, there has to be access control and a consistent and audit proof access documentation. For the reason of data minimization, the access should be limited to the documentation of the inspected operation(s).

The third use case is supporting the right of access. In Europe the right of access enables data subjects to get information about the processing of their personal data by the data controller. There are specific requirements, to support the right of access in an automated manner [START_REF] Herkenhoener | Towards Automated Processing of the Right of Access in Inter-Organizational Web Service Compositions[END_REF]. In particular, the legitimate interest has to be checked and the information has to be provided confidentially. Again, a consistent and audit proof documentation of the data access by subject, object, time and purpose is required. Also, there has to be access control and a consistent and audit proof access documentation. For privacy reasons, the access has to be limited to the documentation related to the processing of personal data of the data subject. In particular, personal data of a third person must not be disclosed.

The schema depicted in Section 3 is implemented by the inSel system, whose architecture is visualized in Figure 2. The system itself is comprised of the following three main components:

• The Secure Hypervisor, representing the basis of the architecture.

• The inSel Core, serving as the security gateway/proxy. Realizing the schema presented in Section 3 and containing the rights management and a user interface which is beyond the scope of this article. • The Secure Log, offering audit proof log facilities for the substitute and the re-substitute functions.

The inSel architecture

Operating as a security gateway/proxy, inSel represents the measuring point for compliance checks. This is based on a secure hypervisor, which is the architectural basis of inSel. It comprises of a TURAYA-based [EP10] security kernel and a TPM (Trusted Platform Module) as hardware-based security anchor for performing measurements of the system and the isolated virtual machines (VMs) for the inSel Core and Secure Log. This way, a complete information flow control can be realized. Furthermore, the functionality of the security gateway (inSel Core) and the logging and audit mechanisms (Secure Log) are logically separated.

For every storage and retrieval transaction going through the security gateway/proxy the logging mechanisms stores the following data: identifier of the data subject, identifier of the involved user, type of operation (i.e. storage or retrieval), transferred data types (e.g. name, address), the result of identify), a timestamp, and a session identifier (for linking log entries of the same user's session).

For compliance checks, authorized users can send requests to the Secure Audit-Log via the user interface, which only supports pre-defined use cases (e.g. inspection of suspected data misuse or controlling the storage service). This limits the possibility of misusing retrieved logging data and allows the audit of compliance checks itself.

Additionally, this can help to provide information to data subjects practicing their right of access by evaluating all transactions for a specific data subject's identifier. For privacy reasons, results of such evaluations should only be provided to the data subject and must not be visible to any other user. This is ensured by the access control mechanism in the compliance interface that will allow requests on information for a given data subject only to the data subject himself. Before transmitting PD to the storage service, the nurse must authenticate her/himself to inSel. The data is transmitted via HTTP over SSL/TLS in standardized XML documents that are created by the nurse's systems, which are assumed to be trustworthy. Transmitted documents are checked for validity against the Re-laxNG schema which is also provided by the nursing service and which is identified via the address of the request. If the document matches the schema, then PD is marked as such by identify (cf. figure 3). Hence, identify is implemented as a search on defined XML trees. Substitute then extracts the data subjects as well as the types of data (e.g. name, address, etc.) from the document according to the schema and encrypts PD and its type with the key of the data subject. After encryption the original PD is replaced by the cipher text and the subjects ID, which is extracted from the XML document. This procedure is repeated for all PD and a log entry is written into the Secure Log, containing data subjects and types. If writing the log is successful the document containing, the encrypted PD is passed to the storage system. These log entries form a protocol showing what data has been collected.

Application of the inSel schema

Again, before retrieving data from the storage system, the (employee of) nursing service must authenticate himself to inSel. If the nursing service is not allowed to access the requested URL, the request is discarded and a log entry is written stating the prohibited access. Otherwise inSel retrieves the requested document from the storage service. Relevant data is identified by re-substitute searching for a predefined pattern ("ID|Base64-string" in the example in figure 3). The matching string is removed and ID and PD are separated. Decrypted PD is inserted where the pattern has been found. After all PD has been processed a log entry is written. The entry contains time, data subject and type of PD accessed as well as an indicator of the success of the decryption. Again, if writing the log is successful the document is passed to the nursing service.

User Management

In order to manage the users of the inSel system, an integrated rights management component is provided, having the functionality to identify the users on the inSel system (authentication), managing their roles and access control permissions (administration) and to store and manage the encryption keys for the individual users. Configuration of the rights management component will be dedicated to the responsible data controller (in the given scenario to the nursing service). This is done exclusively and for a given instance of inSel in an irreversible manner. Neither the data processor (here the storage service), nor other data controller or the inSel provider himself have the permission to interfere.

Discussion

In a productive environment it needs to be assured that the inSel system's availability is guaranteed and that the system itself is capable of scaling to the actual needed demands. While the prototype implementation does not yet allow for scaling and availability mechanisms (e.g. replicating or synchronizing VMs), future extensions need to include appropriate mechanisms for load balancing and cross machine handling of VMs.

The configuration of the function identify is a vital part of our system. In its current implementation the system takes the RelaxNG schemas (stating which elements are valid) and the categorization of PD (which of the valid elements are PD) from the nursing service, which is assumed to be trustworthy. But there is no guarantee that the type of text elements' content matches its assumed type. Malfunctions or misconfigurations of the nursing services' systems might lead to unwanted disclosure of PD.

The configuration of the rights management is done via the user interface, which is designed under the principles of usable security. It allows data subjects to set access rights to their PD according to their preferences (within legal boundaries). Misconfiguration, leading to unwanted disclosures, is minimized by applying usable security. The rights management, though, is only capable of controlling access to data stored at the service provider and does not control the usage of PD after it has been transmitted to legitimate data consumers. Usage Control principles could be used at data consumers to counter this problem, which is beyond the scope of this paper.

Security Discussion

Our approach involves three parties: provider of the storage service, provider of the inSel system, and authorized service users (including data subjects and data consumers). Assuming that there are non-authorized externals, we have four parties to look at with regard to threads against the data subject's privacy. In the following outgoing threads of each of this parties will be discussed.

The provider of the storage service might get non-authorized insights into the stored data; in particular, he might do data mining to increase his knowledge on the data subject beyond the stored encrypted data. Since he stores the data, this is reasonable. In our approach, the personal data that is not required for the storage service is encrypted by the inSel service. This limits the insight into the actual stored data and thus, limits the gain of data mining. The provider of the inSel service might get non-authorized access by sniffing through-going traffic. In our approach, de-and encryption is done inside the inSel Core and incoming and outgoing connections are encrypted via HTTPS. Thus, direct access to the VM is required to gain knowledge of PD. The Trusted Server itself does not allow a direct access to the VMs, as this functionality is centrally deactivated on the system. The only access is via defined interfaces, allowing the remote management of VMs, but not the access to them. Thus, there is no feasible way to read data passing the inSel system.

It might be possible that an authorized user is getting non-authorized access. In our approach, we are using a strict regulation of access control to limit access to only authorized data. Further, the safe use of secure credentials like the new German electronic ID card is supported. Outgoing threads from non-authorized externals are counted by using a very restrictive design of the access points. The inSel service uses proven security mechanisms, such as HTTPS and XML-Encryption with AES, in order to protect and combine it with secure credentials and TPM-based virtual channels. In our approach, we introduced security mechanisms to increase the effort to get non-authorized access to the data outbalance the value of the data.

As any other security gateway, our approach is limited to the capability of current cryptographic algorithms and security protocols.

For supporting compliance checks, our approach comes with a secured and predefined interface. Access to the logging data is clearly controlled and regulated. Thus, it is resilient to data mining attacks and non-authorized access. The predefined interface also supports the principle of data avoidance. E.g. for the use case of the inspection of commissioned data processing the access is limited to the documented operations of a specific session ID and can only be done by specific authorized persons. The provided information is: timestamp, ID (linkable pseudonym) of the subject, message type (providing object and purpose of the access), provided data types (not the data itself), ID (linkable pseudonym) of the data subject. Anyhow, for every new compliance check the interface has to be extended. This may be a drawback for the maintainability and configurability of our approach. But it is reasonable that new compliance checks are not that often introduced, since the underlying regulations and laws do not change that often.

The possibility of existing side channel attacks resulting from the altered architecture or necessary network metadata has not been discussed properly in a systematic way and is topic for future work.

Conclusion

In this paper, we presented a schema called inSel that combines the abilities of a security gateway and an automated compliance checking system in a single system. By optimizing the solution for protecting personal data in storage services with multiple accessing parties, the complexity of data protection and compliance controlling could be reduced to a simplified but powerful gateway system. It allows the separation of security functions from data processing and storage functions. Using encryption to protect data from unauthorized usage, inSel operates as a gatekeeper for storing and retrieving data from the data storage. It combines strong access control mechanisms with consistent and audit proof logging. inSel itself is protected from external manipulation by using a TURAYA-based security kernel and a TPM (Trusted Platform Module) as hardware-based security anchor. Further, the access to the logging can be restricted to predefined and use-case related interfaces introducing robust and simplified semi-automated compliance checks. Based on the given scenario, three use cases for compliance control were implemented, proving inSel as a real-world solution.

While our approach clearly supports data subjects and controlling agencies, there are even benefits for companies complying with data protection laws as they are able to prove their compliance to e.g. independent certification authorities and thus obtaining certificates which in turn can be used as a selling argument or to gain customers' trust.

inSel is able to reduce the effort of the compliance check of a complex system by reducing the relevant components that have to be audited. Its applicability has been shown successfully by a prototypic implementation in the scenario of mobile time and service recording of nursing services. In this case, the processing system only stores and prepares personal data for retrieval, allowing for a higher efficiency when conducting compliance checks. For future uses, the system could be adapted and extended, so it can be used in other application domains, such as eMail or many eHealth applications.

Figure 1 :

 1 Figure 1: The scenario and the location of the solution inSel.

Figure 2 :

 2 Figure 2: Resulting architecture of inSel.

Figure 3 :

 3 Figure 3: Exemplified XML-Transformations implementing the inSel schema

See e.g. http://voices.washingtonpost.com/securityfix/2009/05/hackers_break_into_virginia_he.html (last visit:

25.01.2011) or http://www.wired.com/threatlevel/2009/11/healthnet/ (last visit: 25.01.2011) 2 http://www.xamit-leistungen.de/downloads/XamitDatenschutzbarometer2009.pdf (in German; last visit: 25.01.2011)

Acknowledgements

This work was part of the inSel-project "Informationelle Selbstbestimmung in Dienstnetzen", funded by the German Federal Ministry of Education and Research (BMBF) within the support code 01IS08016(A,B,C). The authors are responsible for the content of this article.