All Posts in Technology

|In: Industry Commentary|Last Updated:

We need reliable bot detectors.

The irresistible subject is Facebook, about which you’ve probably read more than enough to make your eyes glaze. Nonetheless, bear with me, because, as pointed out in this space not long ago, the central problem isn’t data privacy or policy enforcement failures.

No, bots, not Facebook’s data usage policies and violations thereof, are the central problem here. The reason it’s the central problem is that bots scale. Human beings don’t.

And just as Twitter’s failure to implement and deploy bot detectors directly led to zillions of bot-amplified tweet-storms during the 2016 election, so bots are the reason 50 million Facebook subscribers were caught up in the latest fiasco.

Bots and their detection and prevention are the big under-reported issue here, because until it’s addressed, even the most ingenious terms-of-use policies will have all the impact of an eye dropper in a forest fire.

Even if you don’t use Facebook, you and the business you support might nonetheless be on the front lines of the war against the bot apocalypse.

Bots scale. Humans don’t. That’s at the core of Facebook’s data breach. That’s because the initial breach wasn’t a breach at all. A researcher paid a group of Facebook users to take a personality test and to share personal information … a perfectly legal transaction.

Then came the bots, in the form of a crawler that, starting with this list of identified Facebook users, navigated their networks so as to harvest information from 50 million users who hadn’t given their permissions.

This is the nature of social networks: They are networks, which means that from any node you can navigate to any other node.

If the aforementioned researcher were to personally try to harvest data from 50 million connected Facebook subscribers, my back-of-the-envelope calculations say Facebook would have ceased to exist centuries before he finished the job.

But add bots to the mix and you get a very different result. They can crawl the nodes of a network orders of magnitude more quickly than a human can. That’s how they’re able to harvest personal information from millions after only receiving permission from a relative handful. Facebook purportedly disabled the ability to harvest friend data from its API in 2015. All this means is that instead of invoking the API, bots have to screen-scrape instead, which in turn means the bot is impersonating a human being.

Add this: Like it or not, we’re rapidly mastering the discipline predicted in Isaac Asimov’s Foundation Trilogy. He called it “psychohistory,” and its practitioners knew so much about human psychology that they could manipulate people to do just about anything. Asimov optimistically made psychohistorians a secret, benevolent group. Unsurprisingly, our actual psychohistorians are using their techniques to create robotic human impersonators that manipulate actual humans more for power and profit than the greater good.

Why would we expect anything else?

If you’re wearing your business/IT priority-setter hat right now, my best advice is, sadly enough, don’t unilaterally disarm. Your competitors are, or soon will take advantage of these techniques and technologies to sell more products and services. From this perspective you’re in an arms race. If you aren’t actively monitoring developments in these area and working with the business strategy team to see how you can profit from them, it won’t be long before you’re replaced by someone who understands these matters.

But if you’re wearing your human-who-doesn’t-want-the-bot-apocalypse hat, you might why Facebook, which is investing heavily in artificial intelligence research and development, doesn’t devote more of its R&D budget to bot detection … like, for example, any of it?

My guess: Facebook is investing heavily in human impersonation. It’s in the bot business … chatbot technology, for example … so why would it also develop bot detection technology?

Especially when its customers … businesses … see direct financial benefits from being able to deploy convincing chatbots and other human impersonations and no obvious profit from detecting such things.

Because make no mistake about it, you might be a Facebook user, but you aren’t a Facebook customer. Facebook follows the standard media business model. As pointed out in this space back in 2002 in the context of newpapers and television, when it comes to most media, you aren’t the customer. You’re the product. And in the world of business, it’s the customer who’s always right.

Products like us enjoy no such privileges.

Comments

|In: Architecture|Last Updated:

I took a long weekend, so this was my first chance to post even a re-run.

It’s a bit dated, (it ran in 2002) what with its references to web services, but substitute SOA for web services and it holds up pretty well.

At least, I think it does. But you’ll have to be the judge.

– Bob

# # #

Long before ManagementSpeak graced these pages, Mad Magazine had mastered the art of translation. My favorite:

What they say: It isn’t the money. It’s the principle of the thing.

What they mean: It’s the money.

To run IT, you need both money and principles, of course. Among the core principles for running a typical IT organization:

> Buy when you can, build when you have to.

> Minimize data redundancy.

> Maximize software re-use.

> Pick two.

If you buy when you can and build when you have to, you’ll use applications from more than one software vendor, your databases will be tied to your applications, and you’ll have redundant data. On the other hand, most vendors now write to an n-tier software architecture, which means you can get at the underlying logic, so you achieve software re-use.

Want to minimize data redundancy or maximize software re-use? Build everything yourself, or at least everything you can’t get from your primary ERP vendor. You’ll have full control over your code, too which gives you a fighting chance at re-use. Too bad you can’t afford either the budget or time to choose this option.

Web services promises to eliminate these trade-offs. The use of components instead of full-blown objects means logic is easily accessible while data is still defined separately, and the use of HTTP and XML means vendors can write general-purpose components and make money by renting them out. That means (blare of trumpets!) you’ll easily assemble enterprise applications out of commercially available components from all over the world.

It won’t happen — not because of technological obstacles, but because an enterprise application is more than a collection of general-purpose utility routines.

Software is an opinion about how a business should run. It’s expressed in code rather than English, but its an opinion nonetheless, so when you buy software from multiple vendors you’re buying differing opinions. Interfaces are where they clash. To state the obvious: Technology can’t resolve a difference of opinion.

Imagine you’re a retailer. Web services can solve some irritating problems for you, like managing the sales tax logic in multiple states, so as CTO you decide to adopt the architecture to run your whole business.

That’s when you discover: The different vendors from whom you’re going to rent components disagree on some very fundamental issues, such as how to define “customer.” One considers “customer” to be an individual. For a second it’s a household. A third, oriented toward hardware stores, perhaps, remembers that building contractors buy a lot of stuff and use a definition that includes companies and everyone in the company authorized to make a purchase.

Think you’ll just ship customer data into and out of components from all three vendors with impunity?

Think again.

The grand vision of Web services is that easy integration of independently engineered components will happen by just connecting them together like Tinkertoys. The reality: Integration is hard, even when designed into an application.

It won’t happen by accident, grand visions notwithstanding.

Comments