Marit Hansen
email: marit.hansen@privacyresearch.eu

Risk Analysis of Identity Management Approaches Employing Privacy Protection Goals -Position Paper

Keywords:

This position paper introduces the approach of privacy protection goals for risk analysis in identity management. It pleads for taking into account external factors such as the data collection via other applications or upcoming legal legislation.

Protection goals for information security and privacy

For decades, professionals in information technology have been working with the socalled classic triad of the protection goals "confidentiality", "integrity" and "availability" to assess security properties and risks of information systems. Since 2009, an extended set of protection goals has been proposed that also consider the privacy perspective, and thereby better reflect the interests of the individual whose personal data are being processed [START_REF] Rost | Datenschutz-Schutzziele -revisited[END_REF][START_REF] Hansen | Top 10 Mistakes in System Design from a Privacy Perspective and Privacy Protection Goals[END_REF]: In addition to the classic three security protection goals, three complementing privacy protection goals have been introduced:

• "unlinkability": Unlinkability ensures that privacy-relevant data cannot be linked across privacy domains or used for a different purpose than originally intended. Thereby it addresses both the legal principles of data minimization and purpose binding.

• "transparency": Transparency ensures that all privacy-relevant data processing including the legal, technical and organizational setting can be understood and reconstructed. Transparency is the precondition for all kind of user decision, e.g. for giving consent.

• "intervenability": Intervenability ensures that data subjects, operators and supervisory authorities can intervene in all privacy-relevant data processing. Its objective is the application of corrective measures and counterbalances where necessary. The data subject's rights to rectification or erasure are an example for intervenability.

Since beginning of 2012 the State Data Protection Act Schleswig-Holstein, Germany demands that data controllers take into account the three security protection goals as well as the three privacy protection goals (Art. 5 par. 1 LDSG S-H). They have also been taken up in the draft report of the European Parliament on the European Data Protection Regulation [START_REF] Albrecht | Draft Report on the proposal for a regulation of the European Parliament and of the Council on the protection of individual with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF].

Identity management and privacy protection goals

The six protection goals are not independent from each other. Working with protection goals means to identify how far each of the goals should be implemented and to find a suitable balance between those goals, taking into account the interests of all parties involved. Privacy-enhancing and user-controlled identity management has usually strong requirements concerning the protection of personal data against unwanted linkage across domains or contexts [START_REF] Zwingelberg | Privacy Protection Goals and Their Implication for eID Systems[END_REF]. However, unlike an anonymizing system that aims at full unlinkability, several interactions with the same communication partner should in many cases be linkable for the parties participating in the communication (not for potential observers) which has effect on the choice and (re-)use of pseudonyms. Transparency (beforehand and afterwards) is important for users to understand what the data processing is about, e.g. to enable them to select which attribute values to disclose. In case a relying party asks for information that is not appropriate for the given purpose, users must be able to intervene, i.e. to stop a transaction, to limit the disclosure or to send a complaint. Note that the protection goals are not only meaningful for designing information and communication technology systems, but can also be used to check organizational procedures or legal regulations.

Considering external factors, too

For analyzing risks concerning the desired level of guarantees per protection goal, the system scope should not be too narrow. For instance, even photos that have not been biometrically optimized such as in the ePassport pose the growing risk of being linked across domains and contexts because of the big collections via social networks or search engines and the available technologies of biometric matching. Another huge risk for all European identity management may be caused by the regulation on electronic identification and trust services for electronic transactions (eID Regulation) in case it is passed in the draft version that was presented by the European Commission in June 2012 [START_REF]European Commission: Proposal for a Regulation of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market[END_REF]. The proposed regulation aims at removing barriers in the internal market for electronic interactions. Each Member State may notify an electronic identification scheme that it accepts to access public online services. All Member States must accept the foreign notified schemes. The draft eID Regulation demands that each Member State sets up at least one national online authentication service for their notified eID schemes that is available for relying parties requesting to check the link to a user authenticating with the eID. This online authentication service is liable for the unambiguity of the link to a citizen. On the ground of "technology neutrality" Member States must not impose any specific technical requirements (e.g. obtaining hardware or software) on relying parties.

As elaborated in [START_REF]ABC4Trust: Privacy-ABCs and the eID Regulation[END_REF], such a regulation would likely lead to several risks to the user's privacy:

• The need for one always available online authentication service probably means that centralized services would be given preference.

• Liability for the unambiguity of the link between the eID and the citizen would prevent anonymous authentication.

• The liability also would make it necessary for the services to store logfiles on the individual transactions to prove that they did it right. These logfiles -containing the information of users and relying parties involved in cross-border authentication -would have to be retained for as long as authentication result may be challenged.

• eID systems that provide selective disclosure of attributes are not foreseen in the proposed regulation. Such systems would require that relying parties install at least some software which the draft regulation negates.

All in all, the protection goal unlinkability is severely violated by these risks. The other two privacy protection goals, transparency and intervenability, are less addressed in the draft regulation and depend on the implementation. However, in particular the part on liability would have to be clarified concerning transparency and intervenability. It is necessary to amend the eID Regulation so that privacy-enhancing identity management solutions can be used or are even made mandatory for crossborder authentication. Best practice approaches can help to stop a race to the bottom concerning the level of implemented privacy.


Sanna Suoranta

Asko Tontti

Joonas Ruuskanen

Tuomas Aura

Logout in Single Sign-on Systems

Keywords: Single Logout, Logout in Single Sign-On Systems, Shibboleth

diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Nowadays both at work and in leisure time people are using many services that have a web browser as the user interface and platform instead of stand-alone applications. Often the services require the user to authenticate in order to provide personalized service, to access to the user's private information or to verify the user's real-world identity. Usually user authentication is based on passwords, but many users choose poor passwords [START_REF] Florêncio | A largescale study of web password habits[END_REF] or share the same password between unrelated services [START_REF] Gaw | Password management strategies for online accounts[END_REF]. These issues weaken the authentication.

The single sign-on (SSO) systems help users to access several services using a single password; thus, the user does not need to remember service specific passwords. In a federated SSO, the user authentication is separated from the service to be handled on a separate Identity Provider (IdP). Two common systems are OpenID [START_REF]Openid authentication 2.0 -final[END_REF] and Shibboleth [START_REF]Shibboleth[END_REF], which is based on SAML [START_REF] Ragouzis | Security assertion markup language (saml) v2.0 technical overview[END_REF]. These are mainly used locally or for specific online services. No dominant world-wide SSO system exists as the service providers do not want to outsource their user management [START_REF] Dhamija | The seven flaws of identity management, usability and security challenges[END_REF]. The SSO technologies are an active field of researc and development. Impovements have been proposed to the architecture [START_REF] Cahill | Client-based authentication technology: User-centric authentication using secure containers[END_REF][START_REF] Chadwick | Leveraging social networks to gain access to organisational resources[END_REF][START_REF] Sun | Openidemail enabled browser: Towards fixing the broken web single sign-on triangle[END_REF][START_REF] Takeda | Avoidance of performance bottlenecks caused by http redirect in identity management protocols[END_REF], authentication strength [START_REF] Mustafic | Behavioral biometrics for persistent single sign-on[END_REF][START_REF] Suoranta | Strong authentication with mobile phone[END_REF] , usability [START_REF] Linden | An empirical study on the usability of logout in a single sign-on system[END_REF][START_REF] Sun | Openidenabled browser: Towards usable and secure web single sign-on[END_REF][START_REF] Sun | What makes users refuce web signle sign-on? an empirical investigation of openid[END_REF], and privacy [START_REF] Alsaleh | Enhancing consumer privacy in the liberty alliance identity federation and web servies frameworks[END_REF]. On the other hand, less attention has been paid to the termination of the authentication sessions, even though it is a critical part of the authentication process.

SSO systems are common in universities where, in addition to the university itself, also external organizations can offer web-based services for students and staff. For example in Finland, the universities have a common library service that provides access to online electronic publications using Shibboleth for authentication. The university students often use shared computers; thus the proper logout from the services is very important so that the next person using the computer cannot gain access to the services using the first one's privileges.

In this article, we have investigated the logout and its implementation in services that use the Shibboleth SSO. We found many problems in the logout procedures: none of the services implements single logout, and usually at least some server side sessions are still active after logout. Based on our findings, we give a list of actions that help in implementing more secure and usable logout for Shibboleth. Some of the solutions are general and could be used to improve also other SSO systems.

The rest of the paper is organized as follows. Next, we discuss single sign-on systems in general, and OpenID and Shibboleth in detail. In Section 3, we go through how logout works in SSO systems in theory, and in Section 4 how it works in practice in the web services of Aalto University. Then we discuss the solutions for logging out in the SSO systems. In Section 6, we describe what the other researchers have done. Then we list the improvements that should be implemented and, finally, conclude the article in Section 7.

Single Sign-on

Single sign-on systems allow users to log in to several services with one authentication. The SSO systems can be divided into four categories: local and proxy-based, pseudo and true SSO systems [START_REF] Pashalidis | A taxonomy of single sign-on systems[END_REF]. In the local pseudo-SSO system, a user's device has a password manager that automatically works on behalf of the user when she is logging into a service. The proxy-based pseudo-SSO system is similar, but the password manager is located on a network proxy. The local true SSO system rely on trusted component on the client device, but otherwise is quite similar to the local pseudo-SSO. The proxybased true SSO system has an external server for authenticating the user for services. In this article, we concentrate on proxy-based true SSO systems, often called federated SSO. For example, OpenIDand Shibbolethare proxy-based true SSO systems. In addition, many service providers allow other web service developers to use their user authentication with their proprietary protocols. For example, Facebook Login [START_REF] Facebook | Getting started with Facebook login[END_REF] and Microsoft's Windows Live ID [START_REF]Windows live id web authentication sdk[END_REF] provide centralized authentication for third party web applications where users can log in using their existing identities at Facebook and Microsoft's services.

Both OpenID and Shibboleth separate the user authentication from the actual service. Figure 1 depicts the general architecture of a federated SSO system. When a user wants to use a service, she first starts her web browser and connects to the service that is running on a server of a Service Provider (SP). A SP can have several services on the server, and some of them can take care of their own session management but often the SP saves the session information on behalf of the service. The SP responds to the unauthenticated user by redirecting the browser to an Identity Provider (IdP), or if there are several IdPs, the user can choose to which one the connection is redirected. The IdP authenticates the user, creates a SSO session for her, and redirects the user's web browser back to the SP with authentication assertions. Then, the SP saves the session Fig. 1: Architecture of a federated SSO system information and gives the originally requested access to the user. If the user wants to use another service with the same authenticated identity, the IdP does not need to reauthenticate her. It only checks that the valid SSO session exists, and then it gives the authentication assertions directly to the second SP. However, the IdP does not keep track to which SPs the user has been authenticated. Next, we describe shortly the differences of OpenID and Shibboleth.

OpenID

OpenID allows user to choose any identity provider she wants. There are plenty of OpenID identity providers [START_REF]Openid providers[END_REF] but only a few services that accept other than their own IdP.OpenID does not require pre-established trust between SP and IdP [START_REF] Sun | A billion keys, but few locks: the crisis of web single sign-on[END_REF], and that might be one reason why it has not gained worldwide acceptance as a service authentication solution even though many services use it for access control with their own IdP. Moreover, popular OpenID identity providers such as Google do not verify the user's identity in the registration phase, only that the user has a valid email address [START_REF] Chadwick | Leveraging social networks to gain access to organisational resources[END_REF]. However, strong user authentication is possible, e.g. in Estonia, a mobile phone operator acts as an IdP that provides strong verified authentication [START_REF] Ideelabor | Openid in Estonia[END_REF].

Shibboleth

Whereas OpenID requires no prior trust relationship between IdP and SP, Shibboleth participants need to trust each other. However, the IdPs and SPs do not need to belong to a same organization, they just need to share common metadata declaring the trusted IdPs and what attributes each service needs. IdP and SP communicate using SAMLmessages through user's browser using HTTP redirect and post command. Authentication and service sessions are stored in cookies on the cliend side.

In Finland, all the universities have joined to a federation called HAKA [START_REF]Haka federation[END_REF] that handles federated identity management. The universities have their own IdPs and a separate organization, namely CSC that provides high performance computing facilities and Internet access to universities, manages the federation and its metadata on behalf of the universities. The HAKA federation and its services have worked well for reducing the number of necessary passwords. Furthermore, the federation has joined together with the other Nordic federations providing access to research resources over the borders in the Nordic countries [START_REF] Kalmar2 | Kalmar2 -access to nordic higher education with single login[END_REF]. We have chosen to investigate how the services using the Shibboleth SSO manages the logout.

Implementing the Shibboleth SSO

Shibboleth Consortium [START_REF]Shibboleth[END_REF] offers open source implementations for selected SAML2 profiles as Shibboleth IdP and SP. Their Shibboleth IdP is a Java based server that works on top of Tomcat [START_REF]Apache Tomcat[END_REF] Java Servlet platform. It offers several ways to authenticate the users: e.g. username and password query, remote user, and previous session. The first and second methods are for initial phase user authentication and the third allows the actual single sign-on after the user's identity has once been verified. The first asks username and password from the user and checks that they are correct using Java Authentication and Authorization Service (JAAS) interface to connect to a LDAP directory (this method is used in Aalto University's IdP) or Kerberos server. The second method uses a web server, such as Apache, to authenticate the user instead of the IdP program. The third method uses authentication cookies that are stored in the web browser after previously and successfully done user authentication. This allows user to log in to several services with single authentication.

The Shibboleth SP is usually connected to web server as additional module or filter. The web server can be e.g. Apache or Microsoft ISS. The web server mediates the authentication information to the web service application that offers the actual service for the user. The web server and SP pair can host several service applications. There are two basic ways for the service to use Shibboleth for authentication. The service taking care of its own user information management during the session can use Shibboleth for user authentication. The other way is that the service outsources all user session management to the SP.

Logout in SSO Systems

Logging out means clearing the sessions that are created when the user is signed in. In a traditional web service, the user session is usually terminated either when the user explicitly presses logout button or when the service timeout is reached. In the SSO systems, logging out is not so straightforward. The user might want to log out either from a single service or from the whole SSO session. From the SSO point of view, there are even more forms of logout, e.g. Shibboleth and SAML have the following:

-Logout in the service application. If the application takes care of its own user session management, it terminates the user sessions but the SP session needs to be terminated separately. If the SP takes care of the user session management on behalf of the service, the service need to register a handler in SP for logout. -Logout in SP. If SP takes care of all user session management, it offers an API to the services to start the logout in SP. In logout, the SP removes the sessions. In an IdP initiated logout process, the SP removes its sessions and asks the application to end its sessions, too, if necessary. -Logout in IdP. The IdP takes care of the SSO session during which the user can log in to services without re-authentication. If logging into other services is not preferred, the IdP session can be removed. Removing the IdP session does not affect the session any way on the SP and the services. -Local logout. If the user wants to log out from a single service, she uses the local logout that closes both the service and SP sessions related to that service but not the IdP session, nor sessions of other services and SPs. -Single logout (SLO) or Global Logout. If the user wants to log out from all the services, she chooses the single logout. In addition to the currently used service and SP, the IdP goes through all SPs and asks them to log out the user, and ends its own session (IdP initiated logout). -Partial logout. When the service does not work correctly in logout, the result is a often partial logout. Then some of the user's sessions, typically either in the service or in the SP, remains active. The only way to recover from this situation is to close the web browser.

In the SSO systems, the session should end either to local logout or single logout. In practice, the latter is often local logout combined to the IdP logout, not a real SLO. Usability studies [START_REF] Linden | An empirical study on the usability of logout in a single sign-on system[END_REF][START_REF] Sun | What makes users refuce web signle sign-on? an empirical investigation of openid[END_REF] has shown that when using a SSO system, the users expect also single logout. Correctly implemented SLO is extremely important when shared computers are used e.g. by students in a university library. However, many users have personal computers, thus a local logout from a single service might often be more practical, e.g. when the user will log in to another service with the same IdP after logging out from the first service. If also the IdP session has been terminated, the benefits of using the SSO system are overturn since the user has to sign in again every time.

Next we go through how SLO works in different SSO systems and federations.

SAML2 Logout

OASIS, the standardization organization behind SAML, took into account the lessons of another federated identity management system, namely Liberty Identity Federation Framework (ID-FF), while developing SAML2. Liberty ID-FF and Web Service Framework (WSF) allow service providers to communicate directly with identity provider through back channel, which allows SLO in Liberty [START_REF] Alsaleh | Enhancing consumer privacy in the liberty alliance identity federation and web servies frameworks[END_REF]. SAML2 only describes the logout in general and different profiles complete it with conflicting suggestions. For example, the order of removing the sessions on SP and IdP is not clear. Following describes the SAML2 logout with front channel binding that uses web browser to communicate with different actors.

1. The user chooses logout in a web service.

2. The service removes the user's session. 3. The service redirects the web browser to the SP's logout handler. It can set a return parameter if the browser should be redirected to an URL after successful logout. 4. The SP removes the user's SP session. 5. The SP searches the IdP's logout service address from the metadata and redirects the web browser to it with the SAML2 LogoutRequest message. 6. The IdP removes the user's SSO session (PreviousSession) 7. If necessary, the IdP asks an external authentication service to remove its session. 8. The IdP sends the SAML2 LogoutRequest messages through the web browser to all the SPs except that which started the logout. Each SP removes its sessions and asks the services to remove the sessions, too. All the SPs send messages about success of the logout to the IdP through the web browser. 9. The IdP sends information about the success of the logout through the web browser using the SAML2 LogoutResponce message to the SP that started the process. 10. Finally, the SP can either tell the user that logout has been proceeded successfully or even redirect the user to the URL given in step 3.

The SAML2 logout provides SLO but requires the IdP to keep track of all the SPs that the user has logged in, which requires more resources. Moreover, if the user has logged in using different IdPs, only the services using the same IdP will be logged out.

HAKA Federation Logout

Since the first version of Shibboleth does not provide any logout, the HAKA federation developed its own logout for Shibboleth SSO used in Finnish universities. The result is usually only partial logout where the service and SP sessions remains open in the other SPs than the one starting the process. The beginning of the HAKA logout works as the SAML2 logout in the steps 1-7, and the rest as follows [START_REF]Haka Logout[END_REF].

8. The web browser returns to the URL if SP askedit while it called the IdP. 9. The browser tells the user that she is logged out from the service and the IdP. 10. User is encouraged to close the web browser to be sure that logout has been completed. The purpose is to prevent using the session from other SPs than that started the logout.

However, even though the user would close the web browser, other SPs and their service sessions remain open until timeout. If an attacker finds out the session identifier, he can use them for a while. Shibboleth SP 2 supports SAML2 logout but the IdP 2 does not. Future IdP 3 will probably have a back-channel-based SLO where the messages are passed using SOAP.

OpenID Logout

OpenID does not provide single logout although IdPs can provide a logout URL for the service providers. For example, Google staff in the developer discussion forum suggests that the service developer should either provide logout only from the service or redirect the browser to Google's logout URL [START_REF] Balfanz | Sign-out from Google federated login api[END_REF]. However, the service should know which IdP the user has used to log in to the service in order to provide the correct logout URL. This is hard because there is no pre-established connection between the SP and IdP. Furthermore, OpenID IdP does not keep track of the services the user has logged in.

Logout in Practice

We went through commonly used services of the HAKA federation to find out why they behave differently when a user logs out from the service. Almost all possible logout forms listed in Section 3 were found. In this section, we present the results of our tests.

Only Service Session Removed

Half of the Finnish universities use Oodi 3 to record all course grades, and for students, to sign in for courses and exams. The front-page of the service reminds the users to exit from all browser windows when logging out to prevent the next user to gain access to the first user's information. The warning is needed since when the user logs out, only service's local session is terminated and both the IdP and SP sessions remain. The service returns to the service front-page and gives no information about logout status.

In the Oodi login process, two sessions are created: a SP session with eight hours timeout and a local Tomcat session with 30 minutes timeout. The Oodi service copies all information from the SP's session to a session presented by JSESSIONID cookie. When the user logs out from the service, only the Oodi service's own session cookie is removed but the SP session still remains, let alone the IdP session. Same way, when the local session reaches timeout, the service does not inform the SP about the logout. This means that the user can get directly back in to Oodi without re-authentication because the SP session is still valid.

In this case, the biggest security problem is that the user cannot get out from the service at all if she does not close the web browser. The service does not tell to the user about still valid sessions. Even if she closes the web browser, both the SP and IdP SSO sessions remain open until timeout. The problem is Shibboleth specific since the session management is divided between the SP and the service application.

SP Session Removed but Service Session Exists

The libraries of Finnish universities have a joint service called the Nelli4 portal for scientific articles and databases. When the user logs out from the service, the connection is redirected to IdP. The IdP tells the user has logged out from the SSO session and that there might still be active sessions, and only closing the browser will end them. Indeed, there still is an active session, because if the user immediately returns to the Nelli portal and press the login button, she gets in without re-authentication. However, she does not get in to new services since the IdP session has actually been removed.

The Nelli portal is implemented using MetaLib program that uses Patron Directory Services (PDS) for authentication [START_REF] Pennanen | Wiki nelli metalib[END_REF]. When the user logs in to the Nelli portal, the service checks first a PDS HANDLE cookie. If it exists, its information is copied to the main session. Otherwise the service asks the user information from the SP. Nelli creates also a local session key that is stored in a ML SESSION ID (MetaLib Session ID) cookie and included in all page URLs. If this cookie does not exist, it is always created, thus removing it does not affect anything. Removing the key from the URL does not affect either, if the ML SESSION ID cookie exists. The Nelli service session does not end until the user navigates to other pages for more than 10 minutes or press the logout button. In addition to service specific cookies, SP removes its session but because the IdP session is still valid, the next user can get in without authentication. Removing first the SP session eliminates the possibility to logout from the IdP because the necessary information was stored in the SP cookie.

When the user logs out from the Nelli portal, the service does not remove the PDS HANDLE cookie but the SP session is already ended. The problem in this case is that the service session remains open. Thus the user can get in without the service checking from either IdP or SP if their sessions are still valid.

In a way, the logout from the Nelli portal does not work at all. Different sessions are active, even though the user think that they have been ended. The problem is Shibboleth specific but session timeout can be problem in other SSO systems, too.

Local Logout

The Aalto University Wiki5 tries to execute local logout. When the user logs out from the wiki, the connection is returned to login page of the wiki service. Only one line of text "You have been successfully logged out. Return to wiki.aalto.fi or login again" separates the page from the original login page that offers several possibilities to log in. The user may not notice the text at all.

Actually the Wiki service tries to execute SAML2 logout instead of HAKA logout since it asks the SP to redirect the connection to its own logout pages and not to IdP. Because the current IdP does not handle SAML2 logout, the SP removes only its session and rest of the session removals fail.

The problem is that the user is not informed from which session she has logged out, and that this was due to compatibility problems. If the user closes the web browser, the IdP SSO session and possible other SP sessions remain open until timeout. If the user does not close the web browser, the next user can get in to all services using the same IdP SSO session, even to the wiki. The problem is generic in the SSO systems.

Local logout together with IdP Logout

All the course webpages and announcements are in the Noppa6 portal that was developed at Aalto University and later brought into use in two other universities. When the user signs in the portal, both the SP and Noppa's local Tomcat sessions are created.

All user information is copied to session identified by either JSESSIONID cookie or org.apache.tapestry.locale cookie. The SP session is valid for eight hours, but if it is unused, it expires in one hour. The Noppa portal offers only the local logout together with the IdP logout for the user.

The user can continue using other services even though the IdP session has ended because the IdP does not have means to inform the other services to end their sessions. Thus, the real SLO is not executed. If the user closes the web browser while other services are still active, their SP and service sessions remain active until timeout. The problem is generic in the SSO systems and may confuse users that cannot separate the real SLO from logging out from the IdP.

Choosing between Local and IdP Logout

One obsolete service offered to a user a possibility to choose between the local and IdP logout, which was implemented as the HAKA logout from both the SP and IdP. When the user logged into the service, the SP copied the essential user information into long hash and gave it to the service as part of the URL. The service removed the string from the URL and created a cookie with the same name. When the user logged out, the session information was removed from the server memory.

It seems that the logout implementation has been left for the service developers to choose. Moreover, many of the services do not actually provide correct logout, they just end some of the sessions. Furthermore, it is up to the user's enlightment, can she distinguish the local logout from the IdP logout when getting out from different services. The problem is generic since the users do not always know where they want to log out and offering choices may be too complicate for them.

Solutions for Logout in the Federated SSO Systems

In centralized SSO systems, an IdP keeps track to which SPs the user has been authenticated, and communicates to all SPs about logout through a backend channel, thus the single logout is possible. Federated SSO systems do not usually use backend channel for communication and an IdP does not know about active sessions on SPs.

There are several steps that make the logout in the federated SSO systems more secure. At least, the user should be able to logout from the service she is using but also ending the SSO session in the IdP is necessary, if chosen. To provide true single logout, the whole federated SSO needs modifications.

Modifications in Services

When a service is added to the federated identity management, it has to be modified. The developers should decide if the service keeps a session itself or does it use the session provided by SP. If the SP takes care of the sessions, the service just need buttons for the local and IdP logout. Pressing these buttons can start the logout procedures with proper attributes in the SP, and the SP takes care of everything.

If the service takes care of the logout, the procedure is quite the same as above but changes are needed. The service has to remove its own session before calling the logout method of the SP. Equally important is to have a handler to the IdP initiated logout. For this, the service should register a single logout handler for the SP. When a SLO request arrives, the service has to remove all sessions. The request can come through the web browser or using a SOAP interface. In the latter, it is not possible to remove the cookies from the browser, but the service has to remove the session from its own memory. Finally, the lifetime of service session should be shorter than the lifetime of SP session or otherwise the incoming logout requests do not work correctly.

Cookie Management in Web Browsers

Handling of the cookies has not changed much during the recent years. To mitigate problems caused by attacks, there are rules how cookies should be handled. These rules prevent the IdP and SP from seeing each other's cookies.

For making single logout possible, the rules should be changed. For example, the IdP could create a collection of cookies connected to the SSO session. The SPs could add their own cookies to the collection. Then as a creator of this collection, the IdP could remove cookies and set the deletion rights to all servers of the federation. In the single logout, the IdP could remove all the SP cookies that are left over. However, this change may cause unexpected security weaknesses if not done with extra care.

Connections between the IdPs and SPs

Single logout changes the actions of the IdP and SP. For example in the original Shibboleth, the IdP takes only care about the validity of SSO sessions and the SP has the necessary user attributes in its memory. The IdPs and SPs could have been rebooted since all necessary state information has been stored in the cookies on the user's web browser and the other information could have been fetched again. For single logout, the IdP has to store information about all SPs where the user is logged in. This would change a lot of the use and importance of IdP's SSO session.

Another way to do automatic logout is based on AJAX. The web browser could send keep alive messages to the SPs and IdP when the user has an open window for a service. When the user navigates to some other web page than that of the service, the browser simply stop sending these messages to the SP that can then end the user's session. This way the sessions will not be "left behind". Moreover, when the user has moved out from all the services of the federation, the web browser stops sending the keep alive messages to the IdP, too. Then the IdP can remove the SSO session and, to make single logout absolutely sure, start the IdP initiated logout fom all SPs. However, there are two problems: This approach burdens the IdP and SP with additional messages, and it does not work if JavaScript is turned off or the web browser does not support it.

On the other hand, single logout is possible to implement using a polling mechanism. When a user chooses single logout in a service, the service would execute both local and IdP logout, thus ending both its local session on the SP and service, and the SSO session on the IdP. The other SPs would notice that the SSO session is no longer valid because they ask periodically its existence using e.g. a SOAP interface of the IdP.

Then, they too could execute the local logout, and all the sessions would end through true single logout. Of course, the interval of the queries should not burden the IdP. The downside is that with this addition Shibboleth would not be SAML2 compliant software.

Clear User Interface

It is hard for a user to separate a local and single logout and understand their differences when some services of the federation provide the first and some the latter. It would be nice if the user could see on a page the services where the authentication sessions that are still valid. Technically and from the user interface point of view this is hard.

Especially important for the user is to know that global single logout has really removed all the session information from all the services. Closing the web browser ends the sessions in the client side and solves the problem almost satisfactorily. However, the sessions on the server side remains until timeout but they cannot be used without knowing the session key. Another problem rises if the user has also other web browser windows and tabs open, and does not want to close them, just log out from one of the services. At least the web browsers should be improved to really allow to end the sessions without closing the whole browser.

For example, the WebApp of Microsoft Outlook asks from the user before login if the user has a private computer or if she is using a public computer. This affects how long timeout is used for the session when the user is inactive. In the same way, the login of a service could give two possibilities that finally lead to either local or single logout.

Related work

Logout in SSO systems is not widely researched topic. Often it is only mentioned when some other aspects of the SSO systems are improved. For example, Sun et al. [START_REF] Sun | What makes users refuce web signle sign-on? an empirical investigation of openid[END_REF] investigated usability of OpenID system because a single sign-on system may confuse users when it redirects the user from a service to an identity provider for logging in. They found out that despite of many passwords, users are still reluctant to use SSO, e.g. for critical services because they do not understand how it works. They implemented a system [START_REF] Sun | Openidenabled browser: Towards usable and secure web single sign-on[END_REF][START_REF] Sun | What makes users refuce web signle sign-on? an empirical investigation of openid[END_REF] that integrates OpenID login into a web browser and they tested the usability of their system with a small group of users. They list single logout as one important requirement in their system but do not describe its features nor its usability, they only state that it must automatically end all authentication sessions. However, based on the screenshots of their solution, it seems to offer users two possibilities: either single logout or logout only from the current service. In their other article [START_REF] Sun | Openidemail enabled browser: Towards fixing the broken web single sign-on triangle[END_REF], the login process of their system is elaborated in more detail but handling the logout process is not described at all. Cahill et al. [START_REF] Cahill | Client-based authentication technology: User-centric authentication using secure containers[END_REF] have created a client-based authentication system that has a trusted hardware-based secure container for user credentials in the user's device. The system allows both active and passive authentication. The latter means e.g. facial recognition using the device's camera or RFID badge that is near the device. Thus, service providers do not need to implement timeout for their service sessions, but also SAML-based SLO is implemented. The system requires much from the hardware and the user is bound to use one device. Mustafic et al. [START_REF] Mustafic | Behavioral biometrics for persistent single sign-on[END_REF] describe similar system that combines SSO with continuous behavioral biometric-based authentication. Their system uses keystroke dynamics as proof that the user is still the same as that authenticated in the beginning of the session. If the system notices that the user has changed, it starts the SAML SLO. However, this only works for services that require typing.

Linden et al. [START_REF] Linden | An empirical study on the usability of logout in a single sign-on system[END_REF] present a usability study on logout in a SSO system among students and personnel of a university. They found out that especially students expect also single logout when using single sign-on. On the other hand, the personnel stated that their sessions in the university services have no clear beginning or end. More important for the users was that they knew if they were authenticated or if they were anonymous, all the time while they used the services. When Linden et al. did their study, the SSO systems were new and many universities implemented the student services as integrated web portals. This may explain some of the misunderstandings that single sign-on means also single logout.

Conclusions

In order to create reliable logout for the federated SSO systems, standardization organizations, web browser vendors, and service developers should consider also the termination of the sessions. For example, thorough testing of logout behaviour could improve the current situation. Moreover, the following changes would make logout better:

-unified and standardized process for ending the sessions, -improving the cookie management in browsers, -creating a mechanism to check the existence of an IdP session, and -unified user interface for logout.

The unified process for removing the session cookies and managing their timeout periods would prevent the current problems of logout. The SAML single logout is too complex and contradictory to work properly. For example, the order of the session removal is not clear. The standardization should redefine the single logout process because the currently used federation specific definitions are not sufficient, as is shown in Section 4. Examples could also be provided for service developers on how the session management should be handled.

The cookie management improvements consist of two things: ending the sessions without closing the web browser by removing the cookies, and allowing the IdP to remove the SP cookies. The former depends on features in web browsers and requires support from browser vendors. The latter could be taken into account in standardization of HTML 5, for example. However, the current model of session management with cookies is not likely to change. Moreover, if the IdP keeps track of all SPs to which the user has logged in, there are implications to user privacy.

Another possibility for checking the existence of the IdP session is to create a polling mechanism for SPs. If the SP polls the IdP, the IdP does not need to keep track of the SPs to which the user has logged in. Since the user is not bound to use only a single IdP, the SP may need to poll all the IdPs that the users have chosen. Of course, the polling frequence must be reasonable and not burden the IdP and SPs.

The unified user interface means that a federation or the SSO system standardization should define from the user's point of view how the services should end the sessions. Because the user can work either with public or private computers, two options should be provided by all services: single logout that ends both the IdP and all service and SP sessions, and local logout that leaves the IdP session active. Also, all services should inform the user from where she has logged out.

The process of ending the authenticated sessions has not gained the attention it deserves. We tested many services that use Shibboleth as a SSO system and almost all had problems with logout. Because some of the session information remains when the service ends in partial logout instead of local logout, the next user of a shared computer can access the service with the previous user's account. Where the single logout is suggested in the user interface, it often does not work as expected. Even though the IdP removes the SSO session, the service and SP sessions remain active. Often services rely on closing the web browser but even then the server side sessions remain until timeout. Small changes such as unified logout process and user interface would allow the services to provide at least local logout instead of partial logout. For true single logout, the federated SSO systems require modifications to the standards for cookie handling and federation practices such as a polling mechanism for checking the IdP sessions.

E.g. https://oodi.aalto.fi

http://www.nelliportaali.fi

https://wiki.aalto.fi/dashboard.action

https://noppa.aalto.fi/noppa/app

Acknowledgments

We whish to thank Aapo Kalliola and Jaakko Kotimäki for valuable comments.


Marit Hansen
email: marit.hansen@privacyresearch.eu

Data Protection by Default in Identity-Related Applications

Keywords: Data Protection by Default, Privacy by Default, Privacy by Design, Security by Default, Identity, Identity Management

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

For several years, data protection authorities and other privacy advocates have been demanding "privacy by default", often in combination with "privacy by design" for conceptualizing, developing and operating ICT systems that are used to process personal data [START_REF]32nd International Conference of Data Protection and Privacy Commissioners: Privacy by Design Resolution[END_REF]. The general idea of "privacy by design" is to design technologies and business practices right from the beginning according to privacy criteria, thereby implementing important privacy guarantees and features in ICT systems and processes. "Privacy by default" addresses on the one hand that "privacy by design" should be a matter of course in ICT development and operation. On the other hand it defines the goal for a privacy-friendly standard configuration so that the usage of the ICT system does not infringe people's privacy. However, the exact interpretation of "privacy by default" is being debated. The proposed European Data Protection Regulation [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF] has taken up the principles of "privacy by design" and "privacy by default". Since the legal text focuses on "data protection" rather than "privacy" -entirely in the tradition of the European data protection framework in force -, it consequently has incorporated the principles under the names "data protection by design" and "data protection by default". Even without statutory "data protection by design and by default" on the European level, in some European Member States national data protection law took up these principles at least partially, e.g. in the German telemedia law and the data protection law. In addition, they became criteria of the Schleswig-Holstein Privacy Seal [START_REF] Hansen | Datenschutzgütesiegel aus technischer Sicht: Bewertungskriterien des schleswig-holsteinischen Datenschutzgütesiegels[END_REF] and the European Privacy Seal [4]. Standard settings are clearly relevant when assessing privacy properties of ICT products and services, because they will decide on the effort for users to apply the appropriate configuration for a privacy-compliant use. This is both relevant for users on behalf of an organization -they have to consider the legal requirements when processing personal data -and for end-users for their personal purposes, e.g., when joining a social network. The importance of defaults in ICT design has been explored by various researchers (e.g. [START_REF] Nielsen | The Power of Defaults. Jakob Nielsen's Alertbox[END_REF] and [START_REF] Kesan | Setting Software Defaults: Perspectives from Law[END_REF]): They conclude that many users stick with the preconfigured settings which might put them unexpectedly at risk.

Not only European data protection authorities, but also the consumer organization BEUC regarded "privacy and security by design" and "privacy and security by default" as important principles that could be already derived from current law [START_REF]EU General Data Protection Framework -BEUC answer to the consultation[END_REF], in particular from Art. 17 of the European Data Protection Directive [START_REF]Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and[END_REF] that demands "appropriate technical and organisational measures" to protect personal data.

In this paper, we focus on "data protection/privacy by default". The following section describes how "data protection by default" is regarded in the proposed European Data Protection Regulation and what other definitions are being discussed. Section 3 presents general considerations for applying "data protection by default" in practice. In Section 4, recommendations for default settings are shown for three identity-related application scenarios. Section 5 summarizes the findings and gives an outlook.

2

Towards a definition of "data protection by default"

Starting point of this paper is the proposal for a European Data Protection Regulation [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF]. In Art. 23 para. 2, "data protection by default" is introduced: "The controller shall implement mechanisms for ensuring that, by default, only those personal data are processed which are necessary for each specific purpose of the processing and are especially not collected or retained beyond the minimum necessary for those purposes, both in terms of the amount of the data and the time of their storage. In particular, those mechanisms shall ensure that by default personal data are not made accessible to an indefinite number of individuals." [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF] This should be read together with recital 61: "(61) The protection of the rights and freedoms of data subjects with regard to the processing of personal data require that appropriate technical and organisational measures are taken, both at the time of the design of the processing and at the time of the processing itself, to ensure that the requirements of this Regulation are met. In order to ensure and demonstrate compliance with this Regulation, the controller should adopt internal policies and implement appropriate measures, which meet in particular the principles of data protection by design and data protection by default." [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF] Firstly, it is noteworthy that rather than ICT developers this provision addresses the controller only, i.e., the entity that "determines the purposes, conditions and means of the processing of personal data" (Art. 4 para. 5 of the proposed Regulation [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF]). Nevertheless, the preconfigured settings are often determined by the ICT developers. Of course, there might be an indirect effect on ICT developers if controllers demand "data protection by default" [START_REF]Opinion of the European Data Protection Supervisor on the data protection reform package[END_REF]. However, it would be more appropriate to define an obligation for data controllers, data processors and producers of data processing systems as proposed in the Draft Report of the European Parliament [START_REF] Albrecht | Draft Report on the proposal for a regulation of the European Parliament and of the Council on the protection of individual with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF].

Secondly, the meaning of "data protection by default" is not clear. The last sentence of Art. 23 para. 2 on accessibility "to an indefinite number of individuals" points to social network sites and other Internet services. Apart from that, the meaning seems to be reduced to the necessity principle (see also Art. 5 (c) of the proposed Regulation [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF]): processing of personal data is only allowed if and as long the data are necessary for the purpose. Also, the European Data Protection Supervisor (EDPS) has demanded further clarification: "The principle of data protection by default aims at protecting the data subject in situations in which there might be a lack of understanding or control on the processing of their data, especially in a technological context. The idea behind the principle is that privacy intrusive features of a certain product or service are initially limited to what is necessary for the simple use of it. The data subject should in principle be left the choice to allow use of his or her personal data in a broader way. The EDPS recommends including in Article 23(2) a reference to this position of the data subject and providing the necessary clarification in recital 61." [START_REF]Opinion of the European Data Protection Supervisor on the data protection reform package[END_REF] As a contrast, in her work on "privacy by design" Cavoukian does not refer to "least privacy intrusive", but regards "privacy by default" as "privacy as the default setting": "If an individual does nothing, their privacy still remains intact. No action is required on the part of the individual to protect their privacy -it is built into the system, by default." [START_REF] Cavoukian | Privacy by Design: The 7 Foundational Principles[END_REF] This sounds good, but if, e.g., the purpose of the application is to disclose personal data to others (as for social networks), an absolute privacy protection cannot be achieved while keeping the functionality. In this case, the EDSP reference to a "simple use" with least privacy infringement probably fits better to the users' expectations.

It is widely agreed that a preconfigured setting does not constitute a user's consent -she might not even be aware of the setting. Also it is out of the question that a user should be able to change the configuration. However, it is debated whether "privacy by default" demands a preconfigured setting. Commissioner Reding, who criticized that "[p]rivacy settings often require considerable operational effort in order to be put in place" [START_REF] Reding | Your data, your rights: Safeguarding your privacy in a connected world[END_REF], focuses on lowering the threshold for users to configure the system according to their needs: privacy settings would have to be "designed to be easily found and manipulated by the user" (Reding according to [START_REF] Altheim | The Review of the EU Data Protection Framework v. The State of Online Consumer Privacy in the US. Blog entry[END_REF] on "privacy by default"). In this interpretation, "privacy by default" would not need a preconfigured setting, but instead users could be forced to set the configuration at the install or first use of the system. The part of Reding's speech on "privacy by default" recognizes that the use of personal data for other purposes than specified could "be allowed with the explicit consent of the user or if another reason for lawful processing exists". This could mean that the default setting already foresees possible legitimate interests of the controller -other than maximizing the user's privacy -and can only be overridden by an explicit choice (opt-out) of the user. Frankly speaking, "opt-out" is not what users understand by "privacy by default".

In another way, the proposed Regulation falls short: the limitation to the necessity and data minimization principle. The Draft Report of the European Parliament extends that dividing "data protection by default" into two categories: the default by the controller when the data subject is given a choice, and the default of applying "data protection by design" by data processors and producers to ensure that the privacycompliant use by controllers [START_REF] Albrecht | Draft Report on the proposal for a regulation of the European Parliament and of the Council on the protection of individual with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF]. For the latter case, that report relates it to all "principles relating to personal data processing" as introduced in a broadened version of Art. 5 of the proposed Regulation by explicitly mentioning transparency, purpose limitation, data minimization, integrity, storage minimization, intervenability, and accountability [START_REF] Albrecht | Draft Report on the proposal for a regulation of the European Parliament and of the Council on the protection of individual with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF].

This seems to be a good approach to converge the discussion on "privacy by default". After all, the related -and often overlapping -concept "security by default", together with "security by design" or "built-in security", has been discussed for decades. The information security community has not agreed upon one single definition. But indisputably the well-known standard rule "deny by default" for firewalls is a good example: "firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy" [START_REF] Scarfone | Guidelines on Firewalls and Firewall Policy. Recommendations of the National Institute of Standards and Technology[END_REF] -note that the default "deny all" means that no network traffic can pass, so even a "simple use" would not be possible, and the art of good firewall rules requires skilled engineers. Another possibility of "security by default" is realized by hardening ICT systems, i.e. all "services and features that are not widely needed should be disabled by default or accessible only to a small population of users" and "software should run with the least necessary privilege" [START_REF] Lipner | The Trustworthy Computing Security Development Lifecycle[END_REF]. Further, encryption as default, e.g. HTTPS as default for web browsing instead of making it an opt-in feature, is mentioned as an example for "security by default" [START_REF] Soghoian | Not an option: time for companies to embrace security by default[END_REF].

Summarizing, "data protection by default" should encompass not only privacy by design as a default, but also least privacy-infringing (or maximally privacyenhancing) default settings where this is reasonable. The question of defaults should address data controllers, processors and producers.

Applying "data protection by default" in practice

In ICT design, "data protection by default" addresses those cases where different configurations are possible, usually depending on the user's choices. For applications that cannot be configured differently, it is demanded anyway that they are legally compliant, and -if the "privacy by design" approach is followed -that they not only respect, but promote the data subject's privacy.

There is no universal answer to when configurable settings should be used and when wired-in functionality without an option to adapt should be preferred. Wired-in functionality may be regarded over-protective or even invasive for the autonomy and informational self-determination of the individual -both important core values of privacy protection. If configurable settings are chosen, their granularity has to be determined: On the one hand, fine-grained controls may be more appropriate to reflect any situation. On the other hand, they might be too complex for users to understand their meaning and the impact of modification. This would increase the risk of undesired consequences when changing the settings [START_REF] Iachello | End-User Privacy in Human-Computer Interaction[END_REF]. This usability issue is also raised by companies who fear that "privacy by default" could result "in software design that confuses and annoys customers with repeated notices and warnings." [START_REF]Microsoft: Privacy by Default[END_REF] However, this argumentation is inexplicable since "privacy by default" aims at the opposite.

Kesan and Shah [START_REF] Kesan | Setting Software Defaults: Perspectives from Law[END_REF] describe a framework for setting defaults, specifically for software, and the role of policy makers: In general, they don't recommend policy makers to intervene when developers choose the default settings -as long as they choose a setting that all parties would have agreed upon. However, they do see a need for interference of policy makers in three cases: "when users lack the knowledge and ability to change an important default setting" (this category may also comprise settings unexpected by the user), if the default settings "cause harm to third parties" or if it "does not comport with existing law and policy" [START_REF] Kesan | Setting Software Defaults: Perspectives from Law[END_REF]. In severe cases, they regard it as "necessary to change the setting from a default value to a wired-in setting" [START_REF] Kesan | Setting Software Defaults: Perspectives from Law[END_REF]. Especially in the area of privacy, one or more of the listed conditions for policy makers' intervention will often apply concerning today's standard software configuration and the lack of expertise and risk awareness of many users.

When discussing the right defaults, two different types of configuration should be distinguished:

1. The configuration of an additional process that is not strictly needed for the original functionality of the application or its simple use. This is usually associated with a new purpose (e.g. an additional subscription of a newsletter or additional data transfer to other parties that analyze the data). This additional process may be perceived as useful by the data subject, or not. 2. The configuration of a process necessary for the purpose within the applicationhere it has to be determined how the default setting should be. For instance, in a case where some data have to be transferred, it could be encrypted by default or not. Another example would be how the indubitable payment process for some goods or services is handled, e.g. via prepayment, credit card or direct debit.

The default for the first configuration type is quite clear: For each additional purpose, process or party getting access to personal data the default setting should be "No". Also for some original purposes like disclosing data to friends in social networks, meaningful privacy defaults could limit the risks. This second configuration type needs more thorough elaboration: It often depends on the functionality that is supported at the user's side; it frequently needs the user's awareness or even consent. For example, the user requires transparency on the payment provider for organizing the money transfer, and usually wants to choose according to her own needs. Here a default would not be demanded. Also, it is not clear which payment method would suit the user best: prepayment, anonymous e-cash, or separated providers that keep financial data confidential and won't gain information on the purchased goods. Further, different methods may result in different costs for the user. Here transparency is needed, but not a one-size-fits-all default.

Concerning encrypted data transfer, thanks to the SSL support in all browsers this can and should be the default for web requests. But for e-mail encryption, this could only be a default if sender and receiver use the same crypto system. Note that some security or privacy functionality, like encryption, may cause performance losses. With today's machines, it is mostly negligible for SSL, so it does not constitute an obstacle against the default setting. Further, legal restrictions for specific countries have to be considered: Even if the privacy default should be a clear "Yes" for well implemented encryption, this may put the user -or the producer -at some legal risk.

In general, the desired privacy default might not be the same all over the world. Think of an application that allows the user to store data in a cloud. According to European data protection law, personal data from Europe shall not be transferred to locations where no adequate level of protection for the rights of the individual is guaranteed. Indeed, undesired access to data demanded by the local government is discussed as one of the major risks when using foreign cloud services. So, a software tool that provides different options for storage locations may have the default setting "Use the European cloud". But should this also apply to non-European users? Probably not -users and policy makers from other nations may prefer a cloud within their territory. In this case, the software could first -in a legally compliant way -analyze the geolocation of the user's IP address to find out whether she comes from Europe and then determine the default setting. However, the exact location of data processing and the place of jurisdiction can be very relevant for a user who wants to assert her data subject's rights, to know about additional risk (e.g. whether the location falls under a data retention regime) or to file a lawsuit.

The solution would be to foresee defaults like that, but to make sure that users notice them and can get more information on the setting, the reasoning behind and possibilities to change the default value. Of course, this would be necessary, too, if costs for the users differ depending on the chosen option. Here it might be better to do without a default, but be explicit on costs and conditions, especially if more security and better privacy protection cost more.

The information on the defaults should always be accessible, even if the user doesn't feel a need to change them. This is not only demanded by transparency requirements, but is also a good means to help users in understanding the system and be able to debate whether the preconfigured defaults are the right ones or should be adapted -not only for the individual, but for a bigger user group.

Not only location can constitute different desired defaults. A special case is the legal requirement for stricter protection of children data. Also, there might be user groups with individual needs, e.g. based on cultural differences or because of disabilities. However, determining the appropriate default is not a compelling legal reason for a comprehensive analysis of personal data at the controller's side. For client configurations at the user's side, it is possible that the user can choose at install or first use between various categories to get the most appropriate defaults, but this must not result in a transfer of potentially sensitive data (e.g. on disabilities).

In addition, there might be "configuration providers" offering the most appropriate default for their respective community, e.g. as a downloadable file or a newsfeed with updates. This may be a data protection authority, a consumer organization, an associa-tion of people with disabilities, a church, a club or other interested users. These configuration providers could support users if a reaction on a security breach is necessary ("from now on no further data transfer to XY", "abstain from broken crypto algorithm XZ"). By this, more flexibility in shorter reaction time could be achieved. Note that, by providing this default setting, the responsibility and liability for at least that part of the configuration is shifted from the producer/controller/processor to this configuration provider.

From the previous discussion and the legal data protection framework, criteria for assessing potential default settings are sketched in form of a flowchart in Fig. 1. Clearly, a default setting that excludes any risks and enables an at least simple use of the system is a good solution for data protection by default. However, exclusion of any privacy risk may lead to a severe restriction of functionality to that even a simple use is not possible. In some cases, this can be the best choice to guarantee that users become aware of configuration options -it is comparable to the "deny all" firewall rule that forces the users to think about what they really need. However, there may be another solution that does not rule out any privacy risk, but is based on legal grounds. Hopefully, these legal grounds are not overly privacyinfringing themselves (think of the data retention directive). An example is the legal provision on pseudonymous profiling of users under strict conditions as foreseen in the German Telemedia Law and in the Draft Report of the Parliament [START_REF] Albrecht | Draft Report on the proposal for a regulation of the European Parliament and of the Council on the protection of individual with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF]. In this case, the law has defined that users have to be notified and can opt-out, but the default setting may be "Yes" for pseudonymous profiling, although this would not be the least privacy-infringing solution. So it is debatable whether this legally compliant solution still counts as "data protection by default". The reasoning behind privileging pseudonymous data processing is that the purpose can be achieved by accepting a reduced risk compared with a detailed analysis under real names, no matter whether the otherwise legally demanded consent is collected or not. In general, a risk may be tolerable if it is known to the data subject and no overriding legitimate interests of the data subject would be adversely affected. The same line of thought can be applied if the default relies on a consent the user has given earlier.

Is
As stated above, there are many situations where a meaningful privacy default cannot be established. In these cases, a fair implementation of user information and choice is necessary. Otherwise it is questionable whether a solution can be lawful.

4

Identity-related application scenarios and "data protection by default"

In this section, three examples for identity-related applications and potential defaults are discussed: social network sites, user tracking on the web and user-controlled identity management systems.

Social network sites

Although the discussion on "data protection by default" is much older, with social network sites it became apparent to huge parts of the society how important some privacy features are what may happen if private information is widely distributed.

One example is the problem with Facebook parties where users have accidentally invited thousands of members of the network instead of their small group of real friends. As already written in Section 2, the proposed European Data Protection Regulation explicitly demands mechanisms that prevent by default that personal data are made accessible to an indefinite number of individuals. [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF] Various research teams have investigated the value of privacy settings in social networks such as Facebook, e.g. [START_REF] Liu | Analyzing Facebook Privacy Settings: User Expectations vs. Reality[END_REF], [START_REF] Madejski | The Failure of Online Social Network Privacy Settings[END_REF] and [START_REF] Rubinstein | Privacy by Design: A Counterfactual Analysis of Google and Facebook Privacy Incidents[END_REF]. They found that, in large part, the privacy settings didn't match the users' expectations who typically expected a higher degree of privacy and less visibility of their personal data to others.

The understanding of privacy settings could be improved by an appropriate choice of words. For instance, a Facebook "friend" is not always a friend, and when it comes to friends of friends, this may sound nice and still quite intimate, but there is no reliable estimation of users who belongs to this category. For research purposes in [START_REF] Madejski | The Failure of Online Social Network Privacy Settings[END_REF], the Facebook category "everyone" for configuring the accessibility was renamed to "stranger". By this, the scope of potential access can be better expressed.

The question of "data protection by default" in practice for social network sites has been tackled by several researchers. In the work of [START_REF] Niemann | Privacy by Design und Privacy by Default -Wege zu einem funktionierenden Datenschutz in Sozialen Netzwerken[END_REF], "privacy by design" and "privacy by default" have been analyzed separately. Whereas, among others, the aspect of allowing anonymous or pseudonymous use in social networks is considered a "privacy by design" requirement, the following collection of recommendations and considerations are categorized as "privacy by default" [START_REF] Niemann | Privacy by Design und Privacy by Default -Wege zu einem funktionierenden Datenschutz in Sozialen Netzwerken[END_REF]:

• In the default setting, only the basic functionalities should be provided, i.e. only those personal data should be collected and used that are necessary for employing a basic service as expected by the users. This also enables users to become familiar with the system.

• Additional privacy-related functionality needs explicit consent by users. For instance, external search engines should not be able to find a user or to access her data unless she opts in. The biometric analysis of photos would need explicit information of the data subject and her consent.

• default setting for the visibility of profile or status data should be limited to the user's circle of close friends. There might be an exception for social networks that are dedicated to exchanging business contacts.

• If minors are member of the social network, the default settings have to be especially strict.

• Even with strict default settings a usage of the service should be possible. Otherwise there is a risk that users activate everything they can to overcome the limitations of the default settings.

• The provider has to inform the users about defaults and options in a comprehensible way in the registration process. They should be able to conveniently access and check their setting. The information should be well-arranged and easy to understand. Settings should be changeable at any time with effect for the future.

It should go without saying that personal data of non-members of a social network should not be collected unless they have given consent.

User tracking on the web

As soon as commercial sites became part of the World Wide Web, the tracking of users started -based on analysis of IP addresses, the referrer information or other browser chatter and cookies of different kinds. This information is being used especially for marketing research and for adjusting online advertisement according to the usage profile of the web surfers (behavioral targeting). Not always the data are matched to individual users, but at least the collected raw data has to be considered personal data. Most web browsers offer some possibilities for configuration, and several users install plug-ins that help them filtering tracking functions or advertisements. Still, the data collection by many web sites, directly or via third parties, doesn't comply with the requirements set out in the European e-Privacy Directive [23] or Member State's law. Since 2007, consumer organizations in the U.S. have uttered the need for some "Do Not Track" solutions. In this situation, the World Wide Web Consortium took up a proposal of a "Do Not Track" (DNT) header that could be integrated in web browsers. Three different values of DNT are possible: "1" for "opt-out", meaning that the user does not want to be tracked; "0" for "opt-in", meaning that user consents to being tracked; and "null" (no header sent) if the user has not expressed a preference [START_REF]Tracking Preference Expression (DNT). W3C Working Draft 02[END_REF].

When Microsoft announced that their Internet Explorer 10 would be rolled out with default setting "1" (i.e. no tracking), several stakeholders in the U.S. regarded that as an affront since Microsoft, and not the user, would be exercising choice on the browser signal. They threatened to ignore all "no tracking" values sent from Internet Explorers because these settings would represent a choice made by a company instead of the user herself.

However, the European Commission has clarified that "it is not the Commission's understanding that user agents' factory or default setting necessarily determine or distort owner choice. The specification need not therefore seek to determine the factory setting and should not do so, because to intervene on this point could distort the market. [...] the standard should foresee that at the install or first use of the browser the owner should be informed of the importance of their DNT choice, told of the default setting and prompted or allowed to change that setting." [START_REF]Letter to World Wide Web Consortium Tracking Protection Working Group[END_REF] Note that the Commission's statement does not judge on which default the factory setting should be preferred -this is left to the discretion of the browser producers.

This fight over the default setting for behavioral advertizing has an economic background. Even when surveys have shown that the majority of U.S. users as well as European users don't want to be tracked, the huge advertising industry strongly opposes the idea of a non-tracking default. It challenges the business model of offering services "for free" in exchange for collecting and analyzing personal data for individually targeted advertisements. So it may boil down to the question who will pay for web services and what privacy-respecting business models may work.

User-controlled managing of one's identities

User-controlled identity management systems assist and empower users to manage their own partial identities in their digital lives as well as their privacy [START_REF] Hansen | User-controlled identity management: the key to the future of privacy?[END_REF]. They act as gateways and guardians between the user and her communication partners. It is not easy to define the right defaults in such concepts, because active privacy management by the users themselves require their understanding and control while the "data protection by default" principle mainly addresses those users who are not aware of the risks and are not willing or able to configure their system according to their needs. Of course, user-controlled identity management systems would have to inform and train users, but should not generally follow a too paternalistic approach which may be the case when deciding automatically on behalf of the users. Still, a few guidelines can be given here, too:

• When user-controlled identity management systems are employed for achieving unlinkability between different partial identities, this has to be supported throughout all network layers: For instance, if linkable device IDs, IP addresses or browser chatter are communicated, the protection against linkage that private credentials can offer is void. Also, additional data hidden in files may jeopardize the protection. So metadata in documents or photos should not be disclosed to others unless explicitly chosen by the user. Note that this setting relies on additional privacy-bydesign functionality.

• Naturally, all communication should be encrypted by default. Further, the storage of personal data under control of the user herself should be done in a highly secure and trustworthy area to protect unauthorized access.

• As design feature, warnings should be displayed by default if the personal data are to leave the area where the legal data protection framework relevant to the user (e.g. the European Economic Area for European citizens) can be enforced. This may be extended in cases of security or data protection breaches.

• By default, each new contact would mean to create and use a new pseudonym (representing another partial identity) if not stated otherwise. For existing contacts, a re-use of the already established pseudonym should be the default unless the user demands a new one. Note that this violates the rule of maximizing unlinkability for best privacy protection due to presumed functionality requirements: In usercontrolled identity management systems, it should be the (changeable) default to enable longer lasting relationships with a communication partner instead of being limited to an anonymous use or one-time contacts.

• Only those attribute values that are necessary for the purpose should be released. The identity management system cannot decide on its own which attributes are needed. So here a fully automatic transfer of personal data without explicit and informed user consent is not advised. However, this process may be supported by certificates that communication partners (the "relying parties") can get from a trusted party after having assessed the necessity for the attributes for the specified purpose. For the German eID card, this is done to allow selective disclosure of attributes such as information about the age or the domicile, and to distinguish between usage under pseudonym or by giving the real name [START_REF] Zwingelberg | Privacy Protection Goals and Their Implications for eID Systems[END_REF].

For attribute-based credentials that provide a more general solution on possible attributes that may be selectively disclosed meaningful and privacy-friendly defaults still have to be elaborated [START_REF]ABC4Trust -Attribute-based Credentials for Trust, FP7 ICT Integrated Project[END_REF]. Also, the integration of additional parties that take part in the issuing or revoking process or may be relevant if an investigation is needed has to be considered when discussing privacy by default.

Conclusion

The principle "data protection by default" is part of the "privacy by design" approach.

Although both "data protection by default" and "by design" have been incorporated as a legal requirement in the proposed European Data Protection Regulation [START_REF]Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF], they are still not well defined. The Draft Report of the European Parliament on the Regulation [START_REF] Albrecht | Draft Report on the proposal for a regulation of the European Parliament and of the Council on the protection of individual with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation)[END_REF] provides some clarification. But even this improved version of a legal proposal does not answer all questions for an application in practice.

Looking at various interpretations of the "data protection by default" principle, we conclude that two major types of configuration should be distinguished: the introduction of functionality with additional purposes on top of the basic system, and the setting of different options for components within the core application context. Whereas all additional functionality, that is not needed for the original purpose but can involve privacy risks, should be denied by default, the form of the preconfigured setting for mandatory functionality is not always clear when different options exist. However, such situations often require the user's awareness of the data processing and related risks so that a seamless interaction is not advised anyway. is recommended that users get the necessary information to compare settings regarding privacy risks and other relevant properties such as costs or required functionality. In many cases, a fully automatic decision on which defaults are the best for privacy cannot work since there is no overall accepted privacy metrics. Also, even privacy-aware users may have different preferences. In some cases localized defaults should be preferred over global settings, e.g. if the jurisdiction of processors plays a role. For those who don't want to delve into tailoring their settings, configuration providers can step in and offer meaningful defaults fitting various user groups.

An open question is whether "data protection by default" should try to maximize the privacy level when other kinds of data processing are privileged in data protection law. This is especially important for pseudonymous data processing that can massively reduce the risks to privacy in comparison to working with personal data on the basis of consent. Here "data protection by default" may mean "legally compliant by default" instead of "maximum privacy". In these cases, transparency on the defaults and ways for users to change them are essential.

Note that it is not sufficient to have good default settings if users are later on being tricked into releasing data or activating services. Experiments have shown that already the way in which individuals are asked for a decision concerning their privacy might influence their choice [START_REF] Acquisti | What is privacy worth?[END_REF] -such psychological effects have to be further investigated. Supervisory authorities should demand neutral and fair information of users -otherwise a given consent might not be regarded as valid.

Whereas the default settings in the presented scenarios are important, but usually can be changed with some effort by the users, the choice of "data protection by default" becomes even more crucial when the personal computer as interface for looking at settings and changing them vanishes. With tablet computers and mobile phones, the convenience for reconfiguring the system already decreases. Similarly, Smart TVs that are based on web protocols appear to have similar privacy risks as browsing the Internet, but less configuration possibilities. Finally, for ubiquitous computing only few proposals exist on how "privacy by default" could be implemented [START_REF] Schmitt | Privacy as default. Privacy by default! Konzept für Privatsphäre im Ubiquitous Computing[END_REF].

All in all, the discussion on defaults should not promote that users lack necessary information and simply rely on the assumption that the best choice for them has been made already. This would not reduce, but rather increase the vulnerability of individuals' privacy.

Fig. 1 .

 1 Fig.1. Assessing potential default settings for user choices in applications.

may be okay if risks are tolerable and users are sufficiently made aware (of data processing, risks, potential opt-out possibilities)

		Exemplary solution
	!	Warning: default should be set Maybe okay (under usual reserve)	YES	there a default setting?	NO
		Violation of data protection law
	YES At least simple use possible? Good solution for data protection by default YES	Privacy risks excluded (no personal data processed)? NO YES Solution Meaningful privacy Based on legal grounds? NO NO Based on prior consent (informed, freely given)? NO YES default conceivable? YES Solution should foresee a default ! Fair implementation NO of user choice? Solution violates data protection law Solution may be okay YES NO
					Solution violates
					data protection law

Acknowledgments. I am grateful for the support of Jozef Vyskoč and Simone

Fischer-Hübner throughout various versions of this text.