Give Me Paste Back!

As a web-developer and a programmer, there's a rule about never trusting user input.  It's similar Murphy's law and why software companies spend lots of money beta testing.  If there is a wrong way to enter data, a mindless user will find a way.

The rule of thumb to counter this is to programatically eliminate user error on the server-side.  This means that if you're expecting a phone number in format "(555) 555-1212" and the user enters it as "555.555-1212", you either give an error or you process the data anyway after you fix the entry.  Eliminating the user's ability to type a period does solve the aspect of not being able to type a period only.  It does not eliminate a user from typing "555    55 5 -  1212".

I recently had this "discussion" with the good folks at @CreditKarma in 140-characters or less.  They told me what I expected, but 140-characters isn't enough to tell why using JavaScript to turn off a browser feature is ultimately stupid and pointless.

Overall, JavaScript should be used to enhance the browsing experience.  Eliminating paste, right-mouse-click, obfuscating image URLs are all things that cheapen the user experience because the browser does not do what the user expects.  An user should not have to jump through digital hoops to be able to use a website in the way they would like.

Specifically, pasting is something that most people do everyday.  They expect every application, whether it's Microsoft Word or their favorite browser, to do what they've come to expect when pressing "Ctrl-V".

On the other hand, as a web-developer, I understand why folks like Credit Karma choose to prevent pasting via JavaScript.  It's cheaper to write one line to stop pasting than it is to actually test user input.  Testing user input would require more programming hours to test for each possibility.  Furthermore, you run the risk that the user was stupid and accidentally fat-fingered something in one box and then pasted it in another.  I will admit that I have done this.

This is NO excuse for disabling a critical feature of the browsers.  However, if you simply MUST do this, consider the following:

• What frustrated me the most is that there was no feedback as to why paste did not work.  INFORM THE USER that paste has been disabled and offer a reason.  They may not like it, but at least they know that the problem *isn't* between the monitor and keyboard.
• PROVIDE A WAY TO PASTE ANYWAY.  A switch, a preference...anything that says, "Hey, if you want to paste, we'll let you, but be sure you know what you're doing."  Doing this will help people like me who get frustrated and then write Greasemonkey scripts fixing your mess.
• No matter what client-side solution you create, a user will find a way to mess things up so BE PREPARED TO HELP THEM.  Users make mistakes.  Give them a way to fix these mistakes instead of forcing them with the digital equivalent of cattle prods.  Guide them by giving them clear and concise instructions.
• DO NOT RELY ON JAVASCRIPT TO FIX YOUR CARELESSNESS.  Users expect their browser to behave in a specific way. Things like autocomplete are a great way to augment the user experience.  However, forcing the user to wait while their browser counts down to 30 seconds is ridiculous when a crafty user can just read the source to get the final URL.  Furthermore, blocking the word "DROP" via javascript doesn't mean that they won't type in "; DROP TABLE customers". 
• Finally, DO NOT "EDIT WAR".  If people are downloading and using my script, it's because they are frustrated like me.  Listen to your users.  The frustration that we feel doesn't color your company well.  Web Development is like electricity: we don't think about it until something goes wrong.  And users will make sure you hear them loud and clear.

Bottom line: Do not negatively alter the user's browser behavior unless you have absolutely exhausted every other option.  And if you have to, let the user know that you have done so.  After all, you are a guest in the user's browser.  (Technically, the user is the guest, but I digress.)  Don't scruff the floors, drink all the milk and put the carton back in the fridge.  Be a great guest so that the user will invite you back.  Otherwise, you'll find yourself lower and lower on the user's favorites/bookmarks and less and less on their minds.

All of this aside, Credit Karma is a great service.  They provide a way for you to get your credit score for free.  Yes, actually free unlike FreeCreditReport.com.  I do recommend them, even with their broken registration process.

So here it is: Give Me Paste Back now in version 0.2, tested specifically on Credit Karma.  Download the script and then go to Credit Karma and sign up for an account.

Facebook Autopoke Update

It's been a few months since my last post.  After a few months, I finally got in touch with the folks at Greasemonkey.  It looks like Jesse Andrew is no longer running things, which is great for him.  He's got a lot on his plate and it's good to see him giving away some things.

But it did make making the DMCA takedown's a bit longer.  There is only one script left that violates GPL.  Since it's one script, I will be releasing the newest autopoke script sooner than anticipated.

Please note that the public version of the script will be an obfuscated version.  This does accomplishes two things:

• Makes it much easier to see who is actively copying my script without permission
• Also allows those who have "pirated" scripts to know they may be using an outdated or insecure version.

By no means is this perfect, but it gives people like Tony White, who does nothing but copy scripts and claims them as his own, another hurdle to jump through.

If you are a developer and would like access to the "development" version, feel free to look through the Google Code project.  I use mercurial so it should be easy to figure out which is which.  (Sorry, no further clues will be given.  You're a developer.  It's easy to figure out.)

Speaking of Tony White, I'd like to take a brief moment to share a few thoughts about the GPL and litigation.  First, I don't enjoy using a public forum to address a personal issue.  But he has left me no choice since he has yet to respond to any of my messages.  I have asked Tony White on four separate occasions to bring his scripts into compliance.  I could understand a one-time mistake.  Most people don't understand how the GPL works.  However, after reviewing all of his scripts, the vast majority of them are copies of other people's work.  He then removes the original author's name and substitutes his own.

My goal is to not make money off of any of my scripts.  They are freely available, both in speech and in beer.  That is why I did not sue Userscripts or Tony White.  However, claiming someone else's work as your own is simply despicable.

I cannot fight for other people's copyrights.  But I can fight for my own.

Tony White has blocked private messages, either only from me or from everyone.  Either way, here is the bottom line:

If Tony White is found to have a copy of my Facebook Autopoke script, I intend to file suit in Federal Court for injunctive and damage relief.  I plan to ask the court for $1000 for each violation, which will include each copy that was downloaded.  And since he was a repeat offender, I can triple any damages that are awarded.

That being said, I hope to release the newest version of the Facebook Autopoke within a month.

Getting tired of the edit wars? Autopoke is being considered for closed source

Facebook may be changing their poke code in response to this script.  While unconfirmed, it seems each iteration makes autopoking harder and harder.  To thwart their efforts, I am considering closing the source and obfuscating the code.  What do you think?

If you don't see the survey above, you may need to enable surveymonkey.com within your NoScript. Or you can simply take the survey on their website.

Yup, the new facebook broke the autopoke

For those of you that just finished cursing the developers of Facebook for fixing something that wasn't broken, you will soon realize that the new design broke the autopoke.

No worries.  Development has continued.  Hoping to have a fix by the end of the month.

Fighting GPL violators

Being a strong believer in open-source, it gives me no pleasure to find people who violate open source licenses.  Abiding by these licenses are fairly easy and I take a very liberal view of the rights that they protect.

Back in June, I discovered several userscripts that were copies of my Facebook Autopoke script.  While I normally wouldn't have a problem with this, the fact that this user simply copied the script and just pasted his name on it made me pretty angry.  It's one thing to use my script as a bases of a better script.  Even if it's part of a larger work.  But copying the script and just slapping your name on it not only violates the GPL legally, it violates it spiritually.

The GPL was created to foster sharing of thoughts and ideas without fear of stepping on someone's toes.  What this user did was took my hard word and claimed it as his own.

Now, I contacted the Tony White back in May and never received a reply.  So, I contacted Userscripts.org and informed them that I had revoked his license, persuant to section 8 of the GPL. The script is still up today.


So until I have this resolved, all work on the autopoke script will cease.  If you have any questions, feel free to ask them here in the comments.

Major Milestone Achieved!

Quick stats:

• 377 lines of code
• 15 KB
• About 50 total programming hours spanned over three weeks

I am pleased to announce that the autopoke script has reached an important milestone: it has completed it's first set of pokes!  Until now, the majority of the programming concentrated on how to actually detect pokes without loading the entire page.  Then, work began on detecting pokes across all languages, which meant hacking the code of Facebook.  Finally, the poke functions were re-written from the ground-up.

Here are the technical changes made thus far:

• Uses XMLHttpRequest instead of GM_XMLHttpRequest: Makes use of the fast Javascript engine instead of passing to Greasemonkey.  This change should make it easier for non-Firefox users to install the script.  But remember that it is not officially supported.
• Makes asynchronous requests: Fixes a bug that users of slow computers from properly auto-poking.  A copy of the front page is used instead of the DOM itself.  It allows for faster processing and allows users to be poked even before the page finishes loading.
• New status/error messages: These messages are far more informative and allows the user to see why a poke failed.  Debug variable can still be set to see the "console".
• Makes use of XML 1.0 standards: Facebook is XML 1.0 compliant. The script makes use of this to retrieve important information to pass to the poke function.  (If you want to see this in action, set debug to 3 or higher.)

 And here are a list of features that will be added over the next couple of weeks:

• Tracking number of pokes in current war: Obviously, this won't include pokes that have already occurred
• Check Facebook for pokes automatically
• Prettify error messages so that they can be copied and pasted into bug reports
• Comments within the code

And finally, I am working with The Last Well, a 501(c)(3) non-profit organization that building wells in Liberia, to receive donations for it's mission.

Facebook changes their poke engine...again

This seems to happen about 2-3 times a year.  Facebook will change the way that pokes are processed both via the browser and on the backend.  While there is no proof that Facebook is doing this purposefully to disable the autopoke script, it does break the script and produces error 1.1.  This error code means that the autopoke script received a response from Facebook that wasn't expected and could not process the poke any further.

As I've stated before, I do not plan on releasing fixes to autopoke 3.5.  I'm actively developing 4.0 to replace 3.5, which will include an adaptive regular expression to be able to execute the pokes without having a perfect match.  However, this is proving harder than I initially realized.

(Note, another user fixed 3.5 and has released it on userscripts.org.)

There are about eight different places that Facebook can change that could break the script.  I won't run through them all here, but needless to say, it is impossible to predict and anticipate these changes.  For example, prior to this last update, the ID that was assigned to the poke DIV element was named pagelet_netego_pokes.  Facebook has renamed the DIV element to pagelet_pokes.

Facebook uses ajaxify to load a large majority of it's modules (e.g. pokes, birthdays, stories, photos, etc).  This means most of these elements load in the background.  Instead of waiting for these elements to completely load, the 4.0 script now downloads a copy of your homepage to evaluate.  This fixes a HUGE bug where pokes were not being processed because the elements do not completely load.

Even though the script doesn't use the DIV element, it still relies on the ID, which is used within ajaxify to actually load the poke node.  Unfortunately, this is something that cannot be changed due to the mere fact that Facebook can change this div to something completely random.

Facebook has already done this to many of their elements.  If you view the source of the Facebook frontpage, you'll notice many of the linked script names are Df69GCI-zBW.js, 4gR9cTpQYHa.js, etc.  I assume this is done so that the files can only be used once can the source cannot be downloaded conveniently.  Those who know what they are doing (like yours truly) can download these files without much hassle.

The poke link detection is based on the fact that the poke engine (e.g. the actual webpage that processes all pokes) has the word "poke" in it.  Originally, the link detection was based on the link text having the word "poke" in it.  This was changed to allow non-English speakers to use the script.  If Facebook changes things again so that these IDs are randomized, the script will have to fail-back to searching for the work "poke" within the link text, breaking the script for non-English users.

Another change that Facebook has made is how pokes are processed.  This used to be a POST form, which meant encoding the form parameters.  But now, it looks like Facebook is changing this to GET.  (FWIW, this used to be how Facebook did things back in the day.)  Unfortunately, this is something that the script cannot anticipate and must be hard-coded.

As development on 4.0 continues, I will attempt to make the script as adaptive as possible.  But please understand that it is impossible to anticipate everything.  Hopefully, it will be more resilient than it's predecessors.

Development on Facebook Autopoke 4.0 to start next week

A long awaited update to my most popular greasemonkey script will begin sometime next week.  The following changes will be made my autopoke script:

• a complete rewrite of the script from the ground up!
• use xml_httprequest instead of GM_xml_httprequest to save time and overhead
• better poke detection
• poke war count
• localization for any facebook language
• better use of xpath and other tools that have been introduced

I know that this script is being used on other browsers (e.g. Opera, Google Chrome, etc) but please realize that I can only focus on one browser: Firefox.  You are more than welcome to port the script to your own flavor of browser.

Release date is unknown at this time, but I'm hoping for September 2011.

zagg replacement utility uploaded

I released a script that goes through each order that you have with zagg and shows only orders where a replacement can be made.

Have at it.

wikiHow Helper - 0.1 ALPHA released

Welcome to the official blog of the tailgate software repository!  This blog will announce releases and other news for the repository.

I have a lot of scripts on the burner right now.  The one I'm releasing today is the wikiHow Helper script.  Due to it's complexity, I'm only releasing small features at a time.  It makes heavy use of the document.evaluate function so it may not work in non-Firefox browsers.

Please visit the project's change log and release notes for details on how you can help debug the script.