As most of you are aware, we are "competing" in the semi-finals at InsideRIA for a discussion at Adobe Max. When I say compete, you might conjure up images of banner ads on web sites, Twitter posts and Facebook messages. Nearly all of the contestants have done things like that (just look at their respective web sites) and it seems fair. In fact, part of the purpose of the competition is to drum up interest in InsideRIA and the above tactics are well within the spirit of that goal.
However, we noticed some irregularities within the process. Certain sites, some of which were hundreds of votes behind, jumped 500 votes overnight and then stagnated for a while, only to surge again when the sites would again lag behind.
Armed with the realization that something didn't smell right, we decided to investigate to see if the system could be gamed.
We came across the X-Forwarded-For HTTP header which is primarily used with proxied requests to indicate the true IP address of the client. Or, as we discovered, it can be used to trick the poll into thinking that the request was coming from any IP address specified in this header. All a scripter would have to do is send a POST to http://www.oreillynet.com/pub/pq/237 (the poll results page) with a body of qid=237&aid=[poll choice value here] (in our case it was 1289) and add the header "X-Forwarded-For: [Random IP address here]". Send the post 500 times with 500 random IP addresses and voila! you have 500 votes for your company!
We are not going to use this exploit ourselves (and would have only shared this with InsideRIA had we not noticed it already being used by others). We do wish to point out that participating in a competition that has an obvious exploit that can be used by competitors makes us rather uncomfortable. I hope InsideRIA will fix this exploit and start the competition (which ends this coming Sunday night) over from scratch.
Just a heads up. There will be a maintenance window from 4am - 6am EDT early Thursday morning while we upgrade our servers. Aviary will be unavailable for part or all of that time.
We apologize for the inconvenience to anyone this affects and will make it up to you by eating a delicious double-fudge chocolate sundae. Yum.
Hi! My name is Iz and I'm a technoholic. I love reading about technology, tinkering with hardware and most of all - I love buying gadgets. Unfortunately (or fortunately - depending on whether or not I have to clothe and feed you) I'm also extremely... er... let's call it frugal. It's not that I'm flat out cheap, it's just that I know the difference between want and need. I want a big-screen, surround-sound home theater system that can be controlled by an iPod Touch. However, I realize that all I need is a dedicated 20Mbps symmetrical fiber optic line to my house and a computer to access it on. See? Its simple!
However, the line between want and need can get blurred when an item in my want column suddenly goes on sale. For example, the iPod Touch that I want is currently out of my range at $300. If for some reason, Apple would decide to slash prices on the coolest MP3 player in history and suddenly make it $200, that want becomes an Itch. Make it $150 and - boom - now I need it!
At this point you may be wondering, "OK, you like toys but are too cheap to pay for them. So?" Well, building software comes down to a lot of the same choices and thought processes as buying crap. The touch-screen, refrigerator mounted, tablet PC becomes a feature that you may or may not implement. On the one hand - it's cool and some of your users may love it. On the other hand, many of your users won't care and implementing this cool feature may push your release date back a few weeks.
Sometimes, we have the real world equivalent of a sale: The situation changes making it more practical and inexpensive to implement a wanted feature. Scenarios include user feedback, competition or a technology breakthrough... anything that lowers the cost to (or raises the price of not) adding the feature. Suddenly, the want becomes a need and will make it into the next release.
The fun part - at least for the coders, is the actual design and implementation of the feature. Careful consideration of methodologies employed in producing the feature comes into play and this is where the programmers are supposed to shine. A good programmer keeps a need from sliding back into the want column, by making the most functionality using the least amount of resources possible.
So the next time you wonder why every household doesn't have a floor-washing robot, your favorite mp3 player doesn't have an FM radio or why your online word processor can't handle outlines, think about whether those products or features are actually needs or merely wants and you can understand why they were included or left out. At the very least, it will help you crystallize an explanation to your spouse as to why you need a PS3.
< view newer posts | view older posts >
Try Out Aviary»
Aviary is a powerful suite of browser-based design tools for people who create. Head on over to the Aviary homepage to try the applications out and learn more. It's free to try our tools or sign up!
RSS
Email