Feorlen's Other Blog

One of the things I do to protect myself is vigorously restrict disclosure of my physical address. I use a mailbox service and only provide that unless I am compelled otherwise. For example, to register to vote I was required to give my actual residence so I can receive the correct ballot (which arrives at my mailing address.)

Then this happens:

Report: 191M voter records exposed online

Some organization that holds copies of US voter records, through a monumental database screw-up, has allowed public access on the Internet to all of the data. Nobody knows exactly how, or by whom, or even for how long, because the most likely actors are falling over themselves to disclaim any association with the breach.

The California Secretary of State reports that there were 17.7 million registered California voters in 2015. The author of the above article quotes a security researcher who verified access to “over 17 million California voters.” I will leave as an exercise for the reader the percent chance of my information having been exposed.

The problem with secret information is that once it’s released there’s no way to pull it back. Access to voter information varies by state, but many states restrict who can access it and for what purposes. California is particularly strict in that it can only be used for campaign or government purposes. Without question, this disclosure is violating the law. There will be investigations, and charges, and lawyers will wrangle over this for years to come. Maybe, eventually, some person or organization will be held to account.

But for some people, none of that will matter. It’s not just an academic discussion when I have friends and colleagues who regularly receive threats of death and other abuse of the most vile nature. Even for those who have similarly assiduously protected their physical addresses, they will need to face the possibility that the only option to protect themselves from their harassers is to move.

For those friends and colleagues, I can at least report that the State of California has a program that provides a free Post Office Box to qualifying abuse victims, than can legally be used to register to vote and access other government services. So if it comes to that horrible decision, perhaps you can get some help to protect yourself after.

For me, and everybody else, we are on our own. If you live in California and want to express an opinion in this matter, here are some suggestions:

Governor Edmund G. Brown Jr.
Secretary of State Alex Padilla
Senator Barbara Boxer
Senator Dianne Feinstein
Find Your California Representative

For other states:
Find Your Senators and Representatives – OpenCongress

This, friends, is the future.

You may recall my previous post about Apple’s two-step verification and how I reluctantly disabled it for a long trip outside the US. Now I find out that the government of Australia came to the same conclusion. Only one of us seems to be troubled by it, however.

Australian government tells citizens to turn off two-factor authentication
When going abroad, turn off additional security. What could possibly go wrong?

I’m not going to get into any conspiracy theories about why the Australian government might wish to discourage the use of better authentication methods. If they wanted to get into someone’s government services account, I presume they have other ways to do it than hope they can guess at their lousy password.

But putting out the suggestion that two factor auth is something maybe not so important? There’s the real offense. “Go ahead and enjoy your holiday, don’t bother your pretty little head about that complicated security thing.”

Yes, the problems of handling two factor auth when swapping SIMs are a concern. A concern for the people who design these systems that are complex and cumbersome to use and seem to forget that real people don’t conveniently stay put all the time. But how about we talk about that instead of discouraging people from using them?

I wanted a dedicated server to experiment with Swift development on Linux, so I set it up on an Intel NUC (“Next Unit of Computing”) embedded box similar to a Mac Mini. It’s a DE3815TYKHE kit I got from a Tizen developer event a while back. It comes with an Atom E3815 CPU and 2 GB of RAM. I’m not using the onboard 4 GB of flash storage but installed a 256 GB SSD.

Taking advice I found from other users, I updated the BIOS to something known to work as a headless server (without monitor and keyboard) and installed Ubuntu Server 14.04.3 LTS. I could have used the latest 15.10 version, but since Ubuntu has designated 14.04 as a Long Term Support release it’s safe to use for several more years without concern I will be forced to upgrade.

After getting the box set up, next is where to install the Swift dev tools. All the comments I’ve seen seem to expect you will put it in your own home directory, supported by the fact that the file permissions for the contents of the tar package are set to only allow access by the owner. That’s fine if you are doing this on a VM that only you will be using, but I wanted to allow the option of sharing this with another developer on my server. The only reasonable way to do that is put it in a system location and make it owned by root.

The topic of where to actually install a package on a Unix-type server is a religious discussion on the order of which editor to use, so I’ll just say that I put it in /usr/local. (I changed the versioned package directory name to “swift” for convenience.)

The install directions on the Swift download page are good and easy to follow if you are already comfortable with average command-line system administration tasks. (Don’t forget to add the install path to your user’s PATH as described.) Additionally, I installed clang 3.6 as suggested on the github page for anyone on Ubuntu 14.04 LTS.

The directions don’t talk about the install path much. I discovered I had a problem when I got permission errors trying to compile a trivial “Hello, World” example. root could compile, but not anybody else. The solution was to modify all the file permissions so other users can read and execute the needed files. Since I untarred into my install location as root, root already owned all the files so the owner permissions were fine. I didn’t want to universally change everything when adding group and other permissions (plain text files don’t need to be executable, after all) so I did that by hand.

First give group and other users read permissions. Even text files need this, so it’s safe to do it with one recursive command from the top level of my install directory.

chmod -R og+r *

Now locate all the directories and add execute permissions so regular users can traverse the filesystem.

find . -type d -exec chmod og+x {} \;

Finally, identify the remaining files that should be executable by searching for the original owner permissions in a detailed directory listing of everything.

ls -lR | grep rwx

These are the ones I found that only had “rwx” in positions 2-4 indicating permissions for the file owner:

in swift/usr/bin:

-rwxr--r-- 1 root root 56959 Dec 18 23:36 lldb-3.8.0
-rwxr--r-- 1 root root 86318 Dec 18 23:36 lldb-argdumper
-rwxr--r-- 1 root root 927980 Dec 18 23:36 lldb-mi-3.8.0
-rwxr--r-- 1 root root 63672187 Dec 18 23:36 lldb-server-3.8.0
-rwxr--r-- 1 root root 9177 Dec 18 23:35 repl_swift
-rwxr--r-- 1 root root 73808411 Dec 18 23:32 swift
-rwxr--r-- 1 root root 1754089 Dec 18 23:39 swift-build
-rwxr--r-- 1 root root 7683691 Dec 18 23:36 swift-build-tool
-rwxr--r-- 1 root root 856388 Dec 18 23:31 swift-demangle


in swift/usr/lib/swift/linux:

-rwxr--r-- 1 root root 7287250 Dec 18 23:39 libFoundation.so
-rwxr--r-- 1 root root 5037507 Dec 18 23:33 libswiftCore.so
-rwxr--r-- 1 root root 15373 Dec 18 23:33 libswiftGlibc.so
-rwxr--r-- 1 root root 172853 Dec 18 23:39 libXCTest.so


in swift/usr/lib/swift/pm

-rwxr--r-- 1 root root 284768 Dec 18 23:39 libPackageDescription.so


Add execute permissions to these files individually with chmod og+x.

After all this, I was able to compile from a regular user’s home directory.