Google AdWords sending me free money?
Sunday, September 24. 2017
If you own your company and happen to use any Google services (I do both), then you're very likely to be approached by Google's AdWords marketing. They are pitching you initial free credits to use for your ads. Since my business really doesn't rely on advertising, or marketing or anything of such nature, I typically ignore any approaches regardless who is contacting me.
Google has this approach, that they send you snail-mail and the letter will contain a credit-card sized laminated card contaning my business' name and a discount code to be used during registration. As there are nice € sums of money in them, I never threw any of those away. And it so happened, that since I kept ignoring Google's marketing machine, they just kept sending me those cards over and over again.
There is 1150,- € worth of free advertising in those.
You at Google:
Keep sending them, I'll keep collecting them. And amp up the values, I won't even flinch with your 150,- € coupons!
Go big! Go for 500,- € or even bigger!
Apple's new privacy policy against on-line ads
Monday, September 18. 2017
This is a rare event: somebody is actually improving my privacy and I don't have do do anything. Nice!
Apple is introducing intelligent tracking prevention technology in upcoming Safari 11. They're pretty radical in their cookie blocking, they're "deleting even first-party cookies if it's been more than 30 days since you interacted with the website that set the cookie". Naturally corporations depending on tracking you don't much like that, but Apple's response is: Tough luck, privacy comes first. So, it's natural that advertisers don't want you to use Safari or know how to make their tracking harder.
Safari 8, 9 and 10 will block 3rd party cookies as default. You can opt out of that, but it's just ridiculous. I strongly advice against that. Nobody really needs 3rd party cookies, they are never up to no good. Couple years back a Swedish web shop I frequently purchased movies from changed their on-line payment vendor and they actually used 3rd party cookies for the payment transaction. I took a pause over 2 years before doing business with them again. Their current payment system works correctly.
Firefox allows 3rd party cookies, but there is a setting:
Same thing with Chrome, it allows 3rd party cookies, but you can disable it from well hidden setting:
What's really cool with Safari 11, that they'll move tracking protection to the next level. There is a "special" treatment for well-known 1st party cookies too. This is top notch stuff and it outperforms most add-ons and extensions. Really nice!
Fedora 26: SElinux-policy failing on StrongSWAN IPsec-tunnel
Monday, September 4. 2017
SElinux is a beautiful thing. I love it! However, the drawback of a very fine-grained security control is, that the policy needs to be exactly right. Almost right won't do it.
This bite me when I realized, that systemd couldn't control StrongSWAN's charon - IKE-daemon. It worked flawlessly, when running a simple strongswan start
, but failing on systemctl start strongswan
. Darn! When the thing works, but doesn't work as a daemon, to me it has the instant smell of SElinux permission being the culprit.
Very brief googling revealed, that other people were suffering from that same issue:
- Bug 1444607 - SELinux is preventing starter from execute_no_trans access on the file /usr/libexec/stro
ngswan/charon. - Bug 1467940 - SELinux is preventing starter from 'execute_no_trans' accesses on the file /usr/libexec/strongswan/charon.
Others had made the same conclusion: it's a SElinux -policy failure. Older bug report was from April. That's a month before Fedora 26 was released! But neither bug report had a fix for it. I went to browse Bodhi and found out that there is a weekly release of selinux-policy .rpm
-file, but this hadn't gotten the love it desperately needed from RedHat guys.
Quite often self-help is the best help, so I ran audit2allow -i /var/log/audit/audit.log
and deduced a following addition to my local policy:
#============= ipsec_t ==============
allow ipsec_t ipsec_exec_t:file execute_no_trans;
allow ipsec_t var_run_t:sock_file { unlink write };
I have no idea if that fix is ever going to be picked up by RedHat, but it definitely works for me. Now my IPsec tunnels survive a reboot of my server.
Update 10th Sep 2017:
Package selinux-policy-3.13.1-260.8.fc26.noarch.rpm has following changelog entry:
2017-08-31 - Lukas Vrabec <lvrabec@redhat.com> - 3.13.1-260.8
- Allow ipsec_t can exec ipsec_exec_t
... which fixes the problem.
To test that, I dropped my own modifications out of local policy and tested. Yes, working perfectly! Thank you Fedora guys for this.
EPIC 5 Fedora 26 build
Sunday, September 3. 2017
Not many people IRC anymore. I've been doing that for the past 23 years and I have no intention of stopping. For other IRC fans, I recommend reading Wikipedia article about EFnet. It contains a very nice history of IRC networks since 1990. For example I didn't realize that our European IRC is a split of original EFnet. Back in 1994 we really didn't have any names for the networks, there was just "irc".
Ok, back to the original topic. My weapon of choice has always been EPIC. Given the unpopularity of IRC-clients, for example Fedora Linux has a legacy EPIC 4 in it and I've been running EPIC 5 myself for past years, so I had to do some tinkering to get that properly packaged and running on my own box.
Latest version of EPIC5 is 1.2.0, but it won't compile on Fedora 26 as EPIC5 assumes to have OpenSSL 1.0.2 libraries and Fedora 26 has OpenSSL 1.1.0. The options are to either drop SSL-support completely or patch the source code for 1.1.0 support. I chose the latter.
Fedora 26 binary is at: http://opensource.hqcodeshop.com/EPIC/5/RPMS/epic5-1.2.0-1.fc26.x86_64.rpm
source is at: http://opensource.hqcodeshop.com/EPIC/5/SRPMS/epic5-1.2.0-1.fc26.src.rpm
Any comments are welcome!