Yahoo Groups slides further down the spam source slope

I've written about Yahoo Groups' spam problem before and the situation has not gotten any better since 2014. Insteadit's gotten worse, as I tweeted :

Yahoo Groups is now refusing to accept bounce messages for theirmessages, if you had any remaining doubt that it was a spam operationnow.

You can pretend to be a legitimate mailing list operation even ifyou spew tons of spam with individualized MAIL FROM origin addresses(which real mailing list software does too). But this pretense falls


Getting a Yubikey 4 working on Ubuntu 14.04 LTS and other older Linuxes (in PIV mode)

Suppose, not entirely hypothetically, that you have some brand newYubikeys that you're going to use in PIV mode for SSH keys .Everything initially goes well in current Linux distributions like,say, Fedora 24 ( with a hiccup or two ) andUbuntu 16.04, but then you plug one into an Ubuntu 14.04 machineand all of a sudden nothing works. Not only does yubico-piv-tool fail to be able to talk to the Yubikey to do things like


I assume that it's always possible to compromise our security somehow

It can be very easy to get into a stark, binary mindset when youthink about security and security issues, one where anything thatintroduces a potential insecurity must be resisted with full force.This mindset is a mistake, because real security almost alwaysinvolves tradeoffs and a balance of risks, but it can be easy tofind yourself in it. One of my tools for resisting it is to alwaysassume that we can be compromised by a determined attacker who isspecifically targeting us.

This sounds silly and obvious and surely


Security often involves not doing things

Here is something obvious that I feel like stating outright today:

Increasing security often involves not doing things, even whenthey're attractive things .

Security is in part about saying no. It is not just 'no, thatintroduces an obvious security exposure', which is in many ways theeasy case; it is also various forms of 'no, that adds too muchrisk'. This means that security is partly about not doing things,and making security decisions is partly about reluctantly decidingnot to do stuff


The other reason why I've wound up not interested in firewall managers

In a comment on my previous entry on not using firewall managers , Durval Menezes mentioned:

The real problem IMHO with "magical" solutions is when the "magic"suddenly stops working (specially when it falls in some subtle, hardto detect way) and, as it made it "easy" to start with, you have nocontrol nor/nand internal knowledge of it to troubleshoot (or worse,even detect that it has failed in the first place).

Now that it's been brought up,


Why we have multiple wireless networks around here

I mentioned on Twitter that Iwished my iPhone could be set to strongly prefer one configuredwireless network over another in situations where more than one wasavailable, to the point where it would switch from a lower-preferencenetwork to a higher-preference one. At this point, some of you mayask the obvious and perfectly sensible question of why we even havemore than one wireless network available at once.

It is not, as you might first guess, because the various networksrun over different wireless access points that


Admitting that I have have a non-simple firewall setup

When I talked about why I'm interested in nftables I mentioned in passing that I'd looked at FireHOL out of dissatisfaction with mycurrent firewall stuff. In comments James mentioned settling on Shorewall and that plus a Twitterconversation got me to take a look at it too. My gut level reaction to Shorewallmade me sit back and think about the whole situation with my firewallrules, and the result is that I've come to the simple and probablyobvious conclusion that I don't have a simple firewall


Web pages versus APIs, or my views on handling 'bad' requests

In a comment on my entry on giving up on being cautious in the modernweb world , Alan wrote, in part:

I would claim POST to a GET-only URL deserves an error, since theserver is potentially throwing away a whole message. [...]

This is absolutely true. In fact, we can be more general; if youaccept a POST request that you don't know how to handle, you arethrowing away the requester's information (either in the POST body or


Caution is a mistake in modern web servers and apps

When I wrote DWiki (the code behind Wandering Thoughts ),I made it pretty cautious and conservative about what it acceptedinstead of rejecting, and how it handled any number of things. POST s to GET -only URLs, or GET s of POST -only URLs? Rejectedwith errors. Unexpected query parameters on GET s? Rejected withan error. An If-Modified-Since time that didn't exactly match theresource's current modification timestamp? Well, better declarethat a conditional GET miss and


I suspect that browsers are not fully prepared for bad CAs

Yesterday I mentioned that I thoughthow slowly the browsers were moving on the WoSign/StartCom issuewas a sign of real weaknesses in the ability of browsers to dealwith bad CAs. Today it's time to explain that little cryptic remark,but first, a necessary disclaimer: I'm an outsider here and so I'mat least partly speculating.

So first, let's establish how the browsers are being slow. BothChrome and Mozilla have announced cutoff dates for WoSign andStartCom certificates that will be