Well, its not often that I have had a bad word to say about Mozilla Firefox. However, for the second time in a week, I now do.
I have been aware of issues with the Mozilla implementation of eval for some time, but the latest exposure was news to me and seemingly many others.
Full details can be found here. There is no reliable way round that I can find as yet so I will continue along the assumption that in the JavaScript world, nothing is safe.
I will still use a module pattern (as I have discussed before in a previous post) and I will still call "private" members private. I will also continue to discourage the use of evil eval.
Douglas Crockford has a few things to say about Firefox in general and had his own comments about this latest issue.
I am deeply disappointed frankly. Firefox 3 ruined my week last week (well, truthfully, Firebug was as much to blame) and now this. I suppose its nice to see that other browser vendors make mistakes!
skip to main |
skip to sidebar
This is where you can find out all about interface development.
Whats good, whats not good and most importantly, why!?
The JSquared JavaScript Library
About Me
- James Norton
- A certified scrum master and highly experienced front end UI web developer specialising in building cutting edge accessible, feature rich, interactive websites. An expert in unobtrusive object oriented JavaScript and AJAX techniques with a unique light touch approach. Currently working for EMC Consulting.
Get more
Labels
- Accessibility (4)
- ADIJ (3)
- Agile (1)
- AJAX (2)
- Browser support (11)
- Browsers (12)
- Conditional Comments (1)
- CSS (11)
- CSS 3 (3)
- CSS reset (3)
- ECMAScript (1)
- Firebug (1)
- Firefox (1)
- FXSquared (2)
- Google Chrome (1)
- HTML (3)
- HTML 5 (4)
- Interface development (7)
- Internet Explorer (4)
- Internet Explorer 8 (1)
- JavaScript (19)
- JavaScript 2 (3)
- jQuery (1)
- JSquared (21)
- Mobile (1)
- off-topic (6)
- Opera (1)
- Process (1)
- Progressive enhancement (6)
- rant (2)
- Scrum (2)
- Tools (2)
- Twitter (2)
- Usability (2)
- Web standards (7)
Other places to go
Posts
The views expressed here are those of James Norton and do not represent the views of any other organisation including but not limited to any current or past employer.
3 comments:
Why is this a problem? I am not including any scripts in my page which someone else wrote, so why do I need to worry about this? The web is not designed for that.
If I do include someone else's scripts in my page, I will host them from my site, so I know what they're doing.
I am not sure I understand your comment. This is an issue as now there is absolutely no chance of having privately scoped members of an object. Closures are not protected in any way.
This is a client side issue - it does not matter where you host the scripts from. You could even open up Firebug and break the closures.
I understand good OO means having a small API etc... but this argument is about security and 'safeness'?
I'm unclear on how you would secure a javascript application from any such sort of attack? As you are delivering the source code directly to the browser, and anyone can just view it, what difference does it make if you are protecting private variables from being read/altered in firebug? What harm could they do outside of the scope of the browser?
I am just unclear on the need for browser security and trying to understand the issues. As long as your services cannot be compromised I can't see the problem, so I am probably missing something.
Post a Comment