It had to be shortened to 100 words. This also more accurately reflects what
I will be talking about; it will be a slower pace than I had originally anticipated,
and will focus a bit more on some core philosophical concepts. But it will still
be interesting to both hackers and non-technical users.
I noticed a lot of odd `/rss.xml' requests in my 404 log. As it turns out,
it was my fault. This both fixes it and adds a redirect in case someone
tries to do this manually. I suppose that'd be convenient.
Wow. I had wanted to spend less than an hour on a response, and instead I
wound up writing my largest article since the NSA revelations and
GHS. Hopefully others find this useful.
I've been sitting on this for weeks because I didn't have the time to finish
final proofreading and changes. I need to release this before I sit on it
for another couple; I have to start working on my LP2019 talk soon.
* post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md:
New post.
* src/papers.rec: Add post to top.
I'm still debating whether to include the full text of the post within the
RSS feed, since some of them may be substantial (like the one I'll be
posting soon that I've been sitting on for a couple weeks because I'm too
busy/lazy to do final editing).
* src/rss.sh: Add "(Read full post)" link.
The inlined CSS intended to make the stylesheet applicaton less jarring on
slow connections was placed _after_ `style.css', which was causing it to
take precedence over the mobile layout. Silly mistake, and not good. And
it went unnoticed for too long; I didn't visit my own website on mobile for
a bit.
Sorry, mobile people!
* src/header.tpl.htm (head): Move style.css link below inline style.
This increases the headings, gives them slightly larger margins, decreases
the font size for footnotes, decreases the line-height, and lightens the
weight of the font. I think this makes it easier to eyeball the different
sections (especially in the article I will be publishing shortly), and
further helps to emphasize that the footnotes are subservient to the text.
The idea here is to provide as little CSS as is sensible for the initial
page load to be styled in a layout similar to the final layout. This
initial styling may be briefly visible on a slow conection.
Slow connections can happen for a variety of reasons. For example, I'm a
Tor user, and connection speeds vary. Mobile connection speeds can also
vary wildly.
This adds a few hundred bytes, but I was able to cut it down quite a bit,
and I don't find this to be unreasonable relative to the other data on
each page.
I only noticed this issue because my work computer has IE11 installed. I will not be
supporting it. Edge works just fine and IE is just about extinct, finally.
Of couse, I recomend using a free/libre browser.
This automates creation of the header and footer. Previously I modified
them manually and they got out-of-sync.
This is deployed to a different location on my webserver, even though the
public route is `/projects'.
Rather than displaying the hash separately, this just makes the date a link
to the source code. Until I display a modification date, this will also
make it easy to see the history of the file.
This website honors the user's default font settings (both to be kind and
for accessibility reasons). Consequently, the responsive layout is based on
character units (ch) rather than pixels.
This goes back to Open Sans, which is what I was using previously.
I really like Source Sans Pro. Unfortunately, the font rendered far too
small relative to other sans-serif fonts, which caused an unpleasent
experience for both slow page loads (e.g. over Tor or slower
connections) and for users with web fonts disabled (e.g. via NoScript).
Further, the font is huge: the WOFF is over 100KiB per font, and I was
using regular and light versions. Open Sans, in contrast, is <20KiB per
font, allowing me to use Regular, Light, and SemiBold and still be about
half the size of the single Source Sans Pro Regular.
As a bonus, users may also already have Open Sans installed on their
system.
I settled with WOFF instead of WOFF2 for browser support.
The site now looks pretty close on fallback, which is good. For
example, I use DejaVu Sans as my default font, and it even has a Light
version that renders correctly.
As with all resources on my site, I host this from my own domain rather
than via Google's servers. That means that the font won't be cached for
users when they first visit the site, but that's okay---privacy is more
important.
I should note that, since I use NoScript, I almost never load web fonts
for other sites. But I still wanted to try to provide a consistent look
across systems for those who do wish to load fonts.
We have two sitautions to account for:
1. Old posts had both uppercase and lowercase letters in slugs; and
2. Some ids changed.
Lighttpd can't convert to lowercase and having a bunch of separate redirects
in my webserver configuration for the id changes is messy. So, this script
is intended to be called only when a post contains an uppercase character in
the path.
I had wanted to avoid _any_ sort of dynamic scripts. Oh well.
All other redirects are handled in the websevrer configuration (which isn't
part of this repo atm).
Rather than having Pandoc generate the id, which has the potential to change
over time and cause 404s, let's just generate the slug from the filename so
that the ids will never change. This also solves the awkward question of
what the filename should be, since it was previously something arbitrary.
This mass rename was accomplished via this simple shell script:
for p in *.meta; do
slug=$( recsel -P slug "$p" | xargs basename )
mv -v "${p/.meta/.md}" "${p:0:10}-$slug.md"
done
with minor manual tweaks where I saw fit. Of course, now I have some pretty
long filenames, which is undesirable.
The next step is to compare it with the slugs currently on mikegerwitz.com
and make them match. That's the next commit, and should be pretty simple.
I didn't originally intend for all of this to be in a single commit. But
here we are. I don't have the time to split these up more cleanly; this
project is taking more time than I originally hoped that it would.
This is a new static site generator. More information to follow in the
near future (hopefully in the form of an article), but repo2html is now
removed. See code comments for additional information; I tried to make it
suitable as a learning resource for others. It is essentially a set of
shell scripts with a fairly robust build for incremental generation.
The site has changed drastically, reflecting that its purpose has changed
over the years: it is now intended for publishing quality works (or at least
I hope), not just a braindump.
This retains most of the text of the original pages verbatim, with the
exception of the About page. Other pages may have their text modified in
commits that follow.
Enhancements to follow in future commits.
This was a wholly manual effort since Pandoc does not have an AsciiDoc
reader (only writer). Fortunately, Pandoc's Markdown features enabled me to
keep the style essentially the same.
I made no changes to the original text other than changes to markup, so this
remains faithful to the original. Any changes to the text will be made in
future commits so that the diff can be clearly observed.
This could use more work (e.g. getting rid of inline links to make the
Markdown file more readable), but otherwise this is in a good enough state
for now.
This was considerable effort, and took a bit more time than I had
hoped. While newer posts were written with Markdown, previous ones were
writen with my own Markdown-like formatting, but they had enough differences
that it was quite an effort to get things updated. I also checked the HTML
output of each, though I didn't read every article in detail.
Some of these were more substantial than others; National Uproar, for
example.
These conversions were markup translations: the actual text remains
unchanged, except in one minor instance to add text for the sake of
providing some text to hold a link to a quote. Any changes to post text
will happen in future commits so that the diffs are clearly visible.
[Tor][] is a privacy and anonymity tool that [helps users to defend
themselves][tor-about] against traffic analysis online.
Some people, like me, use it as an important tool to help defend against
[various online threats to privacy][sapsf].
[Others use it][tor-users] to avoid censorship,
perhaps by the country in which they live.
Others use it because their lives depend on it---they
may live under an oppressive regime that forbids access to certain
information or means of communication.
Unfortunately, some people also hide behind Tor to do bad things,
like attack websites or commit fraud.
Because of this,
many website owners and network administrators see Tor as a security threat,
and choose to block Tor users from accessing their website.
But in doing so,
you aren't just keeping out some of the malicious users:
you're also keeping out those who [use Tor for important, legitimate
reasons][tor-users].
Malicious users have other means to achieve anonymity and often have the
skill and understanding to do so.
But average Tor users aren't necessarily technology experts,
and certainly don't have the extra (often maliciously-acquired) resources
that bad actors do,
so they are disprortionally affected by blocks.
A particularly unsettling problem I often encounter is that a website will
outright prohibit access by Tor users _even on read-only resources like
articles or information_.
I've even seen this on informational resources on United States Government
domains!
Blocking access to interactive website features---like
posting comments or making purchases---can
be understandable,
or maybe even necessary sometimes.
For example,
Wikipedia prohibits page edits over Tor.
But Wikipedia _does not block reading_ over Tor.
If you are considering threats that may mask themselves behind Tor and you
are running a blog, news site, or other informational resource,
please, consider how your actions [may affect innocent
users][tor-users].
Allow users to read over Tor,
even if you decide to prohibit them from interacting.
For users of Tor who do find themselves stuck from time to time:
I will often prepend `https://web.achive.org/` to the URL of a page that
is blocked,
which allows me to view the page in the Internet Archive's [Wayback
Machine][].
For example,
to view my website in the Wayback Machine,
you'd visit `https://web.archive.org/https://mikegerwitz.com/`.
[Tor]: https://www.torproject.org/
[tor-about]: https://www.torproject.org/about/overview.html.en#whyweneedtor
[tor-users]: https://www.torproject.org/about/torusers.html.en
[sapsf]: /talks/sapsf
[Wayback Machine]: https://web.archive.org/
It's already time to start thinking about LibrePlanet 2019, which will be
March 23--24 in the Greater Boston Area in MA:
[https://libreplanet.org/2019/]()
This is the one event that I must make it to each year, and I encourage
everyone to attend and see the faces of many that are at the heart of the
free software community.
Consider [submitting a session][submit]! Or, if you can't make it but plan
on watching online, maybe help someone else attend by [contributing to the
travel fund][travel-fund]. The call for sessions ends October 26th.
I'll be attending again this year, and I plan on submitting a session
proposal. I won't have the time to do [my 100+hr research talks like the
past couple years][talks], so maybe I'll fall back on something more
technical that I won't have to research.
It's still a ways off, but if you do plan on attending, do let me know so I
can say hello!
[submit]: https://my.fsf.org/lp-call-for-sessions
[travel-fund]: https://my.fsf.org/civicrm/contribute/transact?reset=1&id=60
[talks]: /talks/
Mike Gerwitz