You can mount Linux Ext or LUKS disks on Mac, Windows!

This is exciting! I’ve been looking for a disk format that works seamlessly across Mac, Windows, and Linux.  Something like a USB or disk image that mounts on all three desktop platforms.

The obvious choice is exFAT, but what if I want a modern disk format with journaling for data safety?

Ext4 is one option, although it used to be read-only on Macs (see Mounting Ext2/Ext3/Ext4 USB Flash Drives on Mac: Read Only Success). Maybe things have gotten better in the last 10 years?

And what if I want disk encryption?

VeraCrypt with an exFAT disk works: see Sharing TrueCrypt USB volume on 3 platforms: Mac, Windows, Linux.

But what if you want both encryption and a modern file system? I couldn't find a solution to this, until I found… 

 

linsk

In summary, linsk is an easy way to run an Alpine Linux VM using qemu to mount a disk within it, and then share that disk back out to your local host machine via a networking protocol.

So now you can mount an Ext4 disk, or a LUKS encrypted Ext4 disk, on your Mac or Windows machine!

The usage notes are so good, you can just look there for how to install and use.

Here's a quick use reference, more for my own reference than anything

How to use linsk to mount a Ext4 disk within a LUKS encrypted disk on macOS

Note: If you're not me, please read the linsk documentation first and understand it completely before proceeding below!  This assumes you installed linsk correctly, including qemu!


1. With the disk plugged into your Mac, make sure to unmount all volumes that macOS auto-mounts!!!

Warning Danger Caution Danger: If you don't unmount all volumes first, the following may delete, nuke, and destroy all your disk data.  macOS likes to repeatedly auto-mount any volume it sees, so after every step below, make sure to unmount those volumes again!!!  You'll see warnings to this effect from linsk in the terminal as well.


2. In Terminal, run: $ diskutil list

Find your disk and note its path: e.g. `/dev/diskX`

The value of `X` in `diskX` may change every time your Mac encounter the disk!

However, the LVM group/volume/luks-container names within that disk should be stable (unless intentionally changed), so in the future, you can skip down to the `linsk run` step 5 below if you're just re-mounting the same volume.


3. Find the LUKS volume to mount within diskX.  Run: $ sudo linsk ls dev:/dev/diskX

Note the `vda` drive you'd see are the system drives within Alpine Linux, so ignore those.

For this example, suppose: `vdb1` is the `crypto_LUKS` volume you're interested in.


4. Find the Ext4 volume inside the LUKS volume by running: $ sudo linsk ls dev:/dev/diskX --luks-container vdb1

Now suppose that `cryptcontainer` is the ext4 volume you want to mount.


5. Mount the ext4 volume. Run: $ sudo linsk run dev:/dev/diskX --luks-container vdb1 mapper/cryptcontainer


6. Alternatively, mount the ext4 volume and open a debug shell.  Run: $ sudo linsk run --debug-shell dev:/dev/diskX --luks-container vdb1 mapper/cryptcontainer

This will mount that volume and open a shell within the Alpine Linux VM so you can do whatever you want to that disk volume from within Linux.  Good for changing disk ownership or permissions as needed so your Mac can access it.


7. Mount the volume from macOS.

You can use Cmd+k to connect to the network volume that linsk / Alpine Linux sets up for you locally.

You can also use the Mac Terminal.  Run: $ mount_afp -i -o noowners afp://linsk@127.0.0.1:9000/linsk /Path/to/mountpoint

`sudo` is not needed and unhelpful here!

You might find the folders in the mounted volume do not have the right permissions for you to open them up.  You might try using `sudo chown` or `chmod`, etc., and find they don't work to fix this.  You might try `umask` on your Mac, and find they don't work.

If it's your own disk you want access to, you might as well just tell linsk to open up a debug shell into the Alpine Linux VM and change the permissions on the disk from there.

i.e. Run: $ sudo linsk run --debug-shell dev:/dev/diskX --luks-container vdb1 mapper/cryptcontainer

Then use the Linux chown/chmod tools as needed.

Remember Git passwords securely

Typing your password again and again when using git with remote repo is tiring.

Git will integrate with your OS-level password storage easily enough though.

Macs

I'm under the impression that on Macs, it just works.  It's built into git to interface with Mac's Keychain service.

Or else just install Git-Credential-Manager-for-Mac-and-Linux from Microsoft.  You'll need Homebrew, which is a great package manager for Macs for various development tools.  Then follow the instructions: it's super easy.

Windows

Super easy.  Just download and install the .exe for Git-Credential-Manager-for-Windows from Microsoft.

Linux

There's 3 possibilities:

use Git-Credential-Manager-for-Mac-and-Linux

You can install Git-Credential-Manager-for-Mac-and-Linux from Microsoft.  You'll need Linuxbrew, a package manager I've never heard of before today.  Then follow the instructions: it's looks easy.

But this is not my favorite option because:

1. never heard of Linuxbrew
   
   
2. MS Git-Credential-Manager sends telemetry to Microsoft.  Not much telemetry data, and I'm trusting of MS more or less, but if you're using Linux, I'm going to guess you might see "telemetry" and "MS" and wonder why it's needed for using Git.
   
   
3. someone's tried it a year ago and it didn't work

use Libsecret (best option)

It's 3 lines of commands to run:

sudo apt-get install libsecret-1-0 libsecret-1-dev
sudo make --directory=/usr/share/doc/git/contrib/credential/libsecret
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

This saves your credentials encrypted in ~/.local/share/keyrings.

Yes, you're downloading and compiling it yourself as it's not built-in... in 2020. Crazy.  But is apparently still The Way to go with Ubuntu or Lubuntu 19.10.

Libsecret should interact with the OS level password store.  On Ubuntu, that would be gnome-keyring.  If you need to manage the keys stored by gnome-keyring, you'll need to install another tool like the GUI utility Seahorse:

sudo apt-get install seahorse

use the built-in store (totally insecure and NOT encrypted)

Totally built-in.  Nothing to install.  One line to set up:

git config --global credential.helper store

It stores your passwords in PLAIN text in a file in your home directory.  Don't do this.  Anyone can read your password.  I can read your password.  So don't do this.

VeraCrypt download: how to verify its PGP signature

Important Consideration:  Be sure to know your way around Bash in the terminal, and understand the concepts around GPG / PGP signatures, before using the instructions below.

These instructions are not intended for you if you don't know e.g. what a PGP signature verification is really for.

The steps here is really just a quick reference for you if you already know how to make GnuPG work, but maybe you don't remember the exact steps because, like me, you use it maybe once every 5 years... so you just need a quick reminder.

For better or more detailed instructions: please look for the clear explanation on how to verify downloads from VeraCrypt's own official download page (here's the direct link to it).

Note that VeraCrypt has moved their website!
They've moved their website from the old Codeplex page to the new download page here: https://www.veracrypt.fr/en/Downloads.html

VeraCrypt is apparently sponsored by IDRIX (https://www.idrix.fr) and you can verify the new PGP signature/key from them too: https://www.idrix.fr/Root/content/category/7/32/60/

Their open source development has moved to GitHub where you can see when PGP signature/key update occurred: https://github.com/veracrypt/VeraCrypt/commit/3e25b07646fdb5f01f48da329b91b0553f54a396

On Macs
Make sure Homebrew is installed (or else you can install these yourself from source).  Then in the terminal, you can use these commands to install GnuPG and GPG:

brew install gnupg
brew install gpg2

Next, get VeraCrypt's PGP key ID from:
https://www.idrix.fr/Root/content/category/7/32/60/

It's probably a good idea to cross-reference different websites to ensure the PGP key you got is the right one.  There's a few links above to get you started if you want to do this.

Next, in the terminal, run the following command --- you should make sure the key I wrote below is in fact the VeraCrypt PGP Key ID you got from the link above (and do note the PGP signature/key has changed since version 1.22, in case you're verifying an older version):

gpg --recv-keys 0x680D16DE

That should import the public key and say "VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393)" etc.  

Then run the following command in the terminal --- again, you should make sure the key I wrote below is in fact the correct and official VeraCrypt PGP Key ID:

gpg --fingerprint 0x680D16DE

That should display the key fingerprint in the terminal, which you should compare and ensure is the same as the key fingerprint that's posted on:
https://www.idrix.fr/Root/content/category/7/32/60/
and on:
https://www.veracrypt.fr/en/Digital%20Signatures.html 

Next step in verifying your download, run the following in the terminal for your downloaded version of the files:

gpg --verify veracrypt-1.23-setup.tar.bz2{.sig*,}

Obviously, I'm verifying version 1.23 here.  If you're looking at a different version, you should figure out how to modify this command above to verify whatever you downloaded.

The command above should cause a verification message to be displayed in the terminal.

That verification message should say the signature used key ID 0x680D16DE  --- again, you should make sure the key displayed is in fact the correct and official VeraCrypt PGP Key ID!

Alternatively, that message may state that the primary key fingerprint is 5069A233D55A0EEB174A5FC3821ACD02680D16DE --- this should match the correct and official fingerprints found from the links above!

And it should also say the signature is a "Good signature" from the VeraCrypt Team.

That's it!

If during any of the above steps, an ID or fingerprint doesn't match, then something terrible has happened and it's probably a signal that the verification has failed (or some command was used incorrectly).


On Linux or Windows

Similar instructions apply for Linux, but install GnuPG and GPG from your system's package management system instead.

You can see similar instructions for setting up VeraCrypt on Kubuntu here.

Similarly for Windows, but you'll have to figure out how to install GPG yourself --- see the Tor project's manual on doing that (that's what helped me piece together the above anyway):
https://www.torproject.org/docs/verifying-signatures.html.en

 

Need More Help?

If you want more instructions, please look for the very clear explanation on how to verify downloads from VeraCrypt's own official download page (here's the direct link to it).

Sharing TrueCrypt USB volume on 3 platforms: Mac, Windows, Linux

Edited 2017-04-02.

tl;dr: TrueCrypt exFAT volume on an exFAT disk. But creating such a volume is tricky!

Update for macOS Sierra: I upgraded to the latest macOS and TrueCrypt wouldn't work. After spending a little time on the problem, I gave up and went with VeraCrypt.  Remember to verify the VeraCrypt download though!

I've tried to find a solution to sharing a TrueCrypt encrypted volume on a USB memory stick between three platforms: Mac, Windows, Linux.  It's been tough to find something modern and reliable, as I tried HFS+, Ext2/Ext3/Ext4 on USB and in a TrueCrypt volume.

Modern means that it'll properly deal with big files (over 4 GB), and long international file names (over 8.3 UTF characters).

The best solution I've found so far is a TrueCrypt exFAT volume on an exFAT USB stick.  But creating such a volume is tricky!  Using the wrong software to do the formatting will destroy the TrueCrypt file.

It's modern, and okay but not great in reliability.  There's some caveats and things to watch out for though to make this work well for you.

Such a tri-platform TrueCrypt volume can be created in basically 2 steps:

VeraCrypt: how to verify its GPG signature

(Update:  the following is still correct, but the fingerprint keys I noted have changed after they released version 1.22.  See my recent update.)

I'm not sure why the steps to verify a VeraCrypt download isn't more prominently displayed on their website, so I pieced it together myself here:

Downloaded latest stable release and PGP signature here:
https://veracrypt.codeplex.com/wikipage?title=Downloads

On a Mac, make sure Homebrew is installed (or else you can install these yourself from source).

brew install gnupg
brew install gpg2

Get VeraCrypt PGP key ID from:
https://www.idrix.fr/Root/content/category/7/32/60/

In the terminal, run the following with the VeraCrypt PGP Key ID you got above:

gpg --recv-keys 0x54DDD393
gpg --fingerprint 0x54DDD393

That should display the key fingerprint, which you should compare with the key fingerprint that's posted on:
https://www.idrix.fr/Root/content/category/7/32/60/
and on:
https://veracrypt.codeplex.com/

Now to verify your download, run the following in Terminal for your downloaded version of the files:

gpg --verify VeraCrypt_1.18.dmg{.sig*,}

The message displayed should say the signature used key ID 54DDD393 (make sure it's the key ID found from above!) and is good and from VeraCrypt Team .

Similar instructions apply for Linux, but install GnuPG and GPG from your system's package management system instead.

Similarly for Windows, but you'll have to figure out how to install GPG yourself --- see the Tor project's manual on doing that (that's what helped me piece together the above):
https://www.torproject.org/docs/verifying-signatures.html.en

After all was written above and done, I found VeraCrypt's instructions hidden away at the bottom of a page without mention of what to install and such, but here it is anyway:
https://veracrypt.codeplex.com/wikipage?title=Digital%20Signatures

3 Steps to Free SSL for your domain's static website on AWS S3

Today, let's talk about upgrading your static web site --- served from your own domain --- so that it serves over HTTPS secure protocol.

Prerequisites
This post assumes you've got certain things already set up. If you don't, the rest of this post won't help you, sorry.

(1) You must already have a static web site served from Amazon Web Services (AWS) S3.

But really, if all you've got is just a static web site (no dynamic content, no server side scripts, no database, etc.), using S3 is pretty awesome.  It's fast, inexpensive, and pretty easy to set up --- a topic for another day perhaps.

(2) You must already have your own domain name set up for your web site, e.g. from Namecheap, and you're a little comfortable setting up custom "Advanced DNS" records like CNAME records, etc.  Again, if you don't, the following won't help you, sorry.

NameCheap's been pretty fantastic for domain name and DNS services for me.  Great service.

(3) You also must have email set up for your domain name.  Maybe you've got email set up with that domain name from your domain name registry (e.g. Namecheap).  Or maybe you've got it set up with a dedicated email hosting service, e.g. Fastmail.com, or Google Apps for Work.

Strategy
The general ideas are these:

1. Get a free SSL / TLS certificate for your domain name from AWS Certificate Manager (ACM)
2. Create an AWS Cloudfront Distribution to originate content from S3, to be served out on a Cloudfront address.
3. Change your domain name's DNS CNAME record to point to that Cloudfront address.

The last TrueCrypt 7.1a: cross checking hashes

TrueCrypt has had a good run, and the latest version was intentionally crippled so users can only read from but not otherwise use TrueCrypt volumes anymore.  Internet drama aside, some people have hosted the last full-featured TrueCrypt version 7.1a.

When downloading such security software, you should always check the source of what you download, and this is especially the case with the aftermath of this particular incident.  So I list below some sources to cross check the last version of TrueCrypt.

Open Crypto Audit Project started as a crowd funded way to get a full audit done on TrueCrypt.  They have posted a link to a verified source and binary repository on GitHub under the AuditProject account.  OCAP is explained a bit in this ArsTechnica article, noting that Thomas Ptacek is running Phase II, and Ptacek describes a bit more on this HN thread.

Of course, if you check the files from that repository against the hashes hosted on that repository, you'd expect them to match, even if it was maliciously set up.  So let's cross check with other, hopefully independent and trusted, sources.

Gibson Research Corp. has hosted a TrueCrypt Final Release Repository as well.  Gibson notes the same issue noted above, that you cannot check files against hashes hosted from the same location.  He references a PGP signed file of hashes hosted at Defuse Security.

As discussed on another HN thread, TCnext is hosting another TrueCrypt repository. TCnext refers to a set of "Independent" hashes hosted by German IT-News Golem.de.

At the time of writing, in cross-referencing all hashes mentioned above, the SHA256 hashes were all identical.  Further, the source and binaries hosted by AuditProject on GitHub matches against those SHA256 hashes.  You should check for yourself when you download them, of course.

Installing Lubuntu 14.04 LTS with Full Disk Encryption

I'm going to walk through, complete with screenshots, my installing Lubuntu 14.04 LTS, a modified distribution of Ubuntu Linux that uses the lightweight LXDE desktop environment and OpenBox window manager.

The last time I installed a fresh copy of Ubuntu was probably when I wrote up Installing Windows 7 & Ubuntu UNR side-by-side on Dell Mini more than four years ago.  Before that, I installed Ubuntu on a desktop, which I upgraded to Lubuntu by installing the required packages but without uninstalling any of the Unity shell items from Ubuntu.

With the new LTS release of Lubuntu, I felt it's ready for conservative users like myself to install.  LTS means it has three years of long term support, which means I don't have to do any major upgrades for at least that long (of course, normal minor upgrades from week to week is still necessary).

A fresh install gives us a chance to clear out the cobwebs, idle packages that were installed but is no longer needed by us, etc.  It also gives us a chance to install it with full disk encryption (FDE), which was available before, but didn't seem quite ready for prime time for conservative users.

Let's begin!

Mounting TrueCrypt Ext2/Ext3/Ext4 Volume on Mac: Read Only Success

Some time ago, I wrote Mounting TrueCrypt Ext3 Volume on Mac: Fail wherein I state that TrueCrypt volumes created in Linux and formatted to Ext3 can't be mounted on a Mac.  In the comments, DrTebi helpfully pointed out that it does work if I had used the correct software versions.  That was 1.5 years ago, and it's time to revisit the issue.

The truth is, it does work, but I could only get it to work in read-only mode.  The software you'll need to install are, in this order:

1. OSXFUSE (2.6.0 at time of writing).  This is the successor to MacFUSE, which is no longer maintained and should be considered outdated.  Make sure to install the MacFUSE compatibility layer when installing OSXFUSE (you may have to choose this explicitly under custom install within the installer).
2. Fuse-ext2 (0.0.7 at time of writing).  More Fuse-ext2 documentation is available.
3. TrueCrypt (7.1a at the time of writing).  Make sure to not install MacFUSE within the TrueCrypt installer by un-selecting it explicitly under custom install within the installer.

And that's it.  TrueCrypt on Macs won't create Ext2/3/4 volumes, but it will on Linux.  And when you bring those volumes to the Mac, you can mount it with read-only access.

But if you do require read and write access, I've read that the commercial product, Paragon ExtFS for Mac OS X, will do that for you.

TrueCrypt on Mac installs old version of FUSE: use OSXFUSE instead

Not much more to say than that TrueCrypt up to and including version 7.1a for Macs installs an old version of FUSE, namely MacFUSE.  Instead, you should use OSXFUSE instead.

This really only applies if you intend to use FUSE for other applications or purposes besides TrueCrypt, and those other applications requires a newer version of FUSE than provided by the old MacFUSE.  If all you use FUSE for is TrueCrypt, then don't worry about it; TrueCrypt works fine with the old MacFUSE.

OSXFUSE (2.6.0 at time of writing) is the successor to MacFUSE, which is no longer maintained and should be considered outdated.

Make sure to install the MacFUSE compatibility layer when installing OSXFUSE (you may have to choose this explicitly under custom install within the installer).

Also make sure to not install MacFUSE within the TrueCrypt installer by un-selecting it explicitly under custom install within the installer.  If TrueCrypt was originally installed with MacFUSE, just download the MacFUSE installer separately, and use the uninstaller within the installation disk image.

How to Mount FileVault SparseBundle in Mac OS X 10.3.9

Imagine you have an encrypted home folder in Mac OS X 10.6 on your laptop.  Now your laptop breaks down, but you were able to copy your home folder into an external hard drive from /Users/YourName which, unfortunately, holds just a YourName.sparsebundle folder.

You know your data is encrypted into that YourName.sparsebundle folder of files.  Now you want to retrieve your encrypted data on your other older Mac computer, which only has Mac OS X 10.3.9 installed.  You do have a Mac OS X 10.6 install disc though.

What to do?

Is it Impossible to Secure Home WiFi?

So for an unsophisticated, or lazy, home network user wanting to have a wireless home network, is there a way to secure the home wifi network?  It seems not.

You could use WPA-PSK security protocol with a long and random password, then it'll get hacked in 20 minutes for less than $2 in computing power.

You could put in a mac address filter, so that only those computers with a registered mac address can even get on the network to begin with.  But it turns out mac addresses aren't just easy to modify, but they are communicated on the wireless unencrypted in the open, so it can be easily spoofed.

Another measure is to go with static IP addresses and a restricted IP pool, so there's less chance someone can get an IP address to your network while you're connected.  But it turns out my wireless router is too cheap to let me set static IP addresses on the LAN.  sigh

So am I supposed to install a RADIUS server now?


Instead, I turned down the wireless router's signal power, since I don't even go far from the router when I use the wireless.  At least hackers will have to be physically closer, I guess.


And maybe I'll try to find another ethernet cable so I can just turn off the wireless entirely.  A lot less headache than trying to secure an open channel.

User Home encryption on Ubuntu 10.04 Lucid Lynx

As I mentioned earlier, encrypting a home user's folder is ultra easy now in Ubuntu, at least for creating a new user (switching an existing user over to using an encrypted home is still pretty complicated).  Just go to Users and Groups to add a new user, making sure to click the check-box option to enable encryption.

But that's not good enough. You need to encrypt your swap partition as well, since anything in RAM could be swapped out onto the swap partition on disk and be read back at a later time.  Turns out this is easy to do in Ubuntu as well.

You'll need to install cryptsetup from the Synaptic Package Manager and of course ecryptfs must also have been installed previously as well (you'd need to have had that installed to enable encrypted user folders in the first place, but I just can't recall if that was installed as part of the standard Lucid Lynx distribution or if I had installed it myself afterwards...).

Once cryptsetup is installed, just do sudo ecryptfs-setup-swap.  Read the warning that's thrown up, it explains to you that at this time, hibernation is incompatible with encrypted swap (although suspend works fine), and indicate your agreement (or not to cancel the procedure).

You don't need to have logged out or anything.  This command will work on its own, or at least it did for me without any special prior setting up.  Once that's done, you can verify it by checking less /etc/fstab to see if the original swap disk setup had been commented out and a new encrypted disk is set up for swap in its place.

Once that's done, you should look into securely erasing the free space on the swap and the root volumes to ensure anything sensitive that's been "spilled" out of encryption containment in the past gets cleaned up now.  You'll need the secure-delete package of tools, specifically sfill and sswap.  See this answer for details.

[Edit: Actually, I recommend looking into securely erasing the free space on swap before encrypting it.  Would've made the process just a tad bit more convenient.]

Mounting TrueCrypt Ext3 Volume on Mac: Fail

 I had a TrueCrypt encrypted Ext3 formatted volume in a file on an external hard drive hat is also Ext3 formatted.  I wanted to mount the hard drive on a Mac, then mount the TrueCrypt volume.  The first part is easy, the second part proved impossible for me.

(2013-07-30:  Read the update, Mounting TrueCrypt Ext2/Ext3/Ext4 Volume on Mac: Read Only Success.)

Mounting Ext3 Volume on Mac OS X
You need just two things:

1. MacFuse
2. fuse-ext2

Install those in that order. I plugged in my FireWire external hard drive and the Ext3 formatted volume mounted auto-magically.

You should check which version of Mac OS X you need, etc, and use latest versions of everything, and so on, of course.

Other pages of info that were helpful, for my reference here:

• [SOLVED] mounting ext3 partitions in OSX
• Mounting ext3 in Snow Leopard… 

Mounting Ext3 TrueCrypt Volume on Mac OS X: Didn't work...
I opened up TrueCrypt and did the straightforward select file and mount (type in password, etc), it then said to me something about hdutil couldn't find a volume to mount. Whatever. The volume is Ext3 formatted so the standard utilities packaged with my Mac here wouldn't help.

But TrueCrypt has an option to indicate that the filesystem should not be mounted.  Click on Mount, then click on Options in the Enter password for "file-to-be-opened" window.  Look for the Do not mount option.  With that enabled, enter password and click Ok. The disk can then be found in /dev/.

I figure, in theory, I should be able to use fuse-ext2 manually from the terminal.  So if the disk is at /dev/disk3, make a directory (say  target) in /Volume/target, then fuse-ext2 /dev/disk3 /Volumes/target/ should mount the file system.  Well, it didn't work.

If you're reading this, and you figure out how to make this work, please let me know.

In the mean time, another option is to use a virtual machine on the Mac to boot up to a Linux distro and run TrueCrypt in the Linux based OS.  Some useful information for my reference:

• Sharing TrueCrypt partition between Windows and Ubuntu
• Accessing a Truecrypt encrypted external drive that uses the ext3 filesystem from Mac OS X

Internet security is dying painfully

Just now I saw a link on Hacker News with the following text (I'm linking it to the comments page for that link instead though):

This link says it's from YouTube but it's not (youtube.com)

Sure enough, Hacker News is reporting the host for the link is YouTube.com, and a quick glance at the URL shows it actually is (see bold):

http://www.youtube.com/redirect?username=digitalhook&q=http%3A%2F%2Fsecuritytube.net%2FSocial-Engineering-Attacks-using-Simple-Redirections-video.aspx&video_id=Vgc3NVVpb8c&event=url_redirect&url_redirect=True&usg=UE0DOmwjBRK-mgheFtW1hMTEvh4=

But look a little further and notice it says "redirect", and a little further along you see where it's redirecting (see the red above). In more malicious case, of course those could be further obfuscated so a cursory look by an intelligent human wouldn't see the redirection.

The sad part is, as noted by commenter Charles Randall, "I've taught people how to scan for valid links, and now they can't even trust that."

That's exactly right. The cost of maintaining security by the end-user, as paid by every individual end-user, is growing with little to no value created for any single one of them. The time spent checking the URL's host to ensure clicking it is safe becomes less effective with this kind of redirection: it's all cost and no gain, most of the time.

This comes right after I read Internet Security is a failure, which argues that these four facets of internet security has been a failure: "1. Identity and Authentication / 2. Transport Security / 3. Secure Software and Operating Systems / 4. Law Enforcement".


This reminds me of the article: Are users right in rejecting security advice?, and the paper from Microsoft the article links to as well: So Long, and No Thanks for the Externalities: The Rational Rejection of Security Advice by Users (pdf). Both are great readings, and it certainly makes sense to look at security as an economic question.

Anyway, internet security is in a sad state of affairs.