A recent slashdot post caught my eye. It involves two of my favorite topics: e-voting and lockpicking. According to the slashdot article, Diebold (a company which makes e-voting machines) recently posted, on their own freaking Web site, high-quality images of the key which can be used to unlock the access panels on their e-voting machines. The images were apparently good enough that it was possible for someone to make a quick trip to Home Depot, buy a metal file and a few blanks of the right kind of key, file the keys to the correct shape, and start unlocking Diebold machines.
Word to the wise: next time you feel like photographing your keys (and let's face it, who doesn't love photographing their keys?), put the pictures in a scrapbook on your bookshelf, not the Internet.
31 January 2007
flickr: more 'screw the users!' from yahoo
Yesterday photo-sharing Web site Flickr (owned by yahoo) announced some changes which have angered lots of their users. Each flickr user will have to start signing in with his/her yahoo account username/password (lots of users currently log in with a flickr username/password, so they'll have to change), and there are some new limits being imposed on flickr data (there will soon be a limit of 3000 contacts and a limit of 75 tags per image).
I only recenty started using flickr, and have used my yahoo account for all of that time. And the new limits don't affect me. So this isn't too big a deal for me personally. But it's another example of arbitrary changes imposed with little or no warning or user involvment, much like the recent utter ruination of yahoo TV. Not everything they do is horrible: I like the new yahoo mail (beta). But if they keep alienating their users, they may find that their shiny new upgrades aren't that good for business.
I only recenty started using flickr, and have used my yahoo account for all of that time. And the new limits don't affect me. So this isn't too big a deal for me personally. But it's another example of arbitrary changes imposed with little or no warning or user involvment, much like the recent utter ruination of yahoo TV. Not everything they do is horrible: I like the new yahoo mail (beta). But if they keep alienating their users, they may find that their shiny new upgrades aren't that good for business.
Image inputs in MSIE7 -- revisited
My previous post was a whinefest about image inputs in MSIE 7. This problem turns out to be worse than I thought. In that post, I said that the problem could be circumvented by taking either of two measures, one of which was changing to a submit-type input element. Today I found out that this solution is inadequate, because the name/value pair are still not sent in the POST data if you hit return rather than clicking the submit button.
<* input type="submit" name="ick" value="gakkk" />
If you actually click the submit button in a form (in MSIE 7) containing the above code, then the ick/gakkk pair will be included in the POST data. But if you just hit the return key in the form (which is how I typically submit forms), the ick/gakkk pair won't be sent.
So, I'll have to stick with the other corrective measure and put the ick/gakkk pair in a hidden input, replacing the above HTML with this:
<* input type="hidden" name="ick" value="gakkk" />
<* input type="submit" value="MSIE 7 blows" />
Crap.
<* input type="submit" name="ick" value="gakkk" />
If you actually click the submit button in a form (in MSIE 7) containing the above code, then the ick/gakkk pair will be included in the POST data. But if you just hit the return key in the form (which is how I typically submit forms), the ick/gakkk pair won't be sent.
So, I'll have to stick with the other corrective measure and put the ick/gakkk pair in a hidden input, replacing the above HTML with this:
<* input type="hidden" name="ick" value="gakkk" />
<* input type="submit" value="MSIE 7 blows" />
Crap.
09 January 2007
Image inputs in MSIE7
I saw a post in the last couple of days saying that <* input type="image"> doesn't work in MSIE7. I've recently been working on a project which happens to have one of these elements. I tested it in MSIE7 today, and sure enough, it doesn't work. But it's broken in a very subtle way.
The element in my project looks like this...
<* input type="image" name="ick" value="gakkk" src="button.jpg" />
...and the interface to which this form POSTs looks for the ick field. Looks to me like MSIE7 just doesn't send any name/value data in one of these elements when the form is submitted. All the other form fields make it into the POST data, just not the ick/gakkk pair.
Either of the following seemed to make it work as expected:
*sigh* Just one more stupid thing I have to remember when designing Web applications.
The element in my project looks like this...
<* input type="image" name="ick" value="gakkk" src="button.jpg" />
...and the interface to which this form POSTs looks for the ick field. Looks to me like MSIE7 just doesn't send any name/value data in one of these elements when the form is submitted. All the other form fields make it into the POST data, just not the ick/gakkk pair.
Either of the following seemed to make it work as expected:
- turning the input element into a normal type="submit"
- moving the ick/gakkk name/value pair into a hidden input element in the form
*sigh* Just one more stupid thing I have to remember when designing Web applications.
07 January 2007
Ice storm aftermath
Pictures taken after an ice storm in Versoix, Switzerland. The icicles on the trees are pretty amazing.
This was posted on digg.com, where several of the commentors said that since the ice blew in off Lake Geneva, it's not really an ice storm. Whatever. It's a lot of ice.
Brrrrr.
This was posted on digg.com, where several of the commentors said that since the ice blew in off Lake Geneva, it's not really an ice storm. Whatever. It's a lot of ice.
Brrrrr.
Subscribe to:
Posts (Atom)