Tuesday, November 16, 2010

Just -Why- is IE bad?


I've done a few posts about other Internet browser options (Chrome, Firefox, Safari, Opera), and what's good about the others, but never really explained clearly why the rest are so much better compared to Microsoft's Internet Explorer (IE).
So here goes...

W3C Standards
You first should understand when your browser software requests a webpage the data it receives is typically clear text with Hyper-Text Markup Language (HTML). HTML is text with special encodings within it that tell the browser software how something should graphically be displayed.
So when a webpage contains something like...
This <i>is <b>encoded</b> with</i> <u>HTML</u>!
That tells your browser to italicize "is encoded with", and bold-face "encoded", and underline "HTML"...
This is encoded with HTML!
And there's lots of markup encodings that can be used. Everything from text styling/sizes, colors, positioning/layout, linking, all that kind of stuff.

The "World Wide Web Community" (W3C) have developed certain Standards; what the community agree on for what tags should do what. And while there are minor quirks and differences among all browsers, they pretty much all render things the same... except IE. With IE though, it appears Microsoft has decided, "since we have the biggest market-share (thanks to IE being pre-installed with Windows), we'll make our browser work however we want."  Because of that, now web designers have to implement several different encodings and "hacks" in order to achieve some level of consistency in how their pages appear across different browsers. Take for example this HTML (which rather than in-line HTML tags it uses something called Cascading Style-Sheet, or CSS encoding, but exact same issues in IE)...
<div style="width:200px; height:25px; text-align:center; border-radius: 10px; border:2px solid black;">I'm in a styled div </div>
If you view that in any W3C Standards compliant browser you'll get a nice little rounded box around the text...
I'm in a styled div
However, view it in IE and the dimensions are slightly off and you get no rounded corners at all. If the designer really wants be sure to get rounded corners they have to create graphic images for each corner and fight with exact positioning (using the previously mentioned "hacks"), and your browser then takes longer to load the page because it has to then also download those graphic images to display. And that's just for a rounded corner effect... once you start trying to implement positioning on the page, and nesting of elements within other elements or nearly anything beyond bold, italicize, or underline it just keeps getting worse! And the designers have to either write code on the server-side that changes the HTML sent down to your computer depending on the browser you're using, or they have to send down extra HTML to try to target all browsers. In either case, things take longer if they have to be able to work in multiple browsers. So web design and innovation gets slower trying to keep things consistent for IE. Browsing the Internet is slower because of all the extra stuff that has to be downloaded or built. And most developers even give up on making sure IE works the way they intend things to work, and just say "close enough" and move on. So the user-experience with websites is even worse in IE.
There are lots of things webpages could do, but because there's pretty much no way to achieve the same thing in IE, they're not used at all. So quite simply IE holding back design and innovation!

JavaScript
Most webpages have some level of client-side scripting in them. This is program code, typically written in JavaScript (JS), that runs in the client-side browser to do various things. Most commonly manipulating elements on the page in response to the user's actions. Finally the latest versions of IE are getting consistent with using the same keywords / properties (though people using old versions of IE are likely to still have problems).
But when the browsers need to run the script there is some pretty technical stuff going on and while IE does generally do the stuff, it is WAY slower at it. Now generally client-side script is very short simple things so the differences between 0.01 seconds and 0.1 seconds may not seem like much, as pages get better more sophisticated those speed differences continue to grow. Take for example something like Google Docs (docs.google.com) which is completely browser-based document/spreadsheet editing or Gmail (www.gmail.com) or other high-end web apps. Those things that need to do a lot of client-side work, can easily start showing the weight of IE; in most other browsers something that may take 1 second could take 10 in IE!


There is a popular browser javascript speed test here... http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
Just as an example I ran this on my system in Chrome, Firefox, and Safari three times in each. The average scores were... (bigger numbers = better)
Chrome v7.0 got 3,532
Safari v5.0.2 got 1,913
Firefox v3.6.2 got 422
For IE I only run it once because every couple seconds it constantly was popping up...
And I had to continuously click the "No" to finally get a single test to complete. And for that...
Internet Explorer v8.0 got 77.4


More on Speed
In addition to client-side script speed, there's also a significant issue of speed in regards to parsing and displaying a page. When your browser software sends a request for a webpage your Internet connection speed affects how long it takes to get the HTML/content of the page downloaded to your computer. But once that's downloaded the browser software then has to figure out what the page says and how to actually display it. This is of course primarily dependent on the speed of your computer, but also heavily on the browser software. Pages with a lot of content or complex layouts take significantly longer to display in IE than pretty much any other browser.

Another speed tests that tests some other things than JavaScript such as dynamic changes to page elements is the Acid3 test... http://acid3.acidtests.org/
Chrome 100/100
Safari 100/100
Firefox 94/100
IE 20/100 and "FAIL" ? (That really does say it all! LOL)

Security
There is a standard accepted way webpages can be encrypted and transmitted securely (HTTPS). And pretty much all browsers handle HTTPS just fine. But for additional security, when implemented in a network infrastructure correctly, IE is probably better in that respect. But for probably 99% of users, the security of IE is like using a fire hose when you want a straw.

Sweet Feature of the ..whenever I post them..

So here's a really handy feature of Google Chrome's omnibar... it does math!

Type an equation in the bar and in the "suggested searches" list that drops down from it, it will display the results of your math formula. Even some pretty complex equations and unit conversions!

For example, how many liters are in a 12 pack (12 ounce cans) of pop? Type in...
(12 * 12) ounces in liters
And you'll see a 12 pack is about 4.25 liters...

Thursday, November 11, 2010

Malicious URLs / Phishing

Just a quick reminder about how URLs ("web addresses") and security work...

URL Formation
Given a particular URL...
http://www.google.com/#hl=en&...

The first part, "http" in this case, is the "protocol". There's a few different things you may see here, but nothing you generally need to be concerned with.  Although it is worth knowing that when the protocol is "https" that means data is encrypted before being exchanged between your browser and the server. On pages where you're entering sensitive data (SSNs or credit card numbers), you should check that the page is secured ("https://").

Then after the protocol seperator ("://") is the "domain name". Domain names are basically a tree path, seperated by the dots, and formed right to left. The right-most dot-something group (".com") in this case is referred to as the root domain. Then moving to the left the next sub-domain, the "first level" domain is google. And then one more sub-domain, a "second level" domain of www.
Anything after the first slash after the domain name ("/#hl=en...") all has to do with the path to resources on that site, and all irrelevant to the rest of this info.

This often mis-understood right-to-left organization is something malicious sites tend to try to take advantage of. They register domain names but then apply sub-domains (parts on the left of the first level domain) to make them appear legitimate.
For example, I received an email about a Password Reset from a service I use, and the email had a link to their reset page. I'm sure if I went to the page it would look like the real service's page and ask me for my "old password", which if I provided of course they'd then have my account password and be able to hack my account.  The URL was...
http://us.battle.net.blizzard-password-us-eu.net/account/login.html?ref=https://www.worldofwarcraft.com/...
Which the first level domain name they used is actually ".blizzard-password-us-eu". The real service they're trying to impersonate "us.battle.net".

Public Networks
And if you're using a public network (library, coffee shop, etc), you should probably also make sure any page where you provide a password (or any sensitive data) is also secured. This is because any data you send out on a network, can be seen by other people on that network. But if you're on a page using HTTPS while anybody can still see the encrypted data, it will be just jargon to them.
For example (and rather surprisingly), Facebook's default home / log on page is not secured! If you just type "facebook.com" in and hit Enter you'll be taken to http://www.facebook.com/. If you then log on to that your logon credentials can potentially be seen by anybody on the same network.  With most sites like this though, it is also possible to explicitly provide the https and still use the site as normal. So while just typing "facebook.com" and hitting Enter takes you to the unsecured page if you explicitly put "https://facebook.com" you can still use the site and log in as normal, but now your data is protected.

So in short...
Before providing passwords be sure to check the first level domain you're on and that you know it's legitimate. And before providing anything like SSNs or credit cards (or any private data when on a public network) the page is using a secured (HTTPS) protocol.