My name is Matt Henderson—I’m an entrepreneur living on the southern coast Spain. This is my blog, where I write about technology, business, investing and living abroad. You can learn more about me here.
Speaking with people of different religious beliefs, I’ve always found it curious to hear a common viewpoint, that goes something along the lines of:
It’s quite obvious that all gods in which people around the world believe, and have believed, are false. In fact, it defies logic and common sense that people have actually believed in them. On the other hand, it should be intellectually obvious that the god I believe in, who happens to be the god relevant to the place and time in which I was born, actually does exist.
It seems so strange that these people never seem to question in themselves whether they just might suffer from the same blind-spot they find obvious in those who believe in gods other than their own. And it seems intellectually arrogant.
I thought of this analogously today when I read a comment by Bitcoin-proponent Erik Vorhees, about Milton Friedman:
As the most popular champion of free markets, it’s always surprised (and dismayed) me that Friedman seemed to have little issue with central planning when it came to money itself. He would abhor central planning in basically every good, except the good of money, which is arguably the most important.
Having studied Milton Friedman and his work for many years I’m left with the belief that he was a truly special and brilliant man. I consider him in the same class as people like Richard Feynman.
While I acknowledge the importance of independent and critical thinking, if I found myself in disagreement with these people on a particular issue, my first instinct would be to deeply question my own research, my own understanding, my own logic and assumptions and even my own intellectual limits long before I’d conclude myself as “being dismayed”.
Update 2014-03-06: SOLVED! (See below)
The OS X application firewall running on my Mac mini is preventing Daylite clients from remotely connecting to the Daylite server running on the machine. Unsuccessful at solving the problem myself, I’m offering $20 to the first person whose help results in resolving the issue.
To be more accurate, I’m actually observing two separate issues, and the resolution of either would solve the overall problem. So I’m offering the bounty to the first person who helps me solve either of them.
I have a Mac mini running OS X 10.9.2, along with Mavericks Server. The mini is co-located with one of the leading Mac mini hosting providers. In addition, I have the latest version of Daylite Server running on the machine, to which Daylite clients (OS X and iOS) need to connect.
When the OS X firewall is enabled, Daylite clients are unable to connect to the server:
When I first installed Daylite Server on the machine, the OS popped up several notifications asking for permission for various Daylite-related processes to accept incoming connections. I accepted them all.
And, in fact, for quite some time, Daylite clients were successful in connecting to the machine. At some point, and I can’t remember precisely when, it just stopped working; as long as the firewall was enabled, Daylite clients were no longer able to connect.
I have tried removing all these processes from the firewall, and manually adding them back. Sometimes after doing that Daylite clients can connect, but after the next restart of the machine, they can no longer connect.
(I don’t know if it’s related, but for completeness, I believe this problem started around the time I tried installing, and later uninstalled, Ice Floor, a GUI to manage a separate OS X firewall called “pf”. Again, though, I did run the Ice Floor uninstaller, so I presume anything it installed/configured was undone upon uninstalling it.)
One work-around to Problem 1 is to simply disable the firewall, and that’s what I’m willing to do in the absence of a real solution to Problem 1. But even that doesn’t solve my problem. Why? Because each night at midnight, something happens on the machine that re-enables the firewall! In the morning, I connect to the machine to find this:
So, I’ll connect to the machine during the day, unlock the Security & Privacy preference pane, disable the firewall and re-lock the preference pane. At that point, Daylite clients successfully connect to and sync with the server.
But then the very next morning, I find client connections again failing. I connect to the mini, to find that, as every day, the firewall has mysteriously been re-enabled!
I say that the re-enabling happens at midnight, but I’ve not actually connected to the machine to confirm it happens precisely at that time (because I’m in Europe, and the machine is in the United States). But I’m sure it happens around that time. I’ve checked the Console, however, and don’t find any messages posted around midnight that would seem related.
As mentioned at the beginning, I’m offering $20 to the first person who successfully helps me resolve either of these two problems. (My preference is a permanent solution to the first, but either will do.) Please post your ideas/solutions as a comment on this blog post.
Only one person can receive the bounty—i.e. the first who provides me with the information that results in solving my problem. If two people post the same solution in the comments, the one arriving first will receive the bounty. If you need clarifying information, just ask in the comments, and I’ll try to clarify.
The bounty can be paid by PayPal if outside the United States, or ACH transfer if within the United States (via Capital One 360 P2P payment service).
Thanks so much, in advance!
And the solution came from none other than Makalu’s own system administrator, Niall O Broin. (OK, with SSH access to the machine Niall has a slight advantage…)
What Niall discovered was the following entry in the crontab, set to disable and then re-start the firewall each night at 00:01 (i.e. midnight):
What we don’t know, is how that entry made its way into the crontab, which is a Unix scheduler that Apple recommends against, in favor of launched.
(What’s particularly funny, and ironic, is that after having unsuccessfully spent about two hours searching for the cause, Niall discovered it when we concluded that, at least for the moment, the best course of action would be to add a crontab entry at 00:30 to disable the firewall each day. We though, if we can’t find the problem, at least we can hack a solution!)
At Makalu, we’re longtime users of Basecamp, the online project management system created by the folks at Basecamp (formerly 37signals). 37signals care deeply about design, and this is evident pretty much everywhere in the user experience of their products.
Recently, we started using the Bitbucket git repository management system, by Atlassian. So far, it has not seemed evident that the people at Atlassian care as deeply about user experience.
For starters, simply upgrading from a free trial account to a paid account has been a nightmare—resulting in somehow accidentally upgrading a personal account I didn’t even know I had, and subsequently getting locked out of our team account. (Hopefully I can get a refund, once I determine which “Support Entitlement Number” corresponds to the personal invoice.)
This difference in design priority between Basecamp and Atlassian became really apparent this morning, when I clicked on links in transactional emails from both services, whilst not being logged in.
At Basecamp, I was redirected to a login screen. I immediately understand what the problem is.
At Bitbucket, well, just have a look for yourself.
Most likely this screen would have made a lot more sense, had I had DEBUG set to “True”.
After reading about Facebook’s $19 billion purchase of WhatsApp, I started thinking about the revenue and public valuations of the giant advertising companies—Google, Facebook and Twitter—as compared to that of Apple:
Google, Facebook & Twitter are essentially advertising companies with a combined market capitalization of $612 billion. The total global advertising spend in 2012 was about $507 billion, of which $99 billion was spent on internet advertising (source). These three companies took in $69 billion in revenue in 20131. By comparison, Apple alone took in $170 billion.
Earning 60% less revenue than Apple, the stock market currently values the trio of advertisers at 30% more than Apple.
Assuming the trio of advertisers don’t discover other ways to earn money (they haven’t yet) and that the global ad spend at least remains the same, to match Apple in terms of revenue as a percentage of market capitalization, the percentage of global advertising spent on internet would have to more than double, and the trio would have to capture all of it.
Perhaps that’s why Facebook snaps up companies like Instagram and WhatsApp. If their market valuations depends on their ability to capture the bulk of a hopefully growing internet slice of global advertising, it’s in their interest to acquire large potential ad channels, while at the same time removing those with whom they might otherwise have to share the pie.
The current market is obviously very optimistic about the future of the advertisers, and very pessimistic about the future of Apple. Looking at the financial positions of these companies, and considering their business models and histories, I’m happy to be a Apple investor. I’m reminded of the (paraphrased) words of Benjamin Graham:
In the short term, the stock market behaves like a voting machine, but in the long term it acts like a weighing machine, i.e. a company’s true value will in the long run be reflected in its stock price.
This is based on the 2013 earnings reports of Google and Facebook, and multiplying by four the single quarterly earnings of Twitter. At less than $0.25B for the quarter, Twitter’s earnings are anyway in the noise. ↩
A few months ago, a frequent-traveler named “Matthew Henderson” from New York City signed up at Delta.com, accidentally providing my Gmail email address instead of their own (which is likely some minor variant of mine.) Since then, I’ve been the lucky recipient of nearly weekly email notifications regarding Matthew’s ticket purchases, travel plans and seat upgrades. Next week, in fact, Matthew is traveling to Cancun—lucky guy!
How could this have happened?
If you’ve created an account at pretty much any online service within, say, the last five years, you’ve surely seen a message like this after signing up:
Confirm your email account. Please check for an email from us, containing a link you need to click to confirm that you’re the owner of this email account. Once confirmed, you can begin to use our service.
Well, Delta have not implemented any such confirmation process. They’ll gladly accept any email address you provide, and will take for granted that it is, in fact, your own. And what’s worse, they provide no way for someone like myself to resolve the problem.
Unlike 99.9% of all businesses on the planet, Delta notification emails do not contain “unsubscribe” links. Nor do they contain, “Not Matthew?” links.
They do state that email preferences can be managed by logging in to one’s Delta account. Seeing that, I thought, “Ah ha. I’ll just reset the account password (since I own the email account where the reset will be sent), login, and just delete the whole account!” But that doesn’t work either, because the lost-password recovery workflow requires answering security questions that only Matthew Henderson could know.
So I’m stuck.
Last weekend, I tried calling Delta and waited 48 minutes on hold for an operator, before giving up. Then today, I tried again, and finally managed to get through to someone after 22 minutes on hold.
Speaking with this person, who appeared to be an offshore call center worker, it took another half hour to get him to even understand the nature of the problem. Since I also happened to have a Delta account myself, which their phone system recognized from the telephone number I called from, it proved nearly impossible to get past, “But kind sir, the email address on your account is not from Gmail! But sir, your name is Matt Henderson!”.
Finally, after about an hour, I convinced him that (a) a person can own more than one email account and (b) that there can be more than one “Matt Hendersons” in the world. Understanding the problem at last, he promised to try calling the other Matthew Henderson and sort this out.
I emphasized that the bigger problem is their technical systems, and encouraged him to pass on the message that this needs to be fixed. I’m not holding my breath.
On the Feb 20th, I was contacted in Twitter by someone at Delta, asking me to follow them so we could have a DM conversation. In that conversation, they asked for the SkyMiles number of the person using my email address. Shortly thereafter, they claimed to have fixed the problem, and promised I would not receive more emails. (Notice in this conversation, they also mention a 30 day turn-around time on support email!):
Well, this morning, February 24th, after having been promised that the problem was fixed and that I’d receive no more emails, I got another “It’s time to check in!” email from Delta—for the same guy using my email address:
I haven’t heard back from her, but today more mail arrived:
…along with a survey…
I forwarded this to Brittany, including the following message:
If you’d like a deeper understanding of the problem, please provide me with your personal email address. I’ll go signup with it at Delta.com. The website won’t validate that I’m the owner of the address. I’ll then login and specify that I want to receive every email and newsletter that Delta generates — all of which will go to you.
You can then try to figure out how to get it to stop. You won’t be able to do a password reset to get into the account, because before sending a new password to your email address, it will ask some security questions that only I know.
Then you can start calling Delta, and waiting on the phone for hours to speak to some guy in a call center in India, who will promise to get it fixed and then doesn’t. You can then reach out to artificially friendly people in Delta, who will tell you they are “really concerned about your problem”, promise to get it fixed — and then don’t. And finally, you can go through Delta’s online support forms, and will get an email about, oh, once per week or two — and they also won’t be able to fix the problem.
Meanwhile, more interaction with the folks in Twitter, who remain “terribly sorry about all this”, but continue to be unable to help:
And in the department of adding insult to injury—Since I visited the Delta.com website to create an online support ticket, an advertising cookie was naturally set in my browser, to ensure I see this on EVERY WEBSITE I VISIT NOWADAYS.
Just got another email from Brittany, apologizing for the long delay, and explaining that nobody else at Delta had access to her case emails during her “days off”. That doesn’t make any sense. She wrote me on Feb 17, Feb 24 and now March 2. Anyway, she proceeded to ask me to clarify which of the two email addresses I own: [email protected] or [email protected] I can’t believe it; I already answered that question on Feb 24.
Then, she thanks me for my business and wishes my future flights enjoyable. That also makes no sense. Nowhere in this whole saga have I suggested that I am a Delta customer!
And in the meantime, another email arrived:
On March 5, this exchanged happened on Twitter, where the Delta representative, for the second time, indicates that the the problem has been fixed:
But then today, March 7, this just arrived by email, in response to the long email correspondence I’d been having with “Brittany”.
Unbelievable—What the hell is going on at Delta!
I have a MacBook Air, and my wife has an iMac. The challenge is to have shared access to our family’s documents, while securing those which are confidential. This article describes our solution.
Dropbox solved the first challenge—providing shared access to our documents. But without a solution to the second, our confidential documents remained potentially exposed to anyone who stole (or got access to) our computers, or anyone who got access to our Dropbox account.
Recently, I discovered a solution to the security problem—an app for Mac OS X called Espionage. I introduced Espionage in a previous article here on the blog. In today’s article, we’ll look at how to use Espionage with Dropbox.
From my previous article, you’ll recall that Espionage provides access to sets of folders whose contents are encrypted. It does this by storing each folder’s contents in encrypted disk images, and then mounting those disk images, on your command, at their original folder locations in the Finder. It’s similar in function to products like Knox, but providing a far more convenient user experience.
Because Espionage uses sparse disk images, it becomes feasible to store those images in Dropbox (instead of Espionage’s default location in its Application Support folder), since small changes in content won’t result in having to re-upload the entire image. And that in turns opens the door to sharing of confidential documents between multiple computers running Espionage.
Clearly, to avoid Dropbox conflicts and potentially corrupting the disk images, only one computer at a time can access any given folder. I’ll also describe how we address that risk.
Ok, let’s dig into the details.
Setting up shared access to the secured documents involves establishing the setup on one computer first, moving the relevant Espionage disk images into Dropbox, and then reversing the setup on the second computer.
On each computer’s hard drive, there will be two relevant locations:
The first location—where the encrypted images are stored—will be Dropbox.
The second location—where you will access the confidential documents stored in those disk images—will not be Dropbox. This avoids redundant syncing and having your confidential documents stored unencrypted at any time in Dropbox.
Step 1: On each of our computers, I’ve created a folder called “Confidential” at the root level of our user accounts. Here’s what that folder looks like on my MacBook Air, before I’ve imported them into Espionage, and before I’ve added any confidential documents.
Step 2: Starting with the MacBook Air first, I dragged all these empty folders into a new folder set in Espionage:
For each folder, Espionage internally creates an encrypted sparse disk image (to hold the folder’s contents), protected with a random password derived from your folder set’s master password. That disk image is physically located in the Espionage “Application Support” folder, in your “Library” folder.
Step 3: I then unlocked each folder in Espionage, and (in the Finder) copied in our confidential documents. Here’s what that looked like, after having copied in the contents of our “Budgeting” folder:
Step 4: Having copied in all our confidential documents, I then told Espionage to lock all the folders. Once Espionage unmounted all the source images, the folders in “Confidential” again appeared empty:
You can actually combine steps 3 and 4, by dragging folders that already contain your confidential documents into Espionage. In fact, it’s even preferable to do that, since it helps Espionage calculate the size of the disk image. Note, however, that after Espionage imports your folders, it’ll throw the original away in the trash. Until you empty the trash, you’ll still have an unprotected copy of your documents on your computer!
Also remember, all this mounting and unmounting of disk images happens behind the scenes in Espionage. To the user, it just looks as if his secured documents are appearing and disappearing from those secured folders, as they are unlocked and then locked again in Espionage.
Step 5: Now, for each of these secured folders, I clicked on the info button in Espionage, and relocated the source disk image from its original location in “Application Support” to a folder in Dropbox. In this screenshot, you can see that I’ve already relocated this one:
You’ll notice that the names of the disk images are random; should anyone ever steal your computer, or get access to your Dropbox account, they wouldn’t even know what those images might be associated with. (Unless you’ve blogged about it, as I’ve done here.
Step 6: While the folder info window was still open in Espionage, I copied the disk image access password to the clipboard, and then stored it in 1Password. You’ll need this in order to import the disk image on the second computer. (Remember, the Espionage disk image passwords are not the same as the password associated with your folder set; rather, Espionage creates a much stronger random password for each individual disk image, that is algorithmically derived from your single folder-set master password.)
Step 7: We’re now done with the MacBook Air. Before starting on my wife’s iMac setup, I waited for Dropbox to finish syncing all the Espionage encrypted disk images on both computers.
Step 8: To set things up on the iMac, we simply reverse the process. We start by dragging the disk images into a new folder set in Espionage, enter their associated passwords (which, recall, we stored in 1Password), and then associating those disk images to their relevant locations (“mount points”, in Espionage-speak) in the “Confidential” folder we created in Step 1.
At this point, we’re done. Either computer can now use Espionage to unlock the contents of any of our confidential folders, making them available for use. We’ve hopefully achieved (relatively) secured sharing of confidential documents.
A problem could arise if both computers tried to access a given folder at the same time, or tried to access a folder whose source disk image had not finished synchronizing. And that problem could manifest itself as an inaccessible, corrupt disk image.
This risk of this happening increases with the frequency with which both sides need access to the confidential documents. Fortunately, in our case, neither my nor I work with our confidential documents on a daily basis, and we tend to work in different areas of our confidential documents—e.g. I do the banking and she does the budgeting.
But still, we need to take precautions.
Backups—First, CrashPlan keeps all our home computers backed up, with at least a year’s worth of file versions. Should a disk image get corrupted, we’d be able to recover.
Notifications—Second, in order to help avoid conflicts in the first place, I have Growl 2 running on my wife’s iMac, and setup to send all Espionage notifications to me in emails. So if my wife opens our “Projects” folder, I’ll get an email. And I’ll get another email when she closes it.
With these notifications in place, I should only run into conflicts if I forget to wait until Dropbox syncs the closed disk images.
For those who didn’t read my introduction article to Espionage, here are a few reminders and concluding thoughts:
That’s about all. I hope you’ve enjoyed this article, and I’ll update it with additional thoughts and observations as I have them. And if you have any questions or feedback, don’t hesitate to leave a comment or contact me.
A few weeks ago, and way late to the game, I started listening to podcasts. Of the several I’ve heard so far, the ones I enjoyed have included Horace Dediu’s “The Critical Path“, Benedict Evans’s “Cubed“, Gabe Weatherhead and Erik Hess’s “Technical Difficulties” and Shawn Blanc’s “The Weekly Briefly“. The ones I’ve disliked have included John Gruber’s “The Talk Show” and Marco Arment’s “Accidental Tech“.
I wanted to take a moment to reflect on why I liked some and disliked others. This is mostly for my own benefit, since going through this exercise will likely reveal my motivations for listening to podcasts in the first place.
I enjoyed both The Critical Path and Cubed because they are thought provoking. In their respective podcasts, Horace Dediu and Benedict Evans choose a topic and then take a deep dive—far beyond what would be possible in, say, a blog article. Through their podcasts over the past few weeks, I’ve gotten some fresh perspective on bitcoin, and have considered Google’s business through a new, analytical lens.
As an aside, I think both those podcasts could do without their co-hosts, as it seems wasteful for Dediu and Evans to spend time struggling to sidestep the intellectual equivalent of, “Great point! And that brings us around to something I’ve often wondered—will Google continue to capitalize the A in Android?” (Ok, in fairness it’s not that bad, and keeping up with Horace or Ben is a tall task to begin with.)
I enjoyed Technical Difficulties because, as a geek and tinkerer, I like to learn practical things I previously didn’t know or hadn’t considered. From episode 61, I was inspired to wire my house with cat-6 ethernet cable, thereby relieving my poor wifi network, and from episode 62, I revisited my UPS strategy, and discovered that OS X has built-in support for UPSs in the Energy Savings settings. So this podcast has practical value.
I enjoyed The Weekly Briefly for Shawn Blanc’s sincerity and authenticity. I felt he was speaking directly to me, and that in a way a relationship began between us in that first episode. Having listened to the podcast, I’d feel comfortable introducing myself to Shawn if presented with the opportunity.
I didn’t enjoy The Talk Show or Accidental Tech. In both cases, it seemed as if the hosts believe what their audience has always wanted was the chance to eavesdrop on a random conversation between them and their buddies in a Starbucks. The delivery felt unprepared, the content wandering and arbitrary, and the tone insincere due to what seemed like an attempt to wrap every other comment in wit or sarcasm. (In some strange way that I don’t quite understand, I seem to associate that type of wittiness with arrogance.)
Both Gruber and Arment are smart and interesting guys, and for many years I’ve enjoyed reading what they’ve published on their blogs. For that reason, I was surprised at their work in this medium. As the podcasts didn’t provoke much thought or provide practical value, and since I didn’t feel I got to know them better as people, I came away feeling I’d wasted my time.
For those interested, I chose Instacast as the product for listening to podcasts. Vemedio offer Mac and iOS versions, and a particularly nice feature is the cloud synchronization; if I’m listening to a podcast at home on the Mac in the morning, I can pickup at the same spot on the iPhone while driving to work.
While waiting for version 4 to be released, I’ve had to temporarily uninstall the MailTags plug-in from Mail.app in OS X Mavericks. One of the most-used features of MailTags for me was its ability to copy the selected message’s URL to the clipboard.
A “message URL”? That’s correct. Mail supports URLs to individual messages, that when accessed open the particular message in Mail.app. This is what one looks like:
I often use message URLs to provide myself with reference to conversations, important decisions or tasks that are captured in emails.
Without MailTags installed, though, I’ve been really missing this feature. My friend, Stefan Seiz (@seiz), however, was kind enough to email me an AppleScript that provides this same functionality. From that, I created a Keyboard Maestro macro, and assigned it to a keystroke.
If you use Keyboard Maestro, feel free to download the macro here.
This morning we traveled to Málaga to participate in the 2014 Churriana chess tournament. The event was actually divided into two tournaments—adults and kids. Both my kids chose to participate with me in the adult division.
After five rounds of six, my 10-year old son Lance was in first place—the only person in the tournament who had won all five games out of five.
While I started round six at table 14 with 2.5 points (two wins and a draw), Lance paired off with his rival at table 1. Half an hour later, when I finished my game (I lost), I looked up to see a huge crowd packed around table 1.
I ran over just in time to see Lance fighting it out, cool as a cucumber, in a fierce “final”—rook versus bishop. As the time on the clocks ran down, you could cut the tension with a knife—every move happening lighting-fast in the span of seconds.
Ultimately, Lance lost that final game (His ELO rating is 1,700 while his opponent’s was 2,100) but the crowd burst into a huge cheer as the little 10 year old finished the adult tournament in 2nd place overall.
Although my 12 year-old daughter hasn’t quite reached the level of my son—Lance finished 3rd overall at the Spanish National Championship last year—she’s been dramatically improving in her own right, finishing the tournament this morning in the equally impressive (for her) position of 7th overall.
In the past, all the devices in my home operated over a single wifi network—including four Macs, an AppleTV and several iOS devices. I’ve long suspected I was probably overtaxing the wifi, and listening to the recent “taming wifi” episode of the Technical Difficulties podcast inspired me to do something about it.
So my project this weekend was running cat-6 cabling throughout the house, allowing me to move my Macs and AppleTV off the wifi and onto a gigabit ethernet.
As part of that project, I wanted to modify my upstairs/downstairs roaming wifi network from one in which an Airport Express extended the network created by an Airport Extreme over wifi, to one in which the Express extended the network over ethernet. That proved a bit trickier than I expected, so I wanted to explain it here for the potential benefit of others.
To clarify what I wanted to do: Previously, the Airport Express (upstairs) connected to the Airport Extreme (downstairs) over wifi (a network called “Hacienda”), and then extended the “Hacienda” wifi network to the upstairs area of my house. Configuring an Express to do this is very easy; you just select “Extend a wireless network”.
The problem with such a setup, is that the Express is sharing its wifi bandwidth between two functions—communicating with the upstairs devices over wifi, and then passing that same traffic to the Airport Extreme downstairs, over wifi. Now with cabling everywhere, my plan was to connect the upstairs Express to the ethernet, so that it could extend the wifi network upstairs without having to communicate with the downstairs Extreme over wifi.
Unfortunately, that wasn’t as easy as just connecting the Express to the ethernet. In fact, doing just that caused all sorts of problems; all of a sudden my upstairs Macs started popping up those warnings, “This Mac’s IP address is already in use by other computer with the same name…”
The solution is to configure the upstairs Express in precisely the same way as the downstairs Extreme—i.e. you “create a wireless network” with the same name (“Hacienda” in my case) and the same password, and set the device to operate in “bridge mode”. Doing that, and everything works as expected.
So, wrapping up, here’s a diagram of what my network looked like before and after:
If you’re looking to do the same thing, I hope this article has helped. And if you have any questions, don’t hesitate to write.