Another day, another data breach. This time it’s eBay, but it’s happened with pretty much every major Internet service. If only password hygiene was easier for normal people to grasp. It wouldn’t solve the problem of hackers getting user data, but would help contain the potential damage to user accounts. Even an encrypted list of passwords can be cracked by a dedicated hacker, and lists of common passwords, and their encrypted versions can be had easily online. Once again, using the same password in multiple place is just begging for a world of hurt.

It’s why I’m glad to see two-factor authentication rolling out in more places online. I use two-factor authentication for a lot of the sites I use every day, from Google, to Facebook, to the backend of this very site. The premise is simple: you have your username, and your password, but you also have a second code you have to enter when you log in that is tied to a physical piece of hardware on your person. If those codes match, you’re in. This means that someone trying to break into your accounts needs to have both your credentials, and that piece of hardware to get in. It’s not a new idea; security and financial services have long had dedicated “dongles” that provided codes, but now we all have smartphones, or at least flip phones with texting plans. Two-factor! It should be a slam dunk, right?

The biggest problem is crappy implementation. If, for example, I’ve read that if you keep logging into your two-factor authenticated Google account from the same computer, Google assumes you can trust it and stops asking for your code. [1] It’s a terrible assumption if, say, you’re homeless and use the same library computer to access your email. Or, if your two-factor code is being sent by an insecure method, say SMS or voice message, it’s not hard for a dedicated hacker to snag it before you do. If a server is still affected by the Heartbleed bug, then two-factor authentication can be bypassed, too. For services that use a short PIN (Apple, for example), a dedicated hacker can even just brute-force it.

Two-factor authentication is also a pain in the ass to set up with many services. Setting it up for a new service is the only time I ever use my phone to scan QR codes, which is a pain on its own. There’s also creating backup login codes to store, linking phone numbers where you’d prefer not to have them [2] , or installing crappy apps on your smartphone you’ll never use for other purposes. These are all things that can be overcome through a little diligence, and a little vigilance on the part of the implementers, though. The mainstreaming of biometrics can also help make two-factor even more secure. Even if the bad guy has my phone, they’d have a hard time getting into my authenticator app without my thumbprint.

It’s been said before: “Easy security is no good, good security is not easy.” We’ll never be rid of the threat of bad actors trying to get into our personal data, but there’s enough people working on the problem that the roadblocks are going to get stronger in the future. By making good security, if not easier to set up, at least harder to avoid, we move to a safer online future. Two factor will be part of it, but it’s going to take some time. Certain people will always want to use “12345” as the password on their email account, but the sooner we can mitigate the effects of that, the better off we’ll all be.

A while back, one of my favorite apps, Moves, was bought by Facebook. Cue the standard rending of garments and rage-quitting after the Moves people changed their privacy policy so that Facebook could have their data. In the midst of that great uproar, I tweeted that I would continue to use Moves until Facebook did something questionable with the data.

Why? Well, I’m no fan of Facebook. I’m a user of their service because it’s the one option I have if I want to stay in touch with friends and family, especially the non-techie friends and family. Likewise, Moves is the best app for tracking where I go during the day. There’s other automatic life logging apps, and I’ve tried them. They’re all big, bloated messes. Moves tracks where I go, how many steps, and guesses what mode I used to get there. It’s a great tool for getting a picture of my day.

So, now Facebook sees it. Or can see it. Whatever.

While I understand the desire to be protective of who has access to your data, I’m willing to surrender my information if what I get in return is worth the price. It’s why I still use Google, Dropbox, and a host of other free services. It’s also, yes, part of why I use Facebook. I’d still rather pay, and not give up my data if I have that option, but I’m okay with the alternative. I would have happily paid money for Moves up front, or through some In-App Purchase deal, if it meant they could stay independent. Looks like I’ll be supporting them with my data, instead.

This is one small piece of a larger argument over paying for services in data, but it’s an argument that often overlooks most people’s apathy about their personal data, and preference for free over paid. After all, broadband and mobile internet in the US is expensive enough for many people. Asking them to pay for currently free services like email, or social networking as well adds up to an expensive proposition. A lot of us in the technology world understand the value of our data, and have a greater ability to pay for those services normal people take for granted.

For there to be any improvement across the population, a lot of little things need to change first. Internet access needs to be cheaper, normal people need to learn more about the value of their data, and companies need to find a sustainable business model beyond selling data to advertisers, or charging up front for a service of unclear value. Tecies rage-quitting valuable apps and services makes for compelling Twitter post. It does little to accomplish any real change. In the time it takes to post your quitting message, a hundred or more new people downloaded the app from all the publicity.

Even considering all the above, if there were another app that does what Moves does, as well as Moves does it, and charged a reasonable price in dollars instead of data, I would jump in a heartbeat. I doubt any developer would be able to make a going concern out of it. So, I’m back where I started, and I’m okay with that. Until Facebook does something with my Moves data that goes too far, I’m going to keep using it. I’m still getting my data’s worth.

I’m still new to the whole Quantified Self thing. The only wearable I have is a FitBit One, and I track all my food and water intake manually (when I remember). I use RescueTime to track what I do on my Mac. [1] I have Moves running to see where I went each day, and how I got there. I use Datalove to track how many words I write each day, and the numbers aren’t great. GoodReads tracks my books—and not well. That’s about it. I still end up collecting a lot of data about myself and my activities, but why? Data alone is useless. If RescueTime says I was 41% productive last week, but 24% productive this week, what does it mean? [2]

Data without context is meaningless. One of the reasons why personal fitness and Quantified Self applications go so well together is that if you’re trying to get healthier, knowing how much you move around during the day helps. If you get home, plop on the couch, and see you’ve only made 3238 steps during the day, it might motivate you to try and move around more. When I step on to the treadmill after work, or even just go for my post-lunch walk, I know it’s having an effect better than just returning to my seat and decomposing. I have a goal, and the data lets me know if I’m getting there or not. There’s no better measurement than how I feel—and writing this after a trip to the gym, I don’t feel great—but data helps back things up.

But correlating “steps taken” and “calories consumed” to general health is a lot simpler and easier to understand than a lot of other massive data-focused endeavors. So much of the talk around “big data” reminds me of Max Cohen’s assumptions in the movie Ï€. The idea that if we have enough data, set enough sets of eyes on it—or enough algorithms to parse it—we can discover patterns and gain insights into the future of whatever the data is about rings true. It plays to the innate human prediction for pattern recognition. We’re good at it, and by extension computers are good at it.

There’s just two problems. One: we often read patterns where no real patterns exist, as do our computer programs. Two: This can often lead us down the wrong rabbit hole, as we overgeneralize the pattern we discover, without being aware of its changes. By way of example, look at Google Flu Trends, and how it’s become increasingly out of whack with reality. The “big data” hypothesis, much like the “quantified self” hypothesis, is that the more information we have about something, the more insight we get into it. The problems above prove that this isn’t the case. Data alone does not lead to understanding. As a wise man once said, “You can use facts to prove anything that’s even remotely true.” Algorithms are just as subject to biases and ignorance as the people who make them. As long as that’s the case—and it will always be the case—we’ll have to do a lot more interpreting to find the answers, if they exist.

When a publication like Infoworld is talking about ethics in technology, it's a sign something is up. ¹ While Peter Wayner hits the nail on the head about the questions we need to be asking about the technology we make and use, he's quick to note that “…ethics courses have become a staple of physical-world engineering degrees, they remain a begrudging anomaly in computer science pedagogy.” I'm sure he's right, but we live in a world where GitHub is considered to be a résumé. One can get a programming job, and even start a new company by self-teaching yourself programming. Adding ethics to the CS pedagogy is a great idea, but doesn't help those who lack a formal education.

These ethical dilemmas, especially “Whether – and how – to transform users into products,” and “How much should future consequences influence present decisions” should be part of the dialogue. It seems, rather than try to figure out answers to these dilemmas, we go for the easy assumptions. Yes, we should transform users into products, and no, we shouldn't think about future consequences. The former is easily explained as a side effect of what drives returns on VC investments, the only thing close to a reliable big bet you can make in this market. The latter is an extension of the “fail early, fail often” ethos of the modern Silicon Valley and its children.

“Fail early, fail often"is dangerous, as it leads to extreme short-term thinking. It's often spun as incentive to try new ideas and refactor them if they don't pan out, which is a good strategy. However, when the bar for failure is set too low, a company can abandon a good idea for the new and shiny, even if there is potential for success by just giving it more time and effort. Some of this is an effect of the push for returns on VC investment if a company doesn't become a runaway success after a few rounds. In other cases, it's a get-rich-quick mentality on the part of the founders.

The lack of long-term thinking is also baked into the culture of some of the giants in the technology space. Google and Facebook alike put little thought into the ethics of what they have to do to drive more people into their ecosystem, collect data, and sell ads. Their bottom line is tied to it. Facebook expanding their company into virtual reality through the purchase of Oculus may imply Mark Zuckerberg wants to expand the possibilities of what Facebook can do beyond their current monetization strategy, but who can say? Google's various pie-in-the-sky projects seem to be more about goodwill in the tech community than finding a way improve what it tries to present as a core business. How do military robots help "organize all the world's information?”

We're living in a dangerous time. Heartbleed is a high profile example of the risks we're facing giving up so much of our data to these fast moving systems that spend far more time convincing us to disgorge our lives into them than they do protecting our data. It's easier to focus on getting us to surrender our information than it is to protect it, and the business case is stronger, too. I don't buy the argument that it's the “nature” of the network that things are how they are. We all define what this network is, whether we are a creator or a consumer—a line that is becoming increasingly blurred. We all have a voice in the debate over these ethical dilemmas, and it's time we actually had a debate about it.

Apple is officially letting ordinary users run their beta software. While it’s not the first time Apple’s launched a public beta, they haven’t done it since the move to OS X back in 2000. Siri has bee the only Apple product since OS X released to the public in “Beta” form. Apple’s a very different company now, one that’s “double[d] down on secrecy” to quote Tim Cook. It’s clear this news took a lot of people by surprise.

It’s easy to speculate why Apple’s taking the route of a public beta. Some speculation online has been that it’s to get more diverse bug reporting to prevent some of the same issues that plagued the launch of 10.9 and iOS 7. (Some in the know claim Apple will be making the iOS 8 beta public, but we’ll see come WWDC.) That’s a good reason, but I think there might be another issue at play. iOS 7 got a lot of attention at its announcement, and there were plenty of ordinary users circumventing the developer restrictions to get it on their phones. Enough to spawn an angry editorial from Rene Ritchie at iMore. Even I downloaded the GM of iOS 7 before the official release. [1]

So, if ordinary, clueless users are installing this stuff anyway, why not legitimize it and get some bug reports and data out of it to make the final better? Makes sense to me, and there’s enough disclaimers on the Beta Seed Program page to hopefully scare off some people. It’s necessary, because in recent years, the word “beta” attached to a piece of software has become irrelevant. Flickr, gMail, and Siri were all shipped out as “beta” to consumers who almost certainly were unaware of the connotations. Many online services live in a perpetual beta, constantly changing features, fixing bugs, and introducing new bugs.

The dream for a lot of Apple users would be for the Beta Seed Program to be the first step towards a move away from annual, iterative software releases to regular, ongoing updates, at least to their backend services. It’s probably too soon to say that this is the case, but recent updates to iWork for iCloud suggest they might be moving that direction. Apple’s a small company compared to a lot of their peers, but they’re still a big ship, and they’ll be hard to turn. I might be reading a bit too much into the tea leaves, but I can hope this is the start of a new, more agile and responsive Apple that won’t have their newest flagship mobile OS crash to a white logo every hour.