Archive for the ‘Teh Intarwebs’ Category

Vandals Must Die

Tuesday, April 22nd, 2008

I just got an alert from Google that my website was on a danger list, that it included a link to some malware. (It’s gone now.) Sure enough, the Yahoo post below contained an IFRAME with a reference to Ghod-knows-what. After excising that, I found some link spam buried in two other posts, pointing to a gambling site. Also gone now.

I recently upgraded to WordPress 2.5, which I understand closed a major security hole. I hope that this closed that hole, and I’ll see no more of this evil nonsense.

Fucking parasites. Pardon my Anglo-Saxon, but this crap just makes me furious. Now my page is marked as “Evil! Unclean!” in Google’s index, until they get around to reviewing it again. And it wasn’t just someone having fun punking my site; this is how hackers build their botnets, using openings like this to subvert anyone unlucky enough to read a hacked web page.

(I repeat, the offending code has been removed, and if the programmers at Automattic know what they’re doing, it won’t be back. If you’re still worried, try switching to a more secure browser… like anything other than Internet Explorer. Like this or this or this.)

Twitter and Viral Opt-In Networks

Saturday, April 19th, 2008

Despite my earlier, skeptical thoughts on the subject, I have been following Twitter (although not contributing a lot, I’ll admit) and starting to appreciate it.

Granted, it’s yet another time sink, and I haven’t found an actual productive use for it yet. But I still marvel at how spam-free it remains so far. Since you only follow people you want to follow, you don’t hear from complete strangers. Yes, a stranger can make a message appear in your feed by including @yourname, but that’s a one-to-one channel, not the one-to-gazillions type of channel that spammers feed on. It works as a way to say ‘hi’, but not as a way to mass-market.

We do need some kind of middle ground between the new proprietary walled gardens like Facebook, and the all-you-can-spam communications channels like email and Usenet. IM isn’t quite it, it’s too much hassle to set up anything other than ad hoc one-to-one conversations. IRC seems to have some kind of karmic “Geeks Only” sign on it, it hasn’t caught on in a big way.

Twitter has about the right social model: opt-in, but make it easy to make connections; but we need to supplement the microcontent format, and an economic model that can keep the servers running as the scale gets truly massive. And finally, it should not be tied to the fortunes and whims of any one company, no matter how enlightened they may seem.

Privacy in a Social Network, and Other Oxymorons

Friday, January 4th, 2008

Much virtual ink has been spilled over the past day about Robert Scoble’s banishment from Facebook (temporary, it turns out) and the reasons for it, and whether he deserved it. One point of view, espoused by no less than Jeff Jarvis, is that the contents of Scoble’s Facebook address book should be kept in Facebook, not exported to a system of Scoble’s choosing. It violates one’s privacy, apparently.

This is a ludicrously naive position.

Facebook and others may say they will protect your data as if it were their own. They are lying. To some of us, this lie was transparent from the start; but if you still believed the lie after the Beacon fiasco, and stories of information leaks from even the most secure government agencies, then you are a fool.

Once you put information in Facebook, or any other website, and allow others to access it, it is out there, no take-backs. If you want it kept private, then keep it private; and putting it on the web and letting other people see it is not “keeping it private”.

Consider this: Scoble did what he did in broad daylight, blogging about it once he had permission to do so. And he did it with apparently noble intentions, willing to sacrifice his Facebook account for the cause of data portability. (At least, that’s how he presents it after the fact, though I have no reason to doubt him.) And he did it badly; his activity was detected because the Plaxo script was too fast; the simple expedient of slowing it down and adding a little randomness might have allowed him to evade detection.

Now, do you really think the Plaxo developers were the first ones to come up with this idea? Do you think maybe someone else might be doing exactly the same thing, but more quietly, more competently, and with less noble intentions? In view of that, do you really think it’s even theoretically possible for your Facebook data to remain protected?

Do not count on Facebook to do your information security for you; they can’t do it, even if they sincerely mean to. (And are you really sure they do mean to? No matter how much revenue it would cost them?) If you want privacy, you have to manage it yourself. If you don’t want your data out there, then don’t put it out there. Be judicious in what information you supply to the social network; and consider salting it with disinformation.

That, or stop caring so much about privacy: embrace the Transparent Society, learn to stop worrying and love the social. Seriously, that’s a perfectly legitimate stance; privacy is optional. Or find your own personal balance between hiding everything and revealing everything.

But don’t fool yourself into thinking that you can escape the fundamental tension between social networking and privacy.

One Revolution Per Child

Thursday, November 29th, 2007

One Revolution Per Child

The OLPC project is laudable even on the basis of its stated goals; but I think there’s more going on here. As this article describes, the OLPC device is by its nature subversive. But why assume that that subversion will only take place in the underdeveloped countries that are the ostensible market?

After all, I want one. Don’t you? And if it really will just cost $100 — or even a smidge more — that makes it almost an impulse buy, at least as gadgets go. And what will happen when thousands of these are in the hands of gadget-fans here in the US, and elsewhere in the developed world?

Revolution begins at home.

Update: the Revolution marches forward. Applications as online services (e.g., Zoho, Google Apps) dovetail nicely with this trend. I remain convinced that Google Android is yet another manifestation of this, approaching the same destination by a different route.

JavaScript Rising

Wednesday, July 11th, 2007

In this post I wondered why no one (that I knew of) had proposed using JavaScript as a server-side language, and developed tools to support it. Well, they say it steam-engines when it comes steam-engine time. A lot of other people had the same idea; and unlike me, some of them did more than just blog about it.

Googler and blogger Steve Yegge (whose keynote at OSCON I am going to miss, dammit) made a splash by porting Rails to JavaScript — specifically, the Rhino JavaScript-on-Java interpreter that is bundled with Java SE 6. He calls it “Rhino on Rails”, the clever bastard.

In an effort to increase developer productivity at Google, Steve tried to convince the company to adopt Rails (and consequently Ruby) as a programming language. When that fell on deaf ears (Google really does not want to increase the number of languages that must be supported by their infrastructure), Steve decided to do what any other frustrated programmer would do: he ported Rails to JavaScript. Line by line. In 6 months. Working 2000 hours. Steve is a coding stud.

And he is not alone: witness Project Phobos.

Phobos is a lightweight, scripting-friendly, web application environment running on the Java platform.

It comes with a set of plugins for the NetBeans IDE that cover the complete development process. These include a fully-featured debugger; wizards to help you get started faster; a palette of Ajax widgets that can be dropped on a page, thanks to jMaki; and the ability to generate a standard web application for deployment on any servlet container or Java EE application server.

Currently, the primary language supported by Phobos is JavaScript. By leveraging JavaScript on the server, Phobos allows developers to use the same language on the client and server tier of a web application, eliminating the impedance mismatch that characterizes other approaches to Ajax.

Digging farther back in Steve Yegge’s archive, one finds he has been thinking along these lines for some time:

JavaScript is probably the most important language in the world today. Funny, huh? You’d think it would be Java or C++ or something. But I think it just might be JavaScript.

For one thing, despite JavaScript’s inevitable quirks and flaws and warts and hairy boogers and severe body odor, it possesses that magical property that you can get stuff done really fast with it…

See, JavaScript has a captive audience. It’s one of those languages you just have to know, or you get to miss out on Web programming, and in case you hadn’t noticed, thick clients are like Big Hair these days. Most non-technical people I know pretty much live in their browsers, and they only emerge periodically to stare in puzzlement at iTunes or a game or something, and wonder why isn’t it in the browser, because everything else useful seems to be. It’s where the whole world is. To non-technical people, of course. Which is, like, practically everyone.

What other language is supported, in a reasonably cross-platform manner, on the Windows, MacOS X, and Linux native APIs, the Java virtual machine, the .Net virtual machine, the Parrot virtual machine, the Flash runtime, the Silverlight runtime, and 99% of the web browsers in the world? (And, oh yeah, what’s that new thingamajig from Apple? I vaguely remember reading something about it. Can’t seem to recall the name…) In other words, JavaScript not only runs on every platform of interest; it is the only language that runs on every platform. [1]

JavaScript isn’t winning the fight to be the Next Big Language; it’s already won.

[1] Actually, I don’t know if it runs natively on PlayStation3 and XBox 360. But given the little-bitty interpreter and the great big storage media, the games could ship with their own JS runtime and not miss the space.

XML + ECMAScript: It’s not silly, it’s the Future.

Friday, June 22nd, 2007

Silly season [dive into mark]

Mark’s rant is red and meaty, just the way I like it, but in the end I have to disagree.

The fundamental wisdom at work here is not, “stay away from proprietary platforms”; it’s “don’t marry the platform… any platform”. If you think that open source is insurance against your technology choices going wrong, I have to ask: how many job openings do you see these days for Tcl/Tk hackers? And doesn’t Perl seem to be going down the same path? (And no, I am not a Perl hater; on the contrary, I am a Perl lover who’s feeling kind of unrequited these days…)

I’ve been itching to dig into Flex (darn SCWCD certification still to do first…), and I feel fairly confident that the time will not be wasted. After all, at its base Flex is just ECMAScript and XML. Learning Flex is, in fact, good practice for programming the next generation of browsers: it’s the first available implementation of ECMAScript 4, the standard to which the browsers will eventually hew. And learning a new XML dialect is something that a professional programmer is going to have to do over and over and over in the decade or so to come. So where’s the risk?

That Adobe is going to hose the runtime? Backward compatibility with gazillions of Flash apps is their main selling point; and keeping it free-as-in-beer is how they (okay, Macromedia) established their amazing level of market penetration. Why the hell would they give any of that up? And they are open-sourcing the SDK, so no sale there either. Where’s the downside, honestly?

(Now Silverlight is another matter; Microsoft has neither an installed base to appease nor any commitment to open source anything; the only thing keeping them semi-honest is, well, competition from Adobe. So I’ll be steering clear of that.)

The User Interface of the Future

Friday, June 22nd, 2007

This will be no revelation to some, but it’s becoming increasingly clear how user interfaces will be done in the future. We will specify UI components and layout in a markup language (old flavor: HTML; new flavor: XML), and we will use ECMAscript to add behavior to these components.

How many variations of this are there out there now?

The only (new) system taking a different approach seems to be JavaFX — which is kind of funny, given Java is XML’s home turf, more or less.

I wonder if we’ll see something similar for Mac OS X (beyond the widget API) and Linux — presumably separate versions for GNOME and KDE.

The back-end is still up for grabs, of course; I have yet to hear anyone suggest using ECMAscript for building business logic or web services. To tell the truth, I’m not sure why not; why doesn’t someone take the Tamarin runtime, or Mozilla’s Spidermonkey or Rhino, and build a general-purpose development environment around it? If we’re doing serious work in Ruby and Python, why not JavaScript as well?

Why Twitter?

Wednesday, March 28th, 2007

The first law of Lazy Punditry is: If you have something to say, and wait long enough, someone else will come along and say it better.

I’ve been finding the Twitter phenomenon truly baffling. Why would I care to post an up-to-the-minute timeline of my life? Why would I care to follow such a timeline of someone else?

Like DrBacchus, I may eventually try out Twitter just to see if I really am missing something; but frankly, it’s not high on my list of things to do.