\documentclass{article}
\usepackage{fullpage}
\usepackage{setspace}
\usepackage{graphicx, url}
\doublespacing

% $Id: Report2.tex 24901 2008-08-22 21:47:48Z stunes $

\title{Addressing Privacy Leakage from Search Engine Logs}
\author{Mike Stunes}

\begin{document}

\maketitle

\section{Introduction}

Search engines have the ability to collect massive amounts of data about their
users. 
The ability to use this data is invaluable for research to improve
search engines, and to provide useful, personalized services to
users.
The type of data collected by search engines carries an
enormous privacy risk for users, however.
Users often reveal very personal information
through their search engine usage, and the collection of a number of search
queries can allow detailed profiling of persons.

% TODO: Intro -- what I did

\section{Motivation}

In order to address the privacy problems that arise with collecting
users' data from search engines, most solutions rely on traditional
access control methods, which while practical and useful, do have
their limitations. MIT CSAIL's Decentralized Information Group (DIG),
with which I have been working this summer, has been working on
alternative methods of information access control methods, in the form
of policy-based data use control, where access to information is
logged in such a way that it may be used only for allowed purposes,
and violations of applicable policies can be tracked and violators
held accountable~\cite{weitzner07accountability}.

% Accountability framework
In order to implement this policy-based access control, there is a
need for a ``complete accountability architecture,'' which is a
collection of software that completely manages all of the information
necessary for a policy-based system.

% (In order to do this), (it is needed) a ``complete accountability
% architecture'' that
% can create and handle all of the information that is necessary to enforce our
% access control and usage policies.

This complete architecture would have a server holding sensitive data
and applicable policies that logs the usage of this data, and a client
that queries the server for data and also logs how the data that is
returned is being used. The system would also contain reasoners that
can check that the logged usage is compliant with the applicable
policies.

\section{Architecture}

\begin{figure}
\centering
\includegraphics[width=150mm]{system_diagram}
\caption{Accountability framework architecture.}\label{fig:architecture}
\end{figure}
% TODO: describe interaction between components?

% Complete system architecture
% The accountability framework system exists as a set of interoperating
% components, including a SPARQL endpoint server and a Python client library.

The accountability framework system exists as a set of interoperating
components, including a custom SPARQL~\cite{sparql} endpoint server,
matching Python client library, DIG's {\tt AIR}~\cite{kagal08air} and
{\tt cwm}~\cite{berners08n3} reasoners, and MySQL databases for RDF
triple storage.

% Server Features
\subsection{Features}
The server is a custom HTTP server, written in Python, that implements
most of the features that are necessary for it to integrate into our
complete accountability framework. It handles authentication of
requesters using OpenID~\cite{openid}, logging queries in RDF, and
secure client/server communication using SSL.

The server uses Python's {\tt Base\-HTTP\-Server} for its HTTP
functionality, and implements SSL using the {\tt pyOpenSSL}
library. It also uses {\tt rdflib}~\cite{rdflib} with a persistent
MySQL store for RDF storage, querying, and logging, and uses {\tt
  python\--openid} for OpenID authentication.

% Access policy
\subsection{Access Policy}
Access policy on the server is implemented by allowing the server
administrator to define a custom function to enforce access
control. This function receives as input the OpenID identifier of the
client, and outputs a boolean value corresponding to whether access is
granted, based on whatever reasoning system it chooses. This allows an
extremely high amount of flexibility in creating access control
policy. The example code included with the server includes a function
that uses the {\tt cwm} reasoner with a set of rules written in N3.

% Use policy
\subsection{Usage Policy}
The server also has the ability to attach a usage policy to data that is
returned to clients, accessible by navigating to the path {\tt /policy} from
the server's base URI. Similar to its handling of access control policy, the
document to be returned to the client upon request is handled dynamically by a
custom function. A link to the policy is attached to the XML-formatted query
results with the \verb=<sparql:link>= tag, included in the header.

% Client
\subsection{Client}
In order to enable the client to be used interactively, a matching Python
client library was created. The library consists of a class,
\verb=SparqlWrapper=, which abstracts the public interface of the server.
Details on the use of the client are provided in the Non-Interactive Example
Request section, below.


\section{Example Requests}

This section provides complete walkthroughs of example requests for data on the
server. For the purpose of these demonstrations, assume that there is a server
running on {\tt https://\-example.org:8080}.

\subsection{Interactive}

This scenario describes the sequence of actions that take place when a user
accesses the server with an interactive client, such as a Web browser.

First, the client navigates his/her browser to the base URI of the
server, which in this example is {\tt
  https://\-example.org:8080}. Upon receiving the request, {\tt
  Sparql\-Server} (a subclass of {\tt
  Base\-HTTP\-Server.\-HTTP\-Server}) calls the {\tt do\_GET} method
of {\tt Sparql\-Request\-Handler}. {\tt do\_GET} extracts certain
information from the request (such as the URL's CGI parameters),
attaches a timestamp to the request instance, and calls the
appropriate handler function inside of {\tt
  Sparql\-Request\-Handler}. In this case, it will call the {\tt
  show\-Entry\-Page} method, which checks if the client already has a
valid session (more on this later), and if not (as is the case now),
presents the client with a login page. Had the client already had a
valid session, he/she would be redirected to the interactive webform
instead, which we will see shortly.

When the user submits his/her identifier, the form data is submitted
to {\tt https://\-example.org:8080/\-login}, which after invoking {\tt
  do\_GET}, calls {\tt show\-Login}. {\tt show\-Login} creates a
session ID for the user; creates a new dictionary of session
information (stored in the server's {\tt sessions} dictionary); checks
if the user is allowed to access the server (see Access Policy,
above); inserts the session ID, IP address, hostname, and OpenID
identifier of the client into the session dictionary; and redirects
the client to his/her OpenID Provider (OP).

The client's OP will redirect him/her to the path {\tt
  /login\-Complete}, which invokes {\tt show\-Login\-Complete}. This
function loads the session dictionary which was created earlier,
verifies the client's OpenID authentication, sets a session cookie on
the client's browser that holds a session ID, and redirects the client
to the interactive webform.

When the client reaches the interactive webform, he/she has the option of
entering a query directly, or choosing from a list of prewritten sample
queries. (Note that this particular webform was designed primarily as a
demonstration of the server's capabilities, and can easily be replaced with a
different webform designed for the purpose at hand.) Also, in this
demonstration webform, the user has the option of viewing a list of queries
logged with his/her OpenID identifier.

The webform submits its data to the {\tt sparql} path, which is the actual
SPARQL-endpoint-like interface to the server. It invokes {\tt show\-Sparql},
which loads the existing session dictionary, performs a set of security checks
(defined in the {\tt doSecurity\-Checks} method), logs the query, calls out to
the query modification interface (which currently does nothing), runs the
query, attaches the usage policy to the results, and returns the results to the
client.

\subsection{Non-interactive}

\begin{figure}
\centering
\includegraphics[width=100mm]{openid}
\caption{Non-interactive OpenID authentication process.}\label{fig:openid}
\end{figure}

This scenario describes the sequence of actions that take place when a user
accesses the server with a non-interactive client, using the matching Python
client library, and also describes how OpenID authentication is used in this
situation. The OpenID process used is summarized in Figure~\ref{fig:openid}.

First, the user creates a new {\tt SparqlWrapper} instance:

\begin{verbatim}
>>> import sparql_client
>>> from sparql_client import SparqlWrapper
>>> foo = SparqlWrapper('https://example.org:8080')
\end{verbatim}

At some point, before running queries, the client authenticates to the server:

\begin{verbatim}
>>> foo.authenticate('http://some_guy.sample_openid_provider.com')
\end{verbatim}

This causes the client to request the page at the path {\tt /getSession}, which
invokes the method {\tt showGetSession}. This function creates a new session ID
and session dictionary; stores the session ID, IP address, hostname, and OpenID
identifier in the dictionary; checks if the user is allowed to access the
server (see Access Policy, above); and redirects the client to the path {\tt
/clientLogin} on the server. Back on the client side, the {\tt authenticate}
function opens an HTTP server on {\tt localhost:9876}, which will be explained
shortly.

Upon receiving this redirect, the client library captures the URL it is
pointing to, extracts the session ID (stored in the URL) and saves it, and
opens the user's browser, pointed to the redirect's URL. This causes the user's
browser to request the page at {\tt /clientLogin}, which loads the existing
session dictionary and redirects the browser to the user's OP.

The user's OP redirects the browser to the page at {\tt /clientComplete}, which
loads the existing session and verifies the user's OpenID. It then sends a
redirect to {\tt localhost:9876}, causing the user's browser to make a request
on the HTTP server that the client library started earlier. This serves as a
signal to the client (which has been unaware of events taking place in the
browser) that the authentication process is complete.

The client can issue simple queries as follows:

\begin{verbatim}
>>> foo.setQueryString('SELECT * WHERE {?s ?p ?o . }')
>>> results = foo.query()
\end{verbatim}

Currently, the client library provides little more than the ability to retrieve
the XML returned from the server, through a file-like object returned by {\tt
query}. It would not be difficult, however, for the client to parse the
returned XML into an RDF graph, using \verb=rdflib= or something similar.

% TODO: advanced features of the client library
% (none of which actually do anything yet)

\section{Conclusions and Lessons Learned}

One particular lesson reinforced by this project was the importance of adequate
documentation. The client and server needed functionality from several existing
libraries that were poorly documented, and the difficulty of using them was
eased only by either asking the library's maintainer for assistance, or
manually analyzing the library's source code. Of course, doing either of those
requires that either the source code or the maintainer is readily available,
which is certainly not always the case.

Another lesson that this project taught me was the importance of immediately
implementing a clear and extendible structure in the project's code, keeping in
mind the flow of events and alternative paths that may be needed to address
anything that happens. Several
times, major feature implementations and debugging were made difficult by the
improperly-structured code, and the only simple remedy was a complete
reorganization of the code.

\bibliographystyle{abbrv}
\bibliography{dig}

\end{document}

