Merge branch 'master' of git.delkappa.com:manos/the-last-thing

text/problem/thething/main.tex

@@ -8,13 +8,26 @@ We term significant events as \emph{{\thething} events} or simply \emph{\thethin
 
 Identifying {\thethings} in time series can be done in an automatic or manual way.
 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.
+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}.
+Last but not least, {\thethings} in \emph{smart grid} electricity usage patterns may not only reveal the energy consumption of a user but also information regarding activities, e.g.,~`at work', `sleeping', etc., or types of appliances already installed or recently purchased~\cite{khurana2010smart}.
 We stress out that {\thething} identification is an orthogonal problem to ours, and that we consider {\thethings} given as input to our problem.
 
+We argue that protecting only {\thething} events along with any regular event release -- instead of protecting every event in the timeseries -- is sufficient for the user's protection, while it improves data utility.
+More specifically, important events are adequately protected,  while less important ones are not excessively perturbed. \kat{something feels wrong with this statement, because in figure 2 regular and landmarks seem to receive the same amount of noise..}
+%In fact, 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\footnote{$\epsilon$-differential privacy guarantees that the allocated budget should be less or equal to $\epsilon$, and not precisely how much.\kat{Mano check.}} 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}$) compared to the user-level scenario ($\frac{\varepsilon}{2}$), and thus less noise.
+  
+
+
+
 \begin{example}
 	\label{ex:st-cont}
 	
@@ -37,16 +50,6 @@ We stress out that {\thething} identification is an orthogonal problem to ours,
 	
 \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. 
-
-
 \input{problem/thething/contribution}
 \input{problem/thething/problem}
 \input{problem/thething/solution}