Standardize font sizes and heading tags (<h1>-<h6>) to be more
consistent across the site.
Changes:
* Introduce font size CSS variables and start replacing hardcoded font
sizes with standard sizes.
* Change header tags to use only one <h1> per page. One <h1> per page is
recommended for SEO purposes. Usually this is for the page title, like
in forum threads or wiki pages.
* Standardize on <h2> for section headers in sidebars and <h3> for
smaller subsection headers. Don't use <h4>-<h6>.
* In DText, make h1-h4 headers all the same size. Standard wiki style is
to ignore h1-h3 and start at h4.
* In DText, make h4-h6 the same size as the h1-h3 tags outside of DText.
* In the tag list, change the <h1> and <h2> tag category headers to <h3>.
* Make usernames in comments and forum posts smaller. Also change the
<h4> tag for the commenter name to <div class="author-name">.
* Make the tag list, paginator, and nav menu smaller on mobile.
* Change h1#app-name-header to a#app-name-header.
Fix a couple security issues related to dmail permalinks. Dmails have a
permalink that you can give to a Mod to let them read the dmail. This is
done with a key param that grants access when the dmail is opened by
another user. The key param had several problems:
* The key contained a full copy of the message's title and body encoded in
base64. This meant that anyone given a dmail permalink could read the
full dmail just by decoding the key in the link, without even having
to open the link.
* The key was derived from the dmail's title and body. If you knew or
could guess a dmail's title and body you could open the dmail. One
case when this was possible was when sending dmails. You could send
someone a dmail, take the permalink from your sent copy of the dmail,
then increment the dmail id to open the receiver's copy of the dmail.
Since the sent copy and the received copy both had the same title and
body, they both had the same dmail key. This let you check whether a
person had read your dmail, and what time they read it at.
* The key verification was done with an insecure string comparison
rather than a secure constant-time comparison. This was potentially
vulnerable to timing attacks.
* Opening a dmail belonging to another user would mark it as read for them.
The fix to all this is to use the dmail's id as the key instead of the
dmail's title and body. This means that old permalinks no longer work.
This is unavoidable given the issues above.
Other changes:
* The name of the 'Permalink' link is now 'Share'.
* Anyone with the 'Share' link can view the dmail, not just Mods.
* Add ability to report dmails.
* Enable reports for comments, forum posts, and dmails.
* Allow Members to send reports.
* Don't allow users to report the same thing twice.
Few people used dmail filters (~900 users in 5 years) and even fewer
used them correctly. Most people used them to try to block dmail spam,
but usually they either blocked too much (by adding common words that
are present in nearly all dmails, causing all mails to them to be
filtered) or too little (blocking specific email addresses or urls,
which usually are never seen again after the spammer is banned).
Nowadays the spam detection system does a better job of filtering spam.
Removed IP addresses from comments and from most other listing pages.
IPs take up a lot of space in many places (especially IPv6 addresses),
and in most of these pages they're rarely useful for catching
sockpuppets.
Fineprint text was variously styled with `.info`, `.tn`, `.hint`, or
`.cost-footnote` css classes. Standardize on `.fineprint` instead. Use
`.hint` only for form hints and `.tn` only for <tn> tags in translation
notes.
Incidentally changes the font size of form hints to 0.8em (was 0.7em)
and the color of fineprint to #888 (was #AAA or #666).
Sends automated dmails from `Danbooru.config.system_user`, rather than
whichever user is performing the action happens to be (usually User.admins.first).
Also adds a notice in the view that the dmail was automated.
