Firefox 4 is out! If you for some reason don’t know why you want it here’s a few things you’ll love about Firefox 4.0.
Congrats to everyone involved in shipping.
Firefox 4
Reply
Category Archives: Mozilla
Things You’ll Love About Firefox 4.0
It’s that time again. Here’s my list of awesome things you’ll love about Firefox 4:
For Users
New Look For Tabs
One of the first things that you’ll notice is tabs on top. This paradigm really makes more sense since the tab defines not just the content but the environment it’s viewed (prev/next button, URL bar). It’s also just much sleeker looking. After a few minutes you’ll likely agree this is a better approach than tabs under.
Another nice touch is if you enter a URL that’s already open in another tab, you’ll be given the option to switch to that tab. Perfect for those of us who end up with 50 tabs by lunch time.
It also just feels tighter and less intrusive on the web browsing experience.
Wanted: Native JS Encryption
I’d like to challenge all browser vendors to put together a comprehensive JS API for encryption. I’ll use this blog post to prove why it’s necessary and would be a great move to do so.
The Ultimate Security Model
I consider Mozilla Sync (formerly known as “Weave”) to have the ultimate security model. As a brief background, Mozilla Sync is a service that synchronizes your bookmarks, browsing history, etc. between computers using “the cloud”. Obviously this has privacy implications. The solution basically works as follows:
- Your data is created on your computer (obviously).
- Your data is encrypted on your computer.
- Your data is transmitted securely to servers in an encrypted state.
- Your data is retrieved and decrypted on your computer.
The only one who can ever decrypt your data is you. It’s the ultimate security model. The data on the server is encrypted and the server has no way to decrypt it. A typical web service works like this:
- Your data is created on your computer.
- Your data is transmitted securely to servers.
- Your data is transmitted securely back to you.
The whole time it’s on the remote servers, it could in theory be retrieved by criminals, nosy sysadmins, governments, etc. There are times when you want a server to read your data to do something useful, but there are times where it shouldn’t.
The Rise Of Cloud Data And HTML5
It’s no secret that more people are moving more of their data in to what sales people call “the cloud” (Gmail, Dropbox, Remember The Milk, etc). More and more of people’s data is out there in this maze of computers. I don’t need to dwell too much about the issues raised by personal data being stored in places where 4th amendment rights aren’t exactly clear in the US and may not exist in other locales. It’s been written about enough in the industry.
Additionally newer features like Web Storage allow for 5-10 MB of storage on the client side for data, often used for “offline” versions of a site. This is really handy but makes any computer or cell phone used a potentially treasure trove of data if that’s not correctly purged or protected. I expect that 5-10 MB barrier to rise over time just like disk cache. Even my cell phone can likely afford more than 5-10 MB. My digital camera can hold 16 GB in a card a little larger than my fingernail. Local storage is already pretty cheap these days, and will likely only get cheaper.
Mobile phones are hardly immune from all this as they feature increasingly robust browsers capable of all sorts of HTML5 magic. The rise of mobile “apps” is powered largely by the offline abilities and storage functionality. Web Storage facilitates this in many ways but doesn’t provide any inherent security.
Again, I don’t need to dwell here, but people are leaving increasingly sensitive data on devices they use, and services they use. SSL protects them while data is moving over the wire, but does nothing for them once data gets to either end. The time spent over the wire is measured in milliseconds, the time spent at either end can be measured in years.
Enter JS Crypto
My proposal is that there’s a need for native JS Cryptography implementing several popular algorithms like AES, Serpent, Twofish, MD5 (I know it’s busted, but still could be handy for legacy reasons), SHA-256 and expanding as cryptography matures. By doing so, the front end logic can easily and quickly encrypt data before storing or sending.
For example to protect Web Storage before actually saving to globalStorage:
globalStorage[‘mybank.com’].lastBalance = "0.50";
globalStorage[‘mybank.com’].lastBalance = Crypto.AES.encrypt("0.50", password);
Using xmlHttpRequest or POST/GET one could send encrypted payloads directly to the server over http or https rather than send raw data to the server. This greatly facilitates the Mozilla Sync model of data security.
This can also be an interesting way to transmit select data in a secure manner while serving the rest of a site over http using xmlHttpRequest by just wrapping the data in crypto (that assumes a shared key).
I’m sure there are other uses that I haven’t even thought of.
Performance
JS libraries like Crypto-JS are pretty cool, but they aren’t ideal. We need something as fast and powerful as we can get. Like I said earlier, mobile is a big deal here and mobile has performance and power issues. Intel and AMD now have AES Native Instructions (AES NI) for their desktop chips. I suspect mobile chips who don’t have this will eventually do so. I don’t think any amount of JS optimization will get that far performance wise. We’re talking 5-10 MB of client side data today, and that will only grow. We’re not even talking about encrypting data before remote storage (which in theory can break the 10MB limit).
Furthermore, most browsers already have a Swiss Army knife of crypto support already, just not exposed via JS in a nice friendly API. I don’t think any are currently using AES NI when available, though that’s a pretty new feature and I’m sure in time someone will investigate that.
Providing a cryptography API would be a great way to encourage websites to up the security model in an HTML5 world.
Wait a second…
Shouldn’t browsers just encrypt Web Storage, or let OS vendors turn on Full Disk Encryption (FDE)?
Sure, both are great, but web apps should be in control of their own security model regardless of what the terminal is doing. Even if they are encrypted, that doesn’t provide a great security model if the browser has one security model in place for Web Storage and the site has its own authentication system.
Don’t JS Libraries already exist, and isn’t JS getting the point of almost being native?
True, libraries do exist, and JS is getting amazingly fast to the point of threatening native code. However crypto is now being hardware accelerated. It’s also something that can be grossly simplified by getting rid of libraries. I view JS crypto libraries the way I view ExplorerCanvas. Great, but I’d prefer a native implementation for its performance. These libraries do still have a place bridging support for browsers that don’t have native support in the form of a shim.
But if data is encrypted before sending to a server, the server can’t do anything with it
That’s the point! This isn’t ideal in all cases for example you can’t encrypt photos you intend to share on Facebook or Flickr, but a DropBox like service may be an ideal candidate for encryption.
What about export laws?
What about them? Browsers have been shipping cryptography for years. This is just exposing cryptography so web developers can better take advantage and secure user data. If anything JS crypto implementations likely create a bigger legal issue regarding “exporting” cryptography for web developers.
Your crazy!
Perhaps. To quote Apple’s Think Different Campaign
Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes.
The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.
About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward.
Maybe they have to be crazy.
How else can you stare at an empty canvas and see a work of art? Or sit in silence and hear a song that’s never been written? Or gaze at a red planet and see a laboratory on wheels?
While some see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.
Time to enable the crazy ones to do things in a more secure way.
Updated: Changed key to password to better reflect likely implementation in the psudocode.
On Chrome Dropping H.264
The Chrome team announced they are dropping support for H.264.
WebM Support
WebM support will be growing quickly as Firefox 4 rolls out (Firefox upgrade adoption is legendary). Chrome commands sizable market share and is pushing the Chrome OS platform. Opera is also supporting WebM.
Apple and Microsoft could join the party and bundle WebM support along with the other codecs they support at any time, though they are licensors for H.264 and wouldn’t benefit from WebM market penetration. Microsoft’s implementation does allow for VP8 support if a codec is installed. I’m not aware of anything for Safari and am rather certain nothing can be done for the iPhone without Apple intervening.
On the hardware side AMD, ARM, Nvidia are backing WebM. Broadcom announced support, as did Qualicomm and TI. These are major vendors for mobile chips. Intel is working on stuff too.
H.264 Trouble
H.264 is problematic and bad for the web for many reasons I’ve mentioned here before as well as great posts by roc and shaver. I’ll leave it at that rather than rehash.
There was buzz a while back about H.264 being “free” (quotes intentional), but it’s not really “free” if you read the fine print. As Peter Csathy of Sorenson Media notes:
But, you say, MPEG LA recently announced that it will no longer charge royalties for the use of H.264. Yes, it’s true – MPEG LA recently bowed to mounting pressure from, and press surrounding, WebM and announced something that kind of sounds that way. But, I caution you to read the not-too-fine print. H.264 is royalty-free only in one limited case – for Internet video that is delivered free to end users. Read again: for (1) Internet delivery that is (2) delivered free to end users. In the words of MPEG LA’s own press release, “Products and services other than [those] continue to be royalty-bearing.”
That’s hardly “free”. That’s just one potential use case that’s now royalty exempt. The reason they are doing that is presumably if they can get H.264 adoption high enough, all the other cases will be paying and therefore subsidizing this one case.
WebM is licensed a little different: Patent wise, it’s irrevocably royalty free. License is about as liberal as you can get.
There’s no proprietary html, css, or images (GIF was, now it’s dead) used across the web. Why should video be any different? The key to success and growth has always been an open platform that’s low cost and encourages innovation.
Implementing Today
For anyone who suggests that this further fragments the market, that’s not really true. Adobe Flash actually creates an excellent shim to help migrate away from Flash to <video/>. Allow me to explain:
Adobe will soon be supporting WebM through Flash. Adobe already support H.264 in Flash. For legacy browsers and those who won’t support WebM, you have the option of delivering a Flash experience just like most websites do today. There are websites doing this today via Flash and H.264. For modern browsers you can just use <video/>. Once your non-WebM market share drops low enough, you can get rid of the Flash experience. Soon enough you’ll be able to push WebM to your Flash users. The benefit of switching your Flash experience to WebM as a middle step would be one encoding for both delivery mechanisms vs. using H.264 and WebM in parallel. Of course if you’re supporting mobile you likely need H.264 for a bit longer but likely use a smaller resolution and different profile for mobile consumption.
No matter what there will be two delivery mechanisms for those looking to push video using HTML5 to users today. The only thing that changes is the lean towards standardizing on the actively developed WebM codec vs. H.264.
All new technology has speed bumps, that’s the cost of being on the bleeding edge. However this is a positive turn as things are now starting to line up. The most awesome thing is that the codec, HTML5 specs, and some of the most popular browsers in the world are open and inviting feedback and contributions to improve things.
Firesheep Is Just The Messenger
I must say that I’m glad to see there are no plans to pull Firesheep. Add-ons have a lot of power since they run in a privileged space. Anything your browser can access, your add-ons can access. The point to being able to kill add-ons was to protect the user in situations where an add-on was either bundling malware or sending information without the users consent. Firesheep does none of that. It behaves exactly as advertised. It also causes no harm to the user or their computer.
Firesheep doesn’t do anything that couldn’t be done with a packet sniffer, it just makes it trivial enough that the average person can do it. It just makes a flaw in many websites more visible. The more technical folks have known this for years. Firesheep is just the messenger. These insecure bits of traffic have traveled across the wire for a decade or more. All traffic across Ethernet is visible to all devices. This is how Ethernet works. The network is a shared medium. It’s just a matter of looking at it. WiFi is a slightly different ballgame but at the end of the day if a wireless signal is unencrypted, it’s just a matter of listening.
I am not a lawyer (nor do I play one on TV) but from a legal perspective I suspect Gregg Keizer is correct in suggesting that it’s likely legal under federal wiretapping statutes (ethics is another debate). However a company likely can still fire you for using it, and a school likely can still kick you out for using it on their network. Private networks have their own rules and policies.
That covers the detection of a session. If you were to actually session jack, that would likely be considered fraud, hacking, identity theft, etc. depending on what you do. Generally speaking, unauthorized access to a computer system is illegal. If you are using someone else’s credentials, that’s by definition unauthorized access.
Electronic communications law is hardly considered developed or mature but generally there isn’t an expectation of privacy when no encryption is used and transmission is done over a shared connection. It’s akin to speaking to someone on the street and being overheard. That said, if someone reads their credit card number while on a cell phone call and you use the credit card information you overheard, it’s still fraud regardless of the interception method.
Bottom line: It’s time to start securing connections.
Firesheep Demonstrates The Need For SSL
There’s been a storm of discussion over the past 72 hours about Eric Butler’s Firefox extension Firesheep. To summarize, it’s a Firefox extension that facilitates session hijacking by packet sniffing for data from certain websites. As far as software goes, it’s more evolutionary than revolutionary, at its core it’s a packet sniffer. The evolution is the pretty UI which makes it trivial to hijack someone’s session (he really did do a good job on the UI, it’s so easy a child could use it).
It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure. Anyone can read what’s going across the wire (that includes WiFi) when it is sent unencrypted. If your browser can interpret and use the information to let you browse Facebook, Twitter, etc. so can any browser, on any computer. It’s that simple. Firesheep only supports a handful of sites, but adding support for more sites isn’t difficult. If your favorite website hasn’t been done yet, I expect it will be soon enough.
How Do You Protect Yourself?
The best way to protect yourself is to demand that websites that hold private information use HTTPS from the moment you log in until you log out. Short of that, the best you can do is use a Firefox extension like EFF’s HTTPS Everywhere to force your browser to use HTTPS. This won’t work everywhere as not every web server even has HTTPS working, but many secretly do. They sometimes use HTTPS for certain things like login, then use insecure HTTP for the rest of your visit. That’s so your password isn’t transmitted in plain text. Protecting a password is important, but if the session is insecure anyone can intercept what you do. HTTPS Everywhere works by rewriting all requests to many popular sites to use HTTPS ensuring your privacy and security through the length of your visit. Some websites will have minor issues. For example Facebook Chat is impossible to support right now due to it not working via HTTPS. The rest of Facebook however works.
For more advanced users, HTTPS Everywhere lets you write your own rulesets for sites it doesn’t support.
How Do Websites Protect Their Users?
It’s very simple. Use HTTPS for the period a user is logged in, not just when authenticating and submitting sensitive data. Sure it’s a little slower and requires more hardware, but scaling HTTPS these days isn’t nearly as difficult as it was just 5 years ago. In 2 years it will be even easier. Google went as far as forcing HTTPS upon all of Gmail users. Binding a session to an IP address is fussy and largely ineffective due to NAT, WiFi hotspots and mobile services that can cause an IP to just change with little/no notice. It’s not effective security. It’s better than nothing, but it’s not a fix.
Google could make a huge difference by supporting SSL in Google AdSense, something I’ve called for since 2008. Google has supported SSL with Google Analytics for some time, but they have lagged with rolling out support in other services. Lots of websites monetize with AdSense and this is just another reason websites put off supporting SSL. Other ad networks should do the same. Google AdSense has the least barrier to entry since they serve their text ads off of their own infrastructure, vs. creatives hosted by other parties like some smaller ad networks. One could argue having third-party code inserted on a page mitigates security but it would still be a major improvement over the current state of affairs and would prevent simple session jacking.
On HTML5 And The Future Of Privacy
Today’s alarmist without much research news is “New Web Code Draws Concern Over Risks to Privacy” about HTML5 and its threat to privacy. How evil of HTML5 and its creators.
The Real Deal
Persistent cookies are nothing new. Essentially the strategy works like this: Store data everywhere you can on the users footprint, and if data it deleted in a few locations, you copy it back from another location the next time you can. It’s regenerative by design. A popular example is evercookie which uses:
- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in and reading out Web History
- Storing cookies in HTTP ETags
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
Note that several of these aren’t HTML5 specific. More than one of which isn’t cleared by just “erasing cookies”.
HTML5 does add a few new possibilities, but they are also by design as easy to control, monitor and restrict as your browser (or third-party add-on) will allow. HTML5 storage mechanisms are bound to the host that created them making them easy to search/sift/manage as HTTP cookies. Much worse are some of the more obscure cookie methods (Flash Cookies, various history hacks). They don’t really provide any more of a privacy risk than what the browser already has been offering for the past decade.
To Shut Up The Geolocaiton Conspiracy Theorists
Before someone even attempts the “Geolocation API lets advertisers know my location” myth, lets get this out of the way. The specification explicitly states:
User agents must not send location information to Web sites without the express permission of the user. User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below. The user interface must include the URI of the document origin [DOCUMENTORIGIN]. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context [BROWSINGCONTEXT] is navigated to another URL) must be revocable and user agents must respect revoked permissions.
Some user agents will have prearranged trust relationships that do not require such user interfaces. For example, while a Web browser will present a user interface when a Web site performs a geolocation request, a VOIP telephone may not present any user interface when using location information to perform an E911 function.
To my knowledge no user agent implements Geolocation without complying with these specifications. None.
No HTML5 Needed For Fingerprinting
Even if you do manage to wipe all the above storage locations, you’re still not untraceable. Browser fingerprinting is the idea that just your system configuration makes you unique enough to be traceable. This includes things like your browser version, platform, flash version, and various other bits of data plugins may additionally leak. The EFF recently did a rather impressive study to learn about the accuracy of this technique. Computers with Flash and Java installed sport 18.8 bits of entropy and result in 94.2% of browsers being unique in the EFF study [cite, pdf]. Of course their data was likely skewing towards more experienced web users who are more likely to have an assortment of customizations to their computer (specific plugins, more variety in web browsers, operating systems, fonts) than the average internet user. I’d wager that their data downplays the effectiveness of this technique.
The idea that HTML5 is a privacy risk is FUD. It doesn’t provide any worse security than anything else already out there. It’s actually easier to counteract than what’s already being used since it’s handled by the browser.
The Future
I still believe all browsers out there can do a much better job of protecting privacy when it comes to local data storage for the purpose of tracking. What I believe what needs to happen is web browsers need to start moving away from the “cookie manager” interfaces that are now a decade+ old and move towards a “my data management” interface that lets users view and delete more than just cookies. It needs to encompass all the storage methods listed above as supported by the browser. Hooks should also exist so that plug-ins that have data storage (like Flash) can also be dealt with using the same UI.
Additionally it needs to be possible to control retention policies per website. For example I should be able to let Google storage persist indefinitely, Facebook for 2 weeks, and Yahoo for the length of my browser session should I wish.
My personal preference would be for a website to denote the longest storage time for any object on a webpage in the UI. Clicking on it would give a breakdown of all hostnames that makeup the page, what they are storing and let the user select their own policy. With 2 clicks I could then control my privacy on a granular level. For example visiting SafePasswd.com would give me a [6] in the UI. Clicking would show me a panel this:
+------------------------------------------------------------------------------+ | My Data Settings for SafePasswd.com: | | | | Host Longest Requested Lifespan Your Choice | | | | *safepasswd.com 2 years [site default] | | googleads.g.doubleclick.net 6 years [browser session] | | | | | | (Done) (Cancel) | +------------------------------------------------------------------------------+
I could then override googleads.g.doubleclick.net to be for the browser session via the drop down if that’s what I wanted. I could optionally forbid it from saving anything if that’s what I wanted. I could optionally click-through for more detail or view the data to help me make my decision. Perhaps this would also be a good place for P3P like data to be available. One of the notable failures of P3P that impeded usage was it was never easy to view so it never caught on.
The browser would then remember I forbid googleads.g.doubleclick.net from storing data beyond my browser session. This would apply to googleads.g.doubleclick.net regardless of what website it was used on.
This model works better than the “click to confirm cookie” model that only a handful of people on earth ever had the patience for. It provides easy access to control and view information with minimal click-throughs.
It also makes a web page much more transparent to an end-user who could then easily see who they are interacting with when they visit one webpage with several ads, widgets, social media integration points etc.
One click to view data policies, two clicks to customize, three to save.
HTML5 is not a risk here. The web moving to HTML5 is like going from the lawless land to a civilized society where structure and order rule.
Decrypting The Internet
Bruce Schneier on the new wiretapping proposal:
Any surveillance system invites both criminal appropriation and government abuse. Function creep is the most obvious abuse: New police powers, enacted to fight terrorism, are already used in situations of conventional nonterrorist crime. Internet surveillance and control will be no different.
Official misuses are bad enough, but the unofficial uses are far more worrisome. An infrastructure conducive to surveillance and control invites surveillance and control, both by the people you expect and the people you don’t. Any surveillance and control system must itself be secured, and we’re not very good at that. Why does anyone think that only authorized law enforcement will mine collected internet data or eavesdrop on Skype and IM conversations?
I 100% agree here. A security vulnerability, intentional or not is a vulnerability. Even systems with no known security holes are eventually broken. Look at the recent reverse engineering of HDCP, which was theorized as vulnerable in 2001 but not broken for several years, a pretty good run. Eventually all security mechanisms will be broken. Starting with something broken just increases the window of opportunity for abuse and misuse.
In theory this proposal could (I’m no lawyer, I don’t even play one on TV) even impact things like Firefox Sync (Formerly Weave) which employs the best security mechanism I’ve seen in a service. To summarize, it works by encrypting your data before transmission to the server. However the key is never sent. That means even if the Gestapo took the servers with your data, they would still need to get the key from you, or do battle with the encryption which isn’t easy. Even Mozilla can’t read your data, unless a flaw were found in the encryption algorithm. The question is if sync were considered to fall under “services that enable communications”. That seems broad enough to leave room to argue that sync facilitates communication since the browser is the ultimate communication client. The browser is also valuable since it potentially has passwords, bookmarks, and history giving a good motivator to make that argument. Argue that to a 75-year-old judge who never used a computer and it might work.
Meanwhile just weeks ago UAE ironically gets criticized by the US for proposing a Blackberry ban for the same reasons.
About HTML5 Boilerplate
I wanted to take a few minutes to discuss HTML5 Boilerplate, a template that’s rapidly going around the web development community. I’ve had a few email threads and chats about this recently and thought I’d just put all my thoughts together in one place now.
I’ll start by saying it’s not a bad template. It’s actually quite good and encompasses many best practices as well as incorporates fixes for many common problems (clearfix, pngfix). What I’d like to make note of is that it’s not really bringing you HTML5 and lots of what it does has nothing to do with HTML5.
Not Really HTML5
For starters you’re not really getting HTML5. HTML5 Boilerplate uses JavaScript library called Modernizr. As their website explains:
Modernizr does not add missing functionality to browsers; instead, it detects native availability of features and offers you a way to maintain a fine level of control over your site regardless of a browser’s capabilities.
It also lets you apply styles to the new semantic HTML5 elements like <header/>, <footer/> <section/>.
What don’t you get? Well for starters you’re missing <canvas/> and <video/>. Other than tag elements you’re also missing things like Gelocation, Drag&Drop, web storage, MathML, async attribute on <script/> to name a few. SVG?
Pretty much all the headliners in the HTML5 spec aren’t included. Some like <canvas/> could be helped by way of explorercanvas, but that’s not in there by default.
HTML5 Boilerplate also makes reference to things like Access-Control which still doesn’t work in older browsers. They also suggest setting mimetypes for HTML5 video. This isn’t by any means bad, but hardly makes <video/> useful to everyone. Browsers are still pretty fragmented between webm, ogg, and h.264 (mp4). Then you have older versions that support none of these.
Using gzip on ttf,otf,eot files seems to be a good idea. WOFF however are compressed and correctly excluded.
WTF Does This Have To Do With HTML5?
There are lots of things that I would consider best-practices, but would hardly consider to be HTML5. For example pngfix for IE6, .clearfix, apple-touch-icon, console.log wrapper being the most obvious.
Setting far-future cache times are good, and disabling Etag is a good idea, assuming you rename the file every time it updates. But what does this have to do with HTML5? Is this even practical for everyone?
Then there is some interesting css work like inline print block. There are also a couple of nice usability fixes that I like. Regardless, they are just good design and UX. Not HTML5.
As for the graceful degradation and mobile optimization… that’s design and css. There is no reason why any HTML4 or XHTML site couldn’t do that today. Most choose not to do so in favor of serving different content (including ads) to different devices.
Options -MultiViews… grumble. I’m not particularly fond of it, but again if it works for you, I wouldn’t push you away from it.
Removing www… I hate this one. In my experience the only people who insist upon this have never dealt with websites with high volume and had the requirement of using a CDN by way of a CNAME in front of your site (your domain must be an A record). What is the real benefit here other than some sort of URL ascetics? I’ll let you in on a little secret: The IP address for this blog is hardly maximizing feng shui.
Best Practices != HTML5
Many of these things are best practices. Some of these depend on your application. Most of these aren’t HTML5.
Lets just clarify that HTML5 is not about disabling MultiViews getting rid of the Etag header and being able to style <section/> elements. HTML5 is more than that.
Your ability to use HTML5 still depends on widespread adoption of modern browsers like the latest and upcoming versions of Firefox, Chrome, Safari, Opera, and even IE 9.
Again, HTML5 Boilerplate is not a bad starting point. My point is you’re not really getting as much as it initially sounds like. It’s a bunch of fixes you likely already have in your toolkit already assembled. If that’s helpful: great. But don’t think your missing out on a new era of the Internet by not adopting it. Most good web developers have done these things for a long time now.
Filing Good Bugs
Writing good bugs is important when dealing with software development. I deal with several Bugzilla installations meaning I’ve got some experience with both good and bad bug reports. While the specifics may vary based on the product your submitting a bug report for these basics rules will make life easier for everyone. In many cases will even help things get resolved quicker.
Bugs that are easy to triage, sort and sift are easier to take care of than those that are cryptic and require more investigation. If you want your issue to be addressed promptly make sure you facilitate the process by writing a good bug report. It’s not difficult and doesn’t require much technical know how, it just requires being explicit yet concise. If more information is needed a developer can request it and explain how to capture it.
Summary
A good summary is explicit yet brief. Upon reading it the purpose is clear and little is left to question. Here are several poor summaries, and the ideal way to submit them:
Bad: “add me to planet”
Good: “add john doe to planet.mozilla.org”. There’s no ambiguity there. Just reading the subject I can distinguish it from others in the queue.
Bad: “site crashes browser”
Good: “visiting a video permalink page crashes IE6″. Less ambiguity just make sure to add the url to the bug.
Bad: “javascript error”
Good: “Contact form has a javascript error in Chrome”. Again less ambiguity is key.
Description
Descriptions should ideally be front loaded with the important information. If it’s a bug report and not a request it should be followed by steps to reproduce including what you see, and what you expect to see. Reference attachments as appropriate (screenshots can be helpful).
Bad: “Visiting a video permalink page crashes IE6.”
Good: “Upon visiting a video permalink page in IE6 the video automatically starts playing. About 10 seconds into the ad the browser crashes. I am able to reproduce this consistently at the following link: http://domain.tld/…”.
Bad: “Contact form shows a JS error, can’t submit.”
Good: “When attempting to submit the contact form [http:/doman.tld/...] in IE 7 I get a “object expected” error and it refuses to continue.”
Always include URL’s when applicable or examples on ways to reproduce the error when possible. It’s hard to act upon “several pages” when your site has over a half million pages.
Attachments
Screenshots, traces, debug logs, mockups are generally helpful. As a rule make try to use browser-readable formats when possible. JPEG, GIF, PNG for images, txt, or if you must PDF for documents. Having to open PowerPoint or Word to view your screenshot isn’t cool. It makes people avoid what would be helpful information. Explanations on what you’re seeing and expect to see are also helpful for when it’s not obvious to someone else.
Severity/Priority
Always try to use restraint when setting the severity or priority on a bug. Unless it’s truly a show stopper avoid using the most severe status. Generally speaking most “normal” or a P3 (on a P1 – P5 priority scale). Remember The Boy Who Cried Wolf.
Version
If you know the version, please specify it. It helps when several versions of a product are still floating around.
Product/Component
I put this toward the bottom for a reason. Making a best guess is the most you can generally do. Just be sure to read the entire list before deciding as the best option may be beyond the one you’ve already found.
Following these simple guidelines can go a long way to making sure bugs get resolved quicker.