MaxStocker.com   MaxStocker.com    
   
Home About Blog Stuff Contact
 
   
 

February 2009

Facebook API
Posted : Fri February 27th

More CRTC bungling
Posted : Thu February 26th

Up and down
Posted : Mon February 23rd

Don't lie
Posted : Fri February 20th

Blog layout updates
Posted : Wed February 18th

100!
Posted : Mon February 16th

I predict the future (and try not to look foolish)
Posted : Sun February 15th

Why fulfilling demand is sometimes a mistake
Posted : Thu February 12th

Looking for that special valentine gift?
Posted : Wed February 11th

Grrrrrr
Posted : Wed February 4th

Office 2007 Ribbon et al
Posted : Sun February 1st

Chrome Server : First impressions
Posted : Mon January 26th

Outsourcing IT : how much are you really saving?
Posted : Sun January 25th

AJAX to Servlet
Posted : Sat January 17th

Recent Comments

Max in Whose blog is it anyway?
on Mon May 10th

Rob in Whose blog is it anyway?
on Fri May 7th

Anonymous in SEO and the magic beans
on Thu April 8th

Max in SEO and the magic beans
on Thu April 8th

n.o. in SEO and the magic beans
on Thu April 8th

silky in Right way, wrong way
on Fri February 19th

Categories

Technical
69 Entries

Security
18 Entries

Java
23 Entries

Privacy
6 Entries

Database
11 Entries

Internet
58 Entries

Business
31 Entries

Site Updates
19 Entries

Personal
86 Entries

RSS Feed RSS Feed

Tag Cloud

Why fulfilling demand is sometimes a mistake
Posted : Thursday February 12th, 2009

When it comes to anything really but particularly software development, sometimes people feel that every whim should be catered to, every need filled and every request served. But so often it pays much better to address the real, underlying issue that is the source of the "need" in the first place.

As an example for sometime there was no way in Java to get the MAC address of a network adapter. Now to begin with as a caveat, "no way" isn't entirely true. One could do it, but it required native code or using executing another process (like ipconfig). But true enough there wasn't a Java API method to do it.

But there sure were alot of requests (read demands) for this feature.

So lo and behold in Java 1.6 Sun added a method getHardwareAddress() to the java.net.NetworkInterface class that returns the MAC address.

And all was well.

Or not

What's actually happened is the questions about how to get and use the MAC address have actually increased. The problem is that exactly zero of these questions now (or ever before) were based on a valid idea. Nineteen times out of twenty the "requirements" that lead to the MAC address questions are security related. That is that the questioner is attempting to use the MAC address to authenticate a user. This couldn't be more wrong-headed.

As a quick aside it's wrong headed for a bunch of reasons, not the least of which being it provides exactly zero-security. It is trivial to change a MAC address on most computers these days. Plus it has the added drawbacks of not working when it otherwise might and generally frustrating the real users all while doing nothing to discourage the malicious ones.

Back on point, I'm hard pressed to imagine a better example of when giving the masses what they "need" is actually a step-backward. It's never a good idea in my opinion to encourage bad security ideas and thoughts rather than addressing the real underlying problem. Which in this case is a total lack of understanding of what authentication means, how it works, and what it must have to be successful. Namely an authentication model that allows trivial spoofing is a failure.

Besides all this what about that one in twenty who does have a real need for the MAC address? Well to be honest one in twenty is high because I haven't seen one yet, but nevertheless such information was always available really. One just needed to spend a bit of time figuring out how.

Tags

address  bad  ideas  Mac 

Categories

Technical  Java  Security 

Comments

 
   
  Follow me on Twitter   My Facebook Profile   My LinkedIn Profile   RSS feed of my blog Home   |   About   |   Blog   |   Stuff   |   Contact   |   Privacy Policy  
   
  © 2008 Max Stocker