From 9cdf4e17bc5abb6eef351c6b7298f91a181164f0 Mon Sep 17 00:00:00 2001
From: Chip Black <bytex64@bytex64.net>
Date: Thu, 30 May 2013 05:25:17 -0500
Subject: [PATCH] Add documentation for 1.8

---
 www/css/blerg.css         |  6 +++++
 www/doc/changelog.html    | 33 ++++++++++++++++++++-------
 www/doc/index.html        | 37 +++++++++++++++---------------
 www/doc/privacy_data.html | 48 +++++++++++++++++++++++++++++++++++++++
 www/index.html            |  3 +++
 5 files changed, 101 insertions(+), 26 deletions(-)
 create mode 100644 www/doc/privacy_data.html

diff --git a/www/css/blerg.css b/www/css/blerg.css
index 6624bc2..45a553f 100644
--- a/www/css/blerg.css
+++ b/www/css/blerg.css
@@ -361,3 +361,9 @@ h1, h2, h3 {
 table.help td {
 	padding: 2pt 8pt;
 }
+
+footer {
+	margin: 15pt;
+	font-size: small;
+	color: #333;
+}
diff --git a/www/doc/changelog.html b/www/doc/changelog.html
index b06e421..e340649 100644
--- a/www/doc/changelog.html
+++ b/www/doc/changelog.html
@@ -11,7 +11,24 @@
 The intent of this changelog is to give an overview of the major changes
 and fixes made to Blërg.  For a detailed changelog, see the git log.
 
-<a name="v1.7"><h2>Version 1.7 - released Wednesday, January 16, 2013
+<a name="v1.8"><h2>Version 1.8 - released Thursday, May 30, 2013</h2></a>
+
+<h3>Features Added</h3>
+<ul>
+<li>Passwords are now hashed with scrypt instead of lame old MD5. Source
+for scrypt 1.1.6 is embedded as it provides no readily usable
+library.</li>
+<li>Password formats are automatically upgraded upon login.</li>
+<li>Added new <a href="/doc/privacy_data.html">Privacy and Data
+  Policies</a></li>
+</ul>
+
+<h3>Editing</h3>
+<ul>
+<li>Minor edits to the documentation.</li>
+</ul>
+
+<a name="v1.7"><h2>Version 1.7 - released Wednesday, January 16, 2013</h2></a>
 
 <h3>World Turned Upside-Down</h3>
 <ul>
@@ -24,7 +41,7 @@ and fixes made to Blërg.  For a detailed changelog, see the git log.
 is whitespace ahead of it.</li>
 </ul>
 
-<a name="v1.6.3"><h2>Version 1.6.3 - released Thursday, January 19, 2012</h2>
+<a name="v1.6.3"><h2>Version 1.6.3 - released Thursday, January 19, 2012</h2></a>
 
 <h3>Features Added</h3>
 <ul>
@@ -37,7 +54,7 @@ is whitespace ahead of it.</li>
 responses</li>
 </ul>
 
-<a name="v1.6.2"><h2>Version 1.6.2 - released Sunday, January 15, 2012</h2>
+<a name="v1.6.2"><h2>Version 1.6.2 - released Sunday, January 15, 2012</h2></a>
 
 <h3>Features Deprecated</h3>
 <ul>
@@ -48,7 +65,7 @@ for a FastCGI version in the future, or maybe a new standalone version
 written using <a href="https://github.com/ellzey/libevhtp">libevhtp</a>.</li>
 </ul>
 
-<a name="v1.6.1"><h2>Version 1.6.1 - released Monday, November 7, 2011</h2>
+<a name="v1.6.1"><h2>Version 1.6.1 - released Monday, November 7, 2011</h2></a>
 
 <h3>Features Added</h3>
 <ul>
@@ -58,7 +75,7 @@ audio tag</li>
 Manojlovic</li>
 </ul>
 
-<a name="v1.6"><h2>Version 1.6 - released Monday, July 18th 2011</h2>
+<a name="v1.6"><h2>Version 1.6 - released Monday, July 18th 2011</h2></a>
 
 <h3>Features Added</h3>
 <ul>
@@ -75,7 +92,7 @@ their previous login.</li>
 used on a subpath.</li>
 </ul>
 
-<a name="v1.5"><h2>Version 1.5 - released Friday, March 4th 2011</h2>
+<a name="v1.5"><h2>Version 1.5 - released Friday, March 4th 2011</h2></a>
 
 <h3>Features Added</h3>
 <ul>
@@ -98,7 +115,7 @@ button works in more places</li>
 <li>Allow formatting metachars to be escaped with backslashes</li>
 </ul>
 
-<a name="v1.0"><h2>Version 1.0 - released Wednesday, February 9th 2011</h2>
+<a name="v1.0"><h2>Version 1.0 - released Wednesday, February 9th 2011</h2></a>
 
 <h3>Features Added</h3>
 <ul>
@@ -114,7 +131,7 @@ with hyperlinks</li>
 <li>Fixed tag accessibility issues for longer tags</li>
 </ul>
 
-<a name="v0"><h2>Version 0.ofuckreddit - released Thursday, Jan 13th 2011</h2>
+<a name="v0"><h2>Version 0.ofuckreddit - released Thursday, Jan 13th 2011</h2></a>
 
 <h3>Initial Release</h3>
 
diff --git a/www/doc/index.html b/www/doc/index.html
index 6bc071e..e98ef47 100644
--- a/www/doc/index.html
+++ b/www/doc/index.html
@@ -414,14 +414,15 @@ make the layers more efficient, or reduce the number of layers.
 </table>
 
 <p>Blërg does both by smashing the last two or three layers into one
-application.  Blërg can be run as either a standalone web server, or as
-a CGI (FastCGI support is planned, but I just don't care right now).
-Less waste, more throughput.  As a consequence of this, the entirety of
-the application logic that the user sees is implemented in the client
-app in Javascript.  That's why all the URLs have #'s &mdash; the page is
-loaded once and switched on the fly to show different views, further
-reducing load on the server.  Even parsing hash tags and URLs are done
-in client JS.
+application.  Blërg can be run as either a standalone web server
+(currently deprecated because maintaining two versions is hard), or as a
+CGI (FastCGI support is planned, but I just don't care right now).  Less
+waste, more throughput.  As a consequence of this, the entirety of the
+application logic that the user sees is implemented in the client app in
+Javascript.  That's why all the URLs have #'s &mdash; the page is loaded
+once and switched on the fly to show different views, further reducing
+load on the server.  Even parsing hash tags and URLs are done in client
+JS.
 
 <p>The API is simple and pragmatic.  It's not entirely RESTful, but is
 rather designed to work well with web-based front-ends.  Client data is
@@ -440,24 +441,24 @@ early in the design process that I'd try out mmaped I/O.  Each user in
 Blërg has their own database, which consists of a metdata file, and one
 or more data and index files.  The data and index files are memory
 mapped, which hopefully makes things more efficient by letting the OS
-handle when to read from disk (or maybe not &mdash I haven't benchmarked
-it).  The index files are preallocated because I believe it's more
-efficient than writing to it 40 bytes at a time as records are added.
-The database's limits are reasonable:
+handle when to read from disk (or maybe not &mdash; I haven't
+benchmarked it).  The index files are preallocated because I believe
+it's more efficient than writing to it 40 bytes at a time as records are
+added.  The database's limits are reasonable:
 
 <table class="statistics">
 <tr><td>maximum record size</td><td>65535 bytes</td></tr>
-<tr><td>maximum number of records per database</td><td>2<sup>64</sup> - 1 bytes</td></tr>
+<tr><td>maximum number of records per database</td><td>2<sup>64</sup> - 1</td></tr>
 <tr><td>maximum number of tags per record</td><td>1024</td></tr>
 <table>
 
 <p>So as not to create grossly huge and unwieldy data files, the
 database layer splits data and index files into many "segments"
-containing at most 64K entries each.  Those of you doing some quick math
-in your heads may note that this could cause a problem on 32-bit
-machines &mdash; if a full segment contains entries of the maximum
-length, you'll have to mmap 4GB (32-bit Linux gives each process only
-3GB of virtual address space).  Right now, 32-bit users should change
+containing at most 64K entries each.  Those of you doing some quick
+mental math may note that this could cause a problem on 32-bit machines
+&mdash; if a full segment contains entries of the maximum length, you'll
+have to mmap 4GB (32-bit Linux gives each process only 3GB of virtual
+address space).  Right now, 32-bit users should change
 <code>RECORDS_PER_SEGMENT</code> in <code>config.h</code> to something
 lower like 32768.  In the future, I might do something smart like not
 mmaping the whole fracking file.
diff --git a/www/doc/privacy_data.html b/www/doc/privacy_data.html
new file mode 100644
index 0000000..df2f65a
--- /dev/null
+++ b/www/doc/privacy_data.html
@@ -0,0 +1,48 @@
+<!DOCTYPE html>
+<html>
+<head>
+<title>Blërg Data and Privacy Policies</title>
+<link rel="stylesheet" href="/css/doc.css">
+</head>
+<body>
+
+<a name="privacy_policy">
+<h1>Blërg Privacy Policy</h1>
+</a>
+
+<h2>Blërg Doesn't Want Much Data</h2>
+
+<p>Blërg collects only the data necessary to create an account (username
+and password), and any data submitted via posting.  HTTP logs which
+contain your IP address, browser agent stringand any URLs visited as a
+consequence of using Blërg are kept for seven days then deleted.
+
+<h2>Blërg Doesn't Want To Use Your Data</h2>
+
+<p>User data is used only for the purposes of operating the site, i.e.
+to show your posts to the world.  We don't share your data with anyone
+through any other channels.
+
+<a name="data_policy">
+<h1>Blërg Data Policy</h1>
+</a>
+
+<h2>Blërg Doesn't Forget</h2>
+
+<p>There is currently no way to delete data on Blërg, so any information
+you post may exist on Blërg forever.  Be careful what you post.
+
+<h2>Blërg Isn't That Secure</h2>
+
+<p>Currently, all data transmitted to Blërg, including your username and
+password, are transmitted over unencrypted HTTP.  It is entirely
+possible for someone to view your credentials in transit.  We recommend
+that you don't use the same password on Blërg as you use elsewhere (but
+that's just good password policy).
+
+<p>Passwords are hashed server-side with <a
+href="https://www.tarsnap.com/scrypt.html">scrypt</a> with
+N=2<sup>14</sup>, r=8, p=1.
+
+</body>
+</html>
diff --git a/www/index.html b/www/index.html
index dd7292d..68df77a 100644
--- a/www/index.html
+++ b/www/index.html
@@ -16,5 +16,8 @@
 <script type="text/javascript">
 new blerg.Blerg().write();
 </script>
+<footer>
+<a href="/doc/privacy_data.html">Privacy and Data Policies</a>
+</footer>
 </body>
 </html>
-- 
2.25.1