81 lines
8.1 KiB
TeX
81 lines
8.1 KiB
TeX
\subsection{Motivation}
|
|
\label{subsec:lmdk-motiv}
|
|
|
|
% Crowdsensing applications
|
|
The plethora of sensors currently embedded in personal devices and other infrastructures have paved the way for the development of numerous \emph{crowdsensing services} (e.g.,~Ring~\cite{ring}, TousAntiCovid~\cite{tousanticovid}, Waze~\cite{waze}, etc.) based on the collected personal, and usually geotagged and timestamped data.
|
|
% Continuously user-generated data
|
|
User--service interactions gather personal event-like data, that are data items comprised of pairs of an identifying attribute of an individual and the---possibly sensitive---information at a timestamp (including contextual information), e.g.,~(\emph{`Bob', `dining', `Canal Saint-Martin', $17{:}00$}).
|
|
When the interactions are performed in a continuous manner, we obtain ~\emph{time series} of events.
|
|
% Observation/interaction duration
|
|
Depending on the duration, we distinguish the interaction/observation into \emph{finite}, when taking place during a predefined time interval, and \emph{infinite}, when taking place in an uninterrupted fashion.
|
|
Example~\ref{ex:scenario} shows the result of user--LBS interaction while retrieving location-based information or reporting user-state at various locations.
|
|
|
|
\begin{example}
|
|
\label{ex:scenario}
|
|
|
|
Consider a finite sequence of spatiotemporal data generated by Bob during an interval of $8$ timestamps, as shown in Figure~\ref{fig:scenario}.
|
|
Events in a shade correspond to privacy-sensitive events that Bob has defined beforehand. For instance his home is around {\'E}lys{\'e}e, his workplace is around the Louvre, and his hangout is around Canal Saint-Martin.
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[width=\linewidth]{lmdk-scenario}
|
|
\caption{A time series with {\thethings} (highlighted in gray).
|
|
}
|
|
\label{fig:scenario}
|
|
\end{figure}
|
|
|
|
\end{example}
|
|
|
|
% Privacy-preserving data processing
|
|
The services collect and further process the time series in order to give useful feedback to the involved users or to provide valuable insight to various internal/external analytical services.
|
|
The regulation regarding the processing of user-generated data sets~\cite{tankard2016gdpr} requires the provision of privacy guarantees to the users.
|
|
At the same time, it is essential to provide utility metrics to the final consumers of the privacy-preserving process output.
|
|
To accomplish this, various privacy techniques perturb the original data or the processing output at the expense of the overall utility of the final output.
|
|
A widely recognized tool that introduces probabilistic randomness to the original data, while quantifying with a parameter $\varepsilon$ (`privacy budget'~\cite{mcsherry2009privacy}) the privacy/utility ratio is \emph{$\varepsilon$-differential privacy}~\cite{dwork2006calibrating}.
|
|
Due to its \emph{composition} property, i.e.,~the combination of differentially private outputs satisfies differential privacy as well, differential privacy is suitable for privacy-preserving time series publishing.
|
|
\emph{Event}, \emph{user}~\cite{dwork2010differential, dwork2010pan}, and \emph{$w$-event}~\cite{kellaris2014differentially} comprise the possible levels of privacy protection.
|
|
Event-level limits the privacy protection to \emph{any single event}, user-level protects \emph{all the events} of any user, and $w$-event provides privacy protection to \emph{any sequence of $w$ events}.
|
|
|
|
The privacy mechanisms for the aforementioned levels assume that in a time series any single event, or any sequence of events, or the entire series of events is equally privacy-significant for the users.
|
|
In reality, this is an simplistic assumption.
|
|
The significance of an event is related to certain user-defined privacy criteria, or to its adjacent events, as well as to the entire time series.
|
|
We term significant events as \emph{{\thething} events} or simply \emph{\thethings}.
|
|
Identifying {\thethings} can be done in an automatic or manual way (but is out of scope for this work).
|
|
For example, in spatiotemporal data, \emph{places where an individual spent some time} denote \emph{points of interest} (POIs) (called also stay points)~\cite{zheng2015trajectory}.
|
|
Such events, and more particularly their spatial attribute values, can be less privacy-sensitive~\cite{primault2018long}, e.g.,~parks, theaters, etc. or, if individuals frequent them, they can reveal supplementary information, e.g.,~residences (home addresses)~\cite{gambs2010show}, places of worship (religious beliefs)~\cite{franceschi-bicchierairussell2015redditor}, etc.
|
|
POIs can be an example of how we can choose {\thethings}, but the idea is not limited to these.
|
|
Another example is the detection of privacy-sensitive user interactions by \emph{contact tracing} applications.
|
|
This can be practical in decease control~\cite{eames2003contact}, similar to the recent outbreak of the Coronavirus disease 2019 (COVID-19) epidemic~\cite{ahmed2020survey}.
|
|
Last but not least, {\thethings} in \emph{smart grid} electricity usage patterns could not only reveal the energy consumption of a user but also information regarding activities, e.g.,~`at work', `sleeping', etc. and types of appliances already installed or recently purchased~\cite{khurana2010smart}.
|
|
|
|
\begin{example}
|
|
\label{ex:st-cont}
|
|
|
|
Figure~\ref{fig:st-cont} shows the case when we want to protect all of Bob's significant events ($p_1$, $p_3$, $p_5$, $p_8$) in his trajectory shown in Figure~\ref{fig:scenario}.
|
|
% That is, we have to allocate privacy budget $\varepsilon$ such that at any timestamp $t$ it holds that $\varepsilon_t + \varepsilon_1 + \varepsilon_3 + \varepsilon_5 + \varepsilon_8 \leq \varepsilon$.
|
|
In this scenario, event-level protection is not suitable since it can only protect one event at a time.
|
|
Hence, we have to apply user-level privacy protection by distributing equal portions of $\varepsilon$ to all the events, i.e.,~$\frac{\varepsilon}{8}$ to each one (the equivalent of applying $8$-event privacy).
|
|
In this way, we have protected the {\thething} points; we have allocated a total of $\frac{\varepsilon}{2}<\varepsilon$ to the {\thethings}.
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[width=\linewidth]{st-cont}
|
|
\caption{User-level and {\thething} $\varepsilon$-differential privacy protection for the time series of Figure~\ref{fig:scenario}.}
|
|
\label{fig:st-cont}
|
|
\end{figure}
|
|
|
|
However, perturbing by $\frac{\varepsilon}{8}$ each regular point deteriorates the data utility unnecessarily.
|
|
Notice that the overall privacy budget that we ended up allocating to the user-defined significant events is equal to $\frac{\varepsilon}{2}$ and leaves an equal amount of budget to distribute to any current event.
|
|
In other words, uniformly allocating $\frac{\varepsilon}{5}$ to every event would still achieve the Bob's privacy goal, i.e.,~protect every significant event, while achieving better utility overall.
|
|
|
|
\end{example}
|
|
|
|
We argue that protecting only {\thething} events along with any regular event release is sufficient for the user's protection, while it improves data utility.
|
|
Considering {\thething} events can prevent over-perturbing the data in the benefit of their final quality.
|
|
Take for example the scenario in Figure~\ref{fig:st-cont}, where {\thethings} are highlighted in gray.
|
|
If we want to protect the {\thething} points, we have to allocate at most a budget of $\varepsilon$ to the {\thethings}, while saving some for the release of regular events.
|
|
Essentially, the more budget we allocate to an event the less we protect it, but at the same time we maintain its utility.
|
|
With {\thething} privacy we propose to distribute the budget taking into account only the existence of the {\thethings} when we release an event of the time series, i.e.,~allocating $\frac{\varepsilon}{5}$ ($4\ \text{\thethings} + 1\ \text{regular point}$) to each event (see Figure~\ref{fig:st-cont}).
|
|
This way, we still guarantee that the {\thethings} are adequately protected, as they receive a total budget of $\frac{4\varepsilon}{5}<\varepsilon$.
|
|
At the same time, we avoid over-perturbing the regular events, as we allocate to them a higher total budget ($\frac{4\varepsilon}{5}$) than in user-level ($\frac{\varepsilon}{2}$), and thus less noise.
|