The fact is the internet is open can lead to theft especially to content stealing and plagiarism.

Until now, there was very little to discourage and deter this serious crime. Yes content theft and plagarism is a crime in some jurisdictions.

You cannot rely on others or the authorities to continue to police the internet as they do not have enough resources. You need to protect your content and deter this theft.

The basic form of content theft is to copy and paste your content to another medium.

Well Houdini, prevents this using a little known special algorithm that prevents copying by making the selected text that is targeted by the perps to be copied, to disappear! Yes disappear!!! The only way to recover is to reload the page in the web browser. If they try again, the content disappears again. As long as they keep trying to select and copy your content, the content will disappear before they can get a chance to execute the copy command!

After a few unsuccessful attempts, the theives will move on to a easier target.

Your safe!

— WordPress › Houdini « WordPress Plugins

So what can we glean from this PHK Corporation plugin's description, other than the fact that the author has poor English skills? We can most definitely conclude that phkcorp2005 has no understanding of how most copying of Internet content is carried out. As I and others have pointed out many times over in blog and forum posts, copying is usually not done by a person using a mouse to cut and paste, but rather by automated computer programs called scrapers. (For the uninitiated: See these two Wikipedia articles.)

What is left out of that messy, error-riddled description is the word "JavaScript". It is by no means the only word or phrase that should be inserted, but it is the most important. That fifth "paragraph" (the formatting is also very poor) should say "special JavaScript algorithm", which is synonymous in this case with "useless JavaScript algorithm". All it does is wait for the user to try to select text in the browser and clear the selection if any is made. Besides, any copy-protection scheme based upon JavaScript is inherently useless by virtue of the fact that it doesn't do anything to prevent copying. There are tons of ways to get around it. Disabling JavaScript, for example (as mentioned below).

For example, take hatkirby's rant. I quote from that post the list of circumvention techniques below:

1. Go old fashioned and turn off JavaScript. Yep, the script is rendered useless.
2. More advanced content thieves likely don't just go around to random blogs and copy/paste off of them. They write screen scrapers, small programs that visit sites and download specific parts of the site. As these do not render pages and simply download from them, the script isn't even seen by the scraper.
3. Due to the nature of the Internet, anyone, and I mean anyone, can see the source code of a website. It's done differently in different web browsers, but it's always pathetically easy and, as it simply shows HTML code instead of parsing anything, no scripts are run.
4. RSS. Syndication feeds are normally viewed in feed readers with little to no JavaScript interpreter. Script bypassed.
5. There's this cool little button on most keyboards that says "Print Screen". Even on the keyboards that don't have it, there's usually a key combination that achieves the same effect. It takes a picture of whatever's on the screen. No selection occurs and yet the thief has a copy of your article. They do, however, have to retype it, so this keeps the lazy thieves out.

That's just a smattering of ways to get around the JavaScript inserted by Houdini.

In the face of all the arguments presented, the plugin's author has insisted that the purpose of Houdini is not to "prevent" copying, but to "deter" copying. I don't think that statement holds any weight whatsoever. It still depends upon the copying being performed in a JavaScript-enabled browser by a human.

There's also the matter of just how absurd copy-protection of any kind is on the Internet. Every single document or file anywhere on the Internet must be copied in order for the user-agent (usually a browser in the case of human interaction) to retrieve and display or otherwise make use of the content. This is why it's quite simple for any user to just view the source code of a page. It has to be copied in order to display the content.

Also mentioned in the first (started, chronologically) forum thread is the ability of JavaScript to disable the browser's context menu and thus the "View source" option. That's just as useless as the selection-clearing code, and actually more so because many modern browsers allow specific JavaScript capabilities to be disabled—capabilities like removing or replacing the context menu—as an alternative to disabling all JavaScript. The "View source" option is also present in other places—places such as the browser toolbar's "View" or "Tools" menu—which JavaScript code cannot modify even in the most permissive environment.

Legitimate quoting must also be considered. There are a million and one reasons why someone might legitimately want to copy a few sentences of a blog post. Maybe they like it enough to post a quote to Twitter or Facebook, or perhaps they want to comment on it in a blog post of their own. Content theft is a big problem, but the old methods of periodically searching for and reporting content stolen from one's site are infinitely preferable to this plugin's ineffective method.

Finally, why require the use of a shortcode? Why not just add the script globally to all content pages and forget that stupid "This page is copy protected" header?

At most, Houdini has the ability to add a superfluous <h5> tag to the page and annoy legitimate users with an obnoxious script while doing absolutely nothing to thwart real content thieves. I wonder if WordPress Extend would consider removing this laughable plugin from the directory... Of course, we bloggers would then be denied this ripe opportunity to satirize this particular piece of code.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

The beauty of using this open system is that if something doesn't work the way I want it to, I am free to simply change it; every plugin is editable from within WordPress' administrative back-end, and the core code is also hackable (though I don't like messing with it because upgrades will break changes). When I discovered that the Wibiya Toolbar (or Wibar) was showing on the mobile version of the website (which is generated by MobilePress, another good plugin), I simply looked in the source of Wibiya's plugin to see how the JavaScript for the toolbar was being inserted.

I found that instead of using the wp_enqueue_script() function as WordPress plugin developers are supposed to do, the Wibiya developers simply used echo to output a <script> tag. That explained why only the JavaScript for the Wibar was loading on the mobile site. Rewriting the plugin to use the official WordPress script-injection method solved the problem.

The original relevant code was:

add_action('get_footer', 'filter_footer');
add_action('admin_menu', 'wibiya_config_page');

function filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        echo '<script src="http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js" type="text/javascript"></script>';
    }
}

I rewrote it just a little bit. My changes were pretty trivial, really. I changed the function name to be namespaced (including the plugin name) just so it'd be less likely to conflict with another plugin. I also switched actions to enable wp_enqueue_script() to work (get_footer is called too late) and added a check—if( !is_admin() )—to keep the toolbar off of admin pages, preserving the original behavior of the function (and the sanity of anyone using the modifications).

In short, wp_enqueue_script() takes five parameters, three of which are optional. The first two are the $handle and the $src, which specify a name for the script and its source address. Then come $deps (dependencies; Wibiya has none, so set to false), $ver (version; also false because it's irrelevant), and $in_footer (set to true because the toolbar should be inserted above the </body> tag).

So with my changes, the code block above becomes:

if( !is_admin() ) {
    add_action('wp_print_scripts', 'wibiya_filter_footer');
}
add_action('admin_menu', 'wibiya_config_page');

function wibiya_filter_footer() {
    $wibiya_toolbarid = get_option('WibiyaToolbarID');
    $wibiya_enabled = get_option('WibiyaToolbarEN');

    if ($wibiya_toolbarid != '' and $wibiya_enabled) {
        wp_enqueue_script( 'wibiyabar', 'http://cdn.wibiya.com/Loaders/Loader_'.$wibiya_toolbarid.'.js', false, false, true );
    }
}

Following some light testing, I submitted an idea to the Wibiya feedback forum, where my update is currently being reviewed by the company. Hopefully, the change will be included in a future version of the Wibiya WordPress plugin. After all, it changes nothing for Wibiya but works wonders for compatibility with other plugins.

I'll just bet that this won't be the last time I'll send a patch to a plugin developer. I enjoy reporting bugs and coming up with fixes too much to not do it.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

I'm thinking about portable computing right now because I keep everything on my hard drive. Well, stuff that isn't email or associated with a Web service. Applications and stuff all live on my computer. When I go somewhere else, I can't get at the FTP accounts stored in FileZilla (except for the one or two whose passwords I know by heart) or my Firefox data (stored passwords, which I don't usually need anyway; history; extensions).

Is that bad? Depends. On the one hand other copies of Firefox run a lot faster without all the extensions, but the one I'm using right now is at version 2.0.0.4. No organization I've seen bothers keeping Firefox up-to-date. The current version is 2.0.0.13 2.0.0.14 (updated again today, actually), and that could open me (and all the students and faculty) up to security holes, and I don't like that. Trying to upgrade gets me an error message due to students getting limited accounts.

Aside from the lack of updates, I also don't have any of the comforts of home. That is, I don't have my theme (which is currently a glorious black space theme) or my extensions (which do everything from notifying me of new email to keeping me apprised of visitors to this site to making sure I'm not trusting a bad site). I have no history, no bookmarks (which are actually in Google Bookmarks anyway). I also don't have OpenDNS shortcuts, but that would require configuration changes to the computer's operating system anyway.

Most of these annoyances would be solved if I simply got a USB thumb drive and loaded portable versions of my applications onto it. Transfer the settings files and I'd be good to go. Firefox, Notepad++, and FileZilla already have portable versions, I know for sure, and those are the only applications I really find myself wanting. I don't even use FileZilla that much anyway; I'm only thinking about it because I wanted to try something with it to fix a bum plugin on CodingExperiments.com.

With Notepad++, I'd probably want to have Apache, MySQL, and PHP along, too, so I could work on website development. I know there are portable server installations, too. Those could be added to the list if I got a reasonably sized drive (I'm thinking 16 GB at the moment, plus 500 GB of RAID 1 storage to leave at home for archival).

I could also bring along my computer, I guess. It is a laptop. But it's ailing with power jack issues, which make it really annoying to use if it's not left alone on a table (which it is at home). So the trade-off is not having my settings. I can live with it, really. I only spend an hour or two on foreign computers a week. Planning for the future, though, is something I should do. I won't have my own computer forever; it'll be going back at the end of this school year. And no, my idea of bringing a USB flash drive with me is not new; I'm just writing about it myself for the first time.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

What's in one of those things? Usually it's just a summary of all transactions conducted by the agency on your behalf since the last report, with a few statistics thrown in for good measure. Yes, it can be useful. No, it does not need to be mailed out to every agency customer, in triplicate (I kid you not; this does happen on occasion).

Before the invention of the Internet, such mailings made sense. There was simply no other good way of getting the documents. It was either paper mail or paper fax. Either way, you used paper.

Now, of course, we have the Internet, and that wonderful thing called email. Adobe made the PDF file format, and we should be using that, too. There's simply no good reason to use paper for these reports in this day and age.

Considering that each report averages around 20 or 30 pages, and that there will often be multiple reports mailed by multiple agencies, that translates into a lot of paper, especially if the amount is multiplied by the number of customers receiving those documents. As I said, we could definitely email PDFs instead of putting all these reams of paper in the mail. What if, just hypothetically, there was a better way? A better way even than email?

I think there is, and it's kind of making me eat my own words. What if all the reports were simply generated on-the-fly by a Web-based console? Each customer would get a login (always transmitted over SSL, of course, as with the rest of the site), which would get them into a reporting interface tied to their transactions. Undoubtedly, the transaction data is stored in a database. That would be an efficient way to store such uniform data. The site would simply tie into that database (or a replicated read-only copy, for another layer of hacker cracker safety).

In my mind, I envision the same sort of powerful reporting interface as those used by applications like Google Analytics. Date ranges, comparisons, graphs, charts... All would be quite welcome in a world of financial data. And the best part of such a system would be the near-obsolescence of paper reports. The dynamic charting and date-range selection capabilities of the Web application would surely prove more useful than fixed paper reports.

Of course, there would be Luddites intent upon keeping their paper-based reports. Hence "near-obsolescence" rather than just "obsolescence." There would have to be an option to receive paper reports, in recognition of the views held by the few people who would want them. But that option should be turned off by default. Anyone who wanted paper mailed to them would simply call the agency and say so. It could even be a question when new customers sign up. But again, the default would be "no." As far as I can tell, most people don't use the paper, so why waste it?

It's probably obvious that this is a half-baked idea. I haven't got any interface mock-ups, server-side code (say, PHP or Python), SQL, or anything else. All I have is an ideal, that paper-based reports be sent only -- and only -- to the people who want and use them.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

What I like to do is have debug mode switched in the source code itself, say in a global include file that defines constants and variables for the entire site. (MediaWiki's LocalSettings.php is a good example.) Since it's usually wise to do your development on a different set of files (at least, if not on your own machine), you can make changes and set debug mode on while coding, and then turn it off before uploading the code to the live site. There's no risk of someone discovering a hidden parameter, and you use the same basic if(debug){print debug stuff} code that you would otherwise.

It's not necessarily something you would call a "best practice"; it's just the sort of thing that you want to think about before making the decision to use GET params or constants. If security is important, you should stick with things that can only be switched by modifying the source code. Barring anyone hacking your server, everything would be safe from GET snoopers.

This is just some food for thought.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

What if the show involved not just data structures, but entire class abstractions? Or perhaps actually writing code for a specified operation within the given situation? I think I need to give an example.

Let's say the show begins with the original idea of designing data structures. Whoever comes up with the simplest and most efficient means to store the necessary data gets points, and the other player gets a smaller number of points based on how much less efficient/more complex their idea is.

Next, the challenge would be to write a class (in PHP, Java, JavaScript, or whatever, depending on the problem) to handle the given task, including all member functions and variables, excluding abstraction layers (which could be referenced in contestants' code just the same, with comments to describe what the call is doing). Again the results would be analyzed for efficiency, and points awarded.

Finally, the contestants would develop a user interface, if applicable to the problem set forth at the beginning, graded on usability. Tally up the points, and the player with the most points wins a prize such as a trip to Apache, Google, or somewhere (I'd have to work on the destination list).

It's not fully-baked (neither was i80and's idea, let's be honest), but it would be an interesting idea, and probably much more intellectually stimulating than shows like Fear Factor. What do you all think?

Update (2008-01-04): In light of all the views I've seen this page get, just let me say that if you steal this idea and get some studio to make it, I expect a cut. Gotta protect intellectual property rights. And set aside an equal share for my friend i80and, too; I did get my inspiration from him.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

It would definitely make adding new photo galleries easier, not having to get burned CDs from the current photographer, and actually kind of knowing what's going on so I can organize the albums on my own. It could mean I'd have to delegate some of the more mundane tasks, like filling in album tables with values, to others (who have offered to help). I might turn into a regular executive-type who never does anything himself. OK, so that's a stretch, but I seriously could find some excuses to delegate tedious tasks. Let's see... Resizing images, filling in HTML templates, adding links, updating website text... The list could potentially go on for a while. Depending on what taking the position would involve, perhaps I will take on the extra challenge, if only to exercise my management and photography skills.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

A few details: I was trying out a new extension I installed that generates trees from lists and has expandable/collapsible nodes using JavaScript, and tried using it with the experimental Live Preview function in MediaWiki. I noticed the tree was getting cut off, so I reported a bug to the extension's developer on the extension's talk page at MediaWiki.org. After going back and forth for a few days, testing various issues, I finally decided it wasn't his problem, given the test results both of us were getting. I thanked him for his tests and tried something in my wiki (namely pasting a long article from Wikipedia, and then also trying to preview 50 paragraphs of "Lorem ipsum" text), noting that these were also cut off. I reported the bug to Bugzilla and it was patched just like that.

Whoops, gotta run; I have a message from Bugzilla that probably has patching instructions...

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761

Also added are jQuery tooltips (plugin from Bassistance.de). They display on all major links (like the badges and sidebar links) and the login form. Finally, I developed a settings page for the previously-hidden features for the badges. You can now officially select what badges you would like (blue, yellow, or none). The settings are saved in a cookie on your computer. I hope to add more settings some time.

Originally published at Technobabbles
Content copyright © 2006-2010 by Voyagerfan5761