Tag: data-security

The Evernote two-step: a tale of caution regarding privacy and data ownership

This recent story from PCWorld about Evernote changing its privacy policy followed by this story covering a very abrupt about-face from Evernote say pretty much all there is to say about why it’s a bad idea to blindly trust companies like Evernote with the privacy of your data.

Basically, Evernote changed their privacy policy on a whim to allow employees to snoop on user notes ostensibly to assist efforts to train its algorithms. Originally, individual users could opt out of the algorithm training, but not out of the part of the privacy policy still allowing Evernote employees to snoop on their data; businesses could opt out but would not get the benefits of the new features if they did.

Evernote was quick to backpedal and change to an opt-in model following the fully justified outrage of its users. It’s quite possible some users no longer trust Evernote with their data after this two-step, and it would be hard to blame them. It is possible to store data locally with Evernote (by creating a local notebook instead of a “synchronized” notebook) and they intentionally make it easy to get all your data out of Evernote if you want to leave for what you believe are greener pastures. This gaffe might be the impetus for quite a few users to do just that.

The lesson here is a very powerful one: there’s very little stopping other companies from doing this tomorrow, and there’s no guarantee the CEO of that company will even give the appearance of giving a tinker’s damn about its users. This is a rather direct reminder to take a look at the companies you trust with your data, and how easy it would be to get your data out of those services/products should you decide you want to leave. Of course, it would be wise to remember the best time to find out how easy it is to get your data back out of a product/service is before you put your data in it.

I’ll add a personal angle to this. At various times over the past year and change, I have considered moving this blog to a static site updated with Pelican, among other possibilities. The hard part is not getting the data out of WordPress–that’s actually about as easy as they get. Even the free-of-charge wordpress.com platform makes this relatively easy, even if one is not moving to self-hosted WordPress (a.k.a. “wordpress.org” to differentiate it from shared-hosting wordpress.com).

No, the problem comes if I find out Pelican (in this case) doesn’t work out and I have to move entries back into the last backup of the site as a WordPress site. That might be easy if I make no more than about five posts before finding out it’s not going to work out. But what if that’s ten? Twenty? Fifty? One hundred? Two hundred? It’s a potentially painful process because I don’t see an easy way to automatically make even a WXR file with the new posts in it. Sure, I could ease any future transition by keeping a local install of WordPress and add the new posts manually as I make them, but that is an implied admission I have no confidence in the new platform–and that would be the case even if it was something besides Pelican.

Of course, ideally I want to change platforms only once. There’s always the chance the first change doesn’t work out. There’s also the chance I would want to later switch back to WordPress after making this change, or switch to a future WordPress fork or even to something like b2evolution (which forked from the same blogging software that WordPress was forked from).

Another great example of what not to do, unfortunately, is what the WordPress Foundation (at the time) did when they struck a deal with Meetup.com regarding the online presence of local WordPress groups. The thing to remember about Meetup.com is that they intentionally make it difficult to impossible to change platforms. Vendor lock-in, combined with the (justified) fear that organizers might lose some members (in fact, almost certainly will lose some members) when transitioning to another platform, is the business model of Meetup. It’s a huge departure from the Meetup that I used as an early adopter and that’s sad.

Anyway, it was and still is really disappointing to me that the WordPress Foundation (at the time) deciding to just pay a bunch of money to Meetup. The first reason is it’s been sort of an informal goal of the WordPress community to do everything with WordPress that can be done with WordPress. As an example of this, WordCamps aren’t ticketed with Eventbrite or other such sites; they use a WordPress plugin called CampTix written for the purpose. Thankfully the deal with Meetup.com is about the only time WordPress was intentionally eschewed for a function central to the local WordPress communities around the world.

Adding to it, of course, was the unfortunate experience we had with the Houston WordPress Meetup in most of 2012 going into the early months of 2013 and the response from Meetup (at the top of the post). Basically, Meetup’s standpoint was that the people (community) in the group didn’t matter as much compared to the organizer paying their dues on time. The only silver lining to this cloud is that the WordPress Foundation (the entity paying Meetup which is the nominal organizer of the actual group; maybe this, too, has changed to WordPress Community Support, the new PBC) has a bit more skin in the game and can replace inactive or unresponsive organizers. Then again, they would still be able to do that using a home-brewed WordPress-based solution, without paying Meetup one bloody cent.

Regarding the use of Meetup, it’s hard to see which is the chicken and which is the egg. A lot of groups were using Meetup.com prior to the WordPress Foundation deal. Still, the better move for the community would have been to start a WordPress multiuser site similar to wordcamp.org with a plugin to replicate the Meetup-like functionality in much the same way CampTix fills in for Eventbrite. Better yet would be a fully free software alternative (GPL, if need be Affero GPL) to Meetup.com; even if it is not built on top of WordPress, that would be a step in the right direction.

Examples are plentiful, but the lesson remains the same:

  1. Know how to get your data out of a platform before you need to. If unsure, ask questions. If you don’t like the answers, use a different product or service instead, after getting satisfactory answers to the same questions.
  2. Trust your gut. If a privacy policy change rubs you the wrong way, raise hell about it, and minimize the damage by taking your business and your data elsewhere (see #1).

Data security and the FBI’s attempts to screw it up

I can’t believe we’re even having this discussion in the USA.

This recent article in National Journal reports on a recent discussion hosted by Christian Science Monitor with Amy Hess, the executive assistant director of the FBI’s science and technology branch. The crux of this discussion was that encryption with “back doors” in it is an acceptable tradeoff for law enforcement.

The problem with Ms. Hess’s (and I would assume also the FBI’s) view is that when it comes down to it, computers are stupid. Example: when I type in my login ID “skquinn” and my password into a computer I have an account on, the computer gives me access based on that password. It’s going to give anyone access who has that password matching up with that login ID, it doesn’t matter whether it’s really me, my mom, a friend of mine, or some bozo that just stole my computer (for all values of “stole” whether it’s basic theft, burglary, or a cop with a warrant). There are ways around that password check, though, and this is why I keep my home directories encrypted (in my case, with eCryptfs).

Ms. Hess’s proposal would ask encryption software developers (such as the developers of eCryptfs) to include alternate ways of accessing the keys to decode my home directory, assumably for law enforcement use pursuant to a valid search warrant. The problem with that is that, again, computers are stupid, and the computer won’t be able to tell if it’s legitimate or not. The key can still be used to compromise my privacy; it’s bad enough if it’s a legitimate law enforcement use, but let’s say it’s some rogue cops who would like to see this blog disappear off the face of the Internet for good?

Real data security, whether the government likes it or not, means it is secure against even law enforcement access without the consent of the owner. Perhaps it could be said, especially against law enforcement access. While I would like to think the government acts in our best interests, there are quite a few instances from around the world past and present where this has not been the case. Present-day China, Nazi-era Germany, and recent governments in the Middle East (Iran, Iraq, Afghanistan) all come to mind. I’m certain that if computing technology like this had existed in the 1940s, Adolf Hitler would have loved to have backdoors like that for surveillance purposes.

It’s not our problem if the FBI or any other law enforcement agency can’t spy on us. I concur with the quote of John Basil Barnhill (mis-attributed to Thomas Jefferson): “When government fears the people, there is liberty. When the people fear the government, there is tyranny.”

I don’t want tyranny. And last I checked, that’s not the Statue of Tyranny standing in New York Harbor, either.