table.help td {
padding: 2pt 8pt;
}
+
+footer {
+ margin: 15pt;
+ font-size: small;
+ color: #333;
+}
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>
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>
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>
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>
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>
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>
<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>
<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>
</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 — 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 — 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
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 — 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 — 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
+— 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.
--- /dev/null
+<!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>
<script type="text/javascript">
new blerg.Blerg().write();
</script>
+<footer>
+<a href="/doc/privacy_data.html">Privacy and Data Policies</a>
+</footer>
</body>
</html>
projects / blerg.git / commitdiff