Add text for Web SQL and IndexedDB

chapters/methods.tex

@@ -539,7 +539,7 @@ the full range of features in offline-mode is feasible.
 
 The third category of HTML5 Web Storage is similar to Local Storage, but
 requires that the stored data be deleted after a session is closed. While
-content that is persisted by Local Storage, must be deleted explicitly by the
+content that is persisted by Local Storage must be deleted explicitly by the
 user, Session Storage has the intended function of providing non-persistent
 storage.
 
@@ -553,9 +553,58 @@ section~\ref{subsec:evercookie}).
 \subsection{HTML5 Indexed Database API}
 \label{subsec:html5 indexed database api}
 
+The need for client side storage to provide performant web applications that can
+also function offline, has prompted the inception of alternative methods to
+store and retrieve information. Consequently, the development of the HTML5
+standard has tried to fill that need by introducing HTML5 Web Storage and the
+HTML5 Indexed Database \gls{API}.
+
+HTML5 Indexed Database \gls{API} provides an interface for storing values and
+hierarchical objects using the well-known key-value pair storage principle
+\cite{alabbasIndexedDatabaseAPI2020}. This property makes it similar to NoSQL
+storage solutions which have seen increasing adoption rates on the web. It is
+the successor to the abandonend Web SQL Database (see section~\ref{subsec:web
+sql database}) standard and functions similarly to the HTML5 Web Storage,
+meaning that it has the same storage limits and privacy implications and has to
+obey the same-origin policy. In contrast to HTML5 Web Storage, IndexedDB is
+intended for storing larger amounts of data and provides additional functions
+such as in-order key retrieval. Reading from and writing to an IndexedDB is done
+with JavaScript by opening a connection to the database, preparing a transaction
+and committing it. The development of the standard is ongoing with two editions
+already published and recommended by the W3C and the third edition existing as
+an editors draft until it is ready for recommendation.
+
+HTML5 IndexedDB has been added to the evercookie library (see
+section~\ref{subsec:evercookie}) by
+\citeauthor{kamkarEvercookieVirtuallyIrrevocable2010}, providing redundancy for
+\gls{HTTP} cookies. \citeauthor{acarWebNeverForgets2014}
+\cite{acarWebNeverForgets2014} have shown that only 20 of 100.000 surveyed sites
+use the IndexedDB storage vector with one of them (\texttt{weibo.com}) using it
+for respawning \gls{HTTP} cookies.
+
 \subsection{Web SQL Database}
 \label{subsec:web sql database}
 
+Web SQL Database \cite{hicksonWebSQLDatabase2010} was initially developed to
+provide an \gls{API} for storing data in databases. The stored data can then be
+queried using \gls{SQL} or variants thereof. The W3C stopped the development of
+the standard in 2010 due to a lack of other backend implementations (other than
+SQLite) which is necessary for a recommendation as a standard. Browsers have
+turned to HTML5 IndexedDB (see section~\ref{subsec:html5 indexed database api}),
+the ``spiritual successor'' to Web SQL Database, for web database storage.
+
+In the same way that other tracking technologies can maintain a history of web
+site visits and actions, Web SQL Database can store identifying information via
+the usage of unique identifiers. An arbitrary maximum size of 5 megabytes of
+storage per origin is recommended by the standard, with the possibility to ask
+the user for more capacity. This limit includes other domains which are
+affiliated with the origin but have a different name (e.g. subdomains).
+
+Due to the W3C abandoning the Web SQL Database standard, not many reports on
+usage for tracking purposes exist. The method has been added, however, to the
+evercookie library by \citeauthor{kamkarEvercookieVirtuallyIrrevocable2010} (see
+section~\ref{subsec:evercookie}) to add another layer of redundancy for storing
+unique identifiers and respawning deleted ones.
 
 \section{Cache-based Tracking Methods}
 \label{sec:cache-based tracking methods}