antipaucity

fighting the lack of good ideas

pi-hole revisited

Back in November, I was really up on Pi-hole.

But after several more months of running it … I am far less psyched than I had been. I’m sure part of that is having gotten better internet services at my house – so the impact of ads is less noticeable.

But a major part of it is that Pi-hole is just too aggressive. Far far too aggressive. Aggressive to the point that my whitelist was growing sometimes minute-by-minute just to get some websites to work.

Is that a problem with the site? No doubt somewhat. But it’s also a problem of blacklists. When domains and IPs are just blanket refused (and not in a helpful way), you get broken experience.

Pi-hole has also gone to a quasi-hijack approach: when a domain has been blocked, instead of it just silently not working, it now returns a message to contact your Pi-hole admin to update the block lists.

I hate intrusive ads as much as the next person .. but that shouldn’t mean that all ads are blocked. I have unobtrusive ads on a couple of my domains (this one included).

But even with Pi-hole, not all ads are blocked.

Part of that is due to the ever-changing landscape of ad servers. Part of it is due to the inherent problems with the blacklist/whitelist approach.

Content creators should be entitled to compensation for the efforts (even if they voluntarily choose to give that content away). Bombarding visitors with metric buttloads of advertising, however, makes you look either desperate, uncaring, or greedy.

The current flipside to that, though, is the pay-wall / subscription approach. Surely subscriptions are appropriate for some things – but I’m not going to pay $1/mo (or more) to every site that wants me to sign-up to see one thing: just today, that would’ve encumbered me with over $100/mo in new recurring bills.

Maybe there needs to be a per-hour, per-article, per-something option – a penny for an hour, for example (which, ftr, comes out to a monthly fee of about $7)- so that viewers can toss some scrilla towards the creators, but aren’t permanently encumbered by subscriptions they’ll soon forget about (though, of course, that recurring subscription revenue would surely look enticing to publishers).

As with the per-song/episode purchase model that iTunes first made big about 15 years ago, you could quickly find out what viewers were most interested in, and focus your efforts there. (Or, continue focusing your efforts elsewhere, understanding that less-popular content will not garner as much revenue as popular content will).

Imagine, using my example of $0.01/hr, how much more engagement you could end up garnering while visitors are actively on your site! A penny is “nothing” to most people – and probably just about all who’re online. Maybe you’ll have a handful of people “abusing” the system by opening a thousand pages in new tabs in their hour … but most folks’ll drop the virtual coin in the nickelodeon, watch the video / read the page / whathaveyounot, and move on about their day.

And not everyone will opt for the charge model. Sites that do utilize it can have some things marked “free” or “free for the next 24 hours” or “free in 7 days” or whatever.

Ad companies like Google could still work as the middleman on handling transactions, too – any time you visit per-X content, there could be a small pop-up that indicated you’d be withdrawing Y amount from your balance to view the site (I’m sure there’ll be competition in the space, so PayPal, Facebook, Stripe, Square, etc etc can get in on the “balance management” piece). And at the end of whatever period (day, week, month), Google can do a mass-settle of all the micropayments collected for each site from each visitor (with some percentage off the top, of course).

No ads. You’d actually Get What Your Pay For™, and issues like the recent Admiral thing would go in a corner and die.

update: keeping your let’s encrypt certs up-to-date

Last year I posted a simple script for keeping your Let’s Encrypt SSL certificates current.

In conjunction with my last post sharing the “best” SSL configs you can use with Apache on CentOS, here is the current state of the cron’d renewal script I use.

systemctl stop httpd.service
systemctl stop postfix
~/letsencrypt/letsencrypt-auto -t -n --agree-tos --keep --expand --standalone certonly --rsa-key-size 4096 -m user@domain.tld -d domain.tld
# you can append more [sub]domains to a single cert with additional `-d` directives ([-d otherdomain.tld [-d sub.domain.tld...]])
#...repeat for every domain / domain group
systemctl start httpd.service
systemctl start postfix

I have this script running @weekly in cron. You should be able to get away with doing it only every month or two .. but I like to err on the side of caution.

I’m stopping and starting Postfix in addition to httpd (Apache on my system) for only two reasons: first, I am using some of the LE-issued certs in conjunction with my Postfix install; second, because I don’t know if Dovecot and my webmail system need to make sure Postfix is restarted if underlying certs change.

ssl configuration for apache 2.4 on centos 7 with let’s encrypt

In follow-up to previous posts I’ve had about SSL (specifically with Let’s Encrypt), here is the set of SSL configurations I use with all my sites. These, if used correctly, should score you an “A+” with no warnings from ssllabs.com. Note: I have an improved entropy package installed (twuewand). This is adapted from the Mozilla config generator with specific options added for individual sites and/or to match Let’s Encrypt’s recommendations.

Please note: you will need to modify the config files to represent your own domains, if you choose to use these as models.

[/etc/httpd/conf.d/defaults.conf]

#SSL options for all sites
Listen 443
SSLPassPhraseDialog  builtin
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
Mutex sysvsem default
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom  1024
# requires twuewand to be installed
SSLRandomSeed startup exec:/bin/twuewand 64
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 1024
SSLCryptoDevice builtin
# the SSLSessionTickets directive should work - but on Apache 2.4.6-45, it does not
#SSLSessionTickets       off
SSLCompression          off
SSLHonorCipherOrder	on
# there may be an unusual use case for enabling TLS v1.1 or 1 - but I don't know what that would be
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLOptions +StrictRequire
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

#all unknown requests get domain.tld (over http)
<VirtualHost *:80>
    DocumentRoot /var/html
    ServerName domain.tld
    ServerAlias domain.tld *.domain.tld
    ErrorLog logs/domain-error_log
    CustomLog logs/domain-access_log combined
    ServerAdmin user@domain.tld
    <Directory "/var/html">
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>
</VirtualHost>

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/javascript text/css text/php

[/etc/httpd/conf.d/z-[sub-]domain-tld.conf]

<Virtualhost *:80>
    ServerName domain.tld
# could use * instead of www if you don't use subdomains for anything special/separate
    ServerAlias domain.tld www.domain.tld
    Redirect permanent / https://domain.tld/
</VirtualHost>

<VirtualHost *:443>
    SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
# if you put "fullchain.pem" here, you will get an error from ssllabs
    SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem
    DocumentRoot /var/www/domain
    ServerName domain.tld
    ErrorLog logs/domain-error_log
    CustomLog logs/domain-access_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    ServerAdmin user@domain.tld

# could put this in defaults.conf - I prefer it in each site config
    SSLEngine on

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

    <Directory "/var/www/domain">
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>

</VirtualHost>

I use the z....conf formatting to ensure all site-specific configs are loaded after everything else. That conveniently breaks every site into its own config file, too.

The config file for a non-https site is much simpler:

<VirtualHost *:80>
    DocumentRoot /var/www/domain
    ServerName domain.tld
    ServerAlias domain.tld *.domain.tld
    ErrorLog logs/domain-error_log
    CustomLog logs/domain-access_log combined
    ServerAdmin user@domain.tld
    <Directory "/var/www/domain">
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>
</VirtualHost>

If you’re running something like Nextcloud, you may want to turn on Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" in the <VirtualHost&gt directive for the site. I haven’t decided yet if I should put this in every SSL-enabled site’s configs or not.

vampires vs zombies

A few years ago I wrote about why I like good vampire and zombie stories.

I had an epiphany this week related to that, that I thought you’d all find interesting.

If vampires exist, zombies can not exist [long] in the same universe. Why? Because they’d be eliminating the only source of food for the vampires. And since vampires are, more or less, indestructible (at least to the wiles of marauding zombies), when they eliminated zombie outbreaks, they’d do it quickly and efficiently – and, most likely, quietly.

wordpress plugins i use

As promised last time, I now have a page dedicated to the WordPress plugins I use.

Check it out, here.

a couple months late – but my prediction was pretty close

Tesla’s Model 3 is debuting at $35,000.

That is distinctly in the range of most “normal” people to obtain.

It should be shipping sometime in 2017. I’d buy one.

more ad blocking extensions

The list of ad blocking extensions I have installed has grown.

Add to the previous two these two: