Last month, eWeek reported that PayPal intends to block unsafe browsers from accessing their site. They’ve focused on phishing detection and support for Extended Validation SSL Certificates. So what are these features, and why does PayPal think they’re critical? And just which browsers are they likely to block?

Phishing protection has an obvious appeal for a site whose accounts are one of the biggest phishing targets on the web.  Opera 9.1 and up, Firefox 2, and Internet Explorer 7 check the websites they visit against lists of known fraudulent sites. These browsers will warn the users before they accidentally type their credentials into a bogus log-in form. While this makes no difference when a user is already on PayPal’s site, it does mean the user is less likely to get his or her password stolen, and thieves are less likely to carry out fraudulent transactions with the account.

Extended Validation or EV certificates are like normal SSL certificates: they encrypt your web activity to prevent eavesdropping. What makes them different is that EV certificates require the issuer to verify the site owner more thoroughly. Browsers with EV support will display an indication that the site has been verified, usually by turning part or all of the address bar green. This is intended to give the user greater confidence that the site is legit. EV certificates are currently supported by IE7 and development versions of Opera 9.50 and Firefox 3. (You can preview a version of Opera with EV support by downloading Opera 9.50 beta 2.)

(It’s worth noting that Opera 9.50 beta 2 is stricter about verifying EV certificates, and will not show PayPal with a green bar because it loads images and scripts from another site. More recent preview releases will, like IE7 and Firefox 3, be satisfied if the main page is EV and the resources are all protected by regular SSL.)

So which browsers might get turned away at the gate?

In a follow-up story, PayPal clarified that they have absolutely no intention of blocking current versions of any browsers, and that they would only block obsolete browsers on outdated or unsupported operating systems. So an Opera 9 user on Windows XP isn’t likely to get shut out of PayPal anytime soon. But a Windows 98 user might have cause for concern.

Browser detection is extremely tricky to get right, requiring frequent adjustments. It looks like PayPal intends to take the minimalist approach: Assume most browsers are capable of handling what you send them, and only block the problematic ones.

It is finally official. Opera Dragonfly is the name for Opera’s forthcoming developer tools. The alpha will be released on the 6^th of May. The application won’t be feature complete, but shows a good foundation of what Opera Dragonfly will become, and the vision of the app. Even in its current form, it is very useful for debugging web sites, and certainly far better than what we have had previously.

It’s important that web developers and designers that will find a use for Opera Dragonfly leave feedback once the alpha is released. This will let us know what functionality is important, and what improvements we need to add. We are committed to making Opera Dragonfly a first class developer tool, that fits the needs of real world web developers.

This is the first project I’ll be the lead of the launch, so it should be an interesting and busy couple of weeks. Things are looking very positive so far. I’m looking forward to seeing developers use Opera Dragonfly and seeing how easier it makes debugging issues in Opera. The easier this process is the better it is for web developers, Opera, and especially our users who will benefit from better web site compatibility in the long run if Opera Dragonfly is successful.

The Desktop team today released a new snapshot of Opera 9.5 beta containing some pretty significant changes to Opera’s handling of document.all.

From the Desktop team blog:

“Too many sites check for support of document.all and assume that the browser is Internet Explorer. As a result, they often give Opera code that is designed only to work with Internet Explorer’s bugs, which Opera does not have. If they fail to detect it, they use standards compliant code instead, which would work with Opera.

“Occasionally, sites use document.all correctly without testing if it exists, and without providing a standards-based approach, which is why we added document.all support in the first place. Cloaking will cause the first case to use the standards approach, while allowing the second to continue to function.

Opera’s new cloaking behavior of document.all follows that of Firefox and Safari. Hopefully with this change, many of the webpages containing legacy code will start giving Opera the same code as Firefox, rather than of the buggy IE.

Opera’s JavaScript guru, Hallvord Steen, wrote about it in his blog today. He provides a bit of background to the obsolete document.all and its successors document.getElementById and getElementsByTagName.

Update: I should point out that the change of Opera’s handling of document.all is still experimental at this point. The Desktop team is looking for your feedback on this; let them know if this change breaks any sites in Opera.

There has been lots commentary and discussions regarding Microsoft’s solution to fix compatibility issues between various versions of Internet Explorer (IE). For a good background on this, read Aaron Gustafson’s post on the A List Apart blog.

So what do Opera, Mozilla and Safari think about IE’s brilliant solution?

I’ve gathered some quotes and snippets from various blogs of people from Opera, Safari WebKit, Mozilla, and the WaSP.

Håkon Wium Lie, Chief Technology Officer at Opera (Read more)

“Finally, it seems, Microsoft has decided to take Web standards seriously. Designers will no longer have to spend countless hours trying to get their pages to look right in Internet Explorer while adhering to standards. Unfortunately, I think that the celebration is premature. I predict that IE 8 will not pass Acid2, after all.”

Maciej Stachowiak, Safari Webkit (Read more)

“Finally, while we sympathize with the tough road that the IE team has to travel to achieve a high degree of standards compliance, we haven’t really experienced the same problem. The IE team has mentioned severe negative feedback on the IE7 release, due to sites expecting standards behavior from most browsers, but IE6 bugs from IE.

But WebKit already has a high degree of standards compliance. And we are not in the enviable but tough position of being the most widely used browser. The fixes we do for standards compliance rarely cause widespread destruction, and when they do, it’s often a sign that the standards themselves may need revision. We do not get complaints from web content authors about their sites breaking, on the contrary we get a lot of praise for each version of the engine handling web sites better.”

Doron Rosenberg, Mozilla (Read more)

“And since IE8 still does IE6 mode, most web applications will probably not bother updating their code to work with IE8’s changes and continue to use the IE6 mode even when no one actually runs IE6. Why should someone spend money to update the app to use the new IE changes when they can run the old code just fine. And use Silverlight for more advanced things, of course.

The question is, how long will this cycle continue? Web standards are supposed to avoid this exact issue”

Anne van Kesteren, R&D, Core-Specs, Core QA at Opera (Read more)

“This only leads to IE9 getting a different mechanism for the opt-in switch, because, obviously, if a lot of pages uses “IE=edge” without the author’s consent, IE9 would break all those pages, and that wouldn’t be acceptable to MS. So we end up with yet another switch.”

Ian Hixie, Google and editor of the HTML 5 spec (Read more)

“It will also increase the complexity of authoring by an order of magnitude. Big sites will become locked in to particular IE version numbers, unable to upgrade their content for fear of it breaking. Imagine in 18 years — only twice the current lifetime of the Web! — designers will not have to learn just HTML, they’ll have to learn 4, 5, maybe 10 different versions of HTML, DOM, CSS, and JS, just to be able to maintain the various different pages that people have written, as they move from job to job.”

Chris Mills, Developer relations manager at Opera (Read more)

“Microsoft have decided to try to save themselves the shame of breaking the web any more by introducing version targeting to web pages, that is, you can now add a <META> element to your document’s <head>, to specify which IE rendering engine your markup/code should be rendered by.”

Mike Shaver, Director of Ecosystem Development at Mozilla (Read more)

“So we’re going to see X-UA-Compatible in IE8, with very high likelihood. It’s positioned as something that other browsers could use — if they wanted to ship multiple rendering engines to make download size a further impediment to competing with Microsoft, say, or totally lock themselves out of the mobile market”

Robert O’Callahan, Mozilla (Read more)

“The truth is that you can’t ever actually freeze those old versions completely. If a security bug or crasher bug is found in any one of those engines, it must be fixed in each engine it occurs in. Those fixes can create compatibility problems, so your “compatibility guarantee” turns out to be a mirage. But you have successfully multiplied the cost of security fixes and testing those fixes by the number of engines you’re supporting.”

Hallvord Steen, Core QA at Opera (Read more)

“The web and the spec would benefit enourmously if your team sat down to do the detailed analysis work - hunting through the sites that break, figuring out the main problems, suggesting ways the still-in-progress HTML5 standard could change to make real compatibility possible. It’s slow but you can make a public comittment and draw huge grassroot support from web developers. I bet you would get help doing evangelism and outreach for sites that serve you “error correcting” CSS you can’t possibly work with in standars mode. You can release IE8 beta versions but delay the final until site compatibility problems are resolved.”

Dean Edwards, The Web Standards Project (WaSP) (Read More)

“I won’t support any more cruft added to HTML without hearing the reasons. “Don’t break the Web” is a way to befuddle us. Tell us what your real concerns are and we will try to help. We are not hear to rubber-stamp the first crazy idea that you come up with.”

Al Billings, Mozilla QA Engineer (Read more)

“This new mode, and the change to standards mode within IE, just enables IE to continue to hold back the improvement of the web.”

John Resig, JavaScript Evangelist, Mozilla (Read more)

“Wanna know how I can tell that no other browser vendor participated in the creation of the new meta X-UA-Compatible tag? Because it’s completely worthless - and in fact harmful - for any browser to implement!”

Robert Accettura, Mozilla contributor (Read more)

“Why not do like WebKit, Mozilla, and Opera do and start providing nightlies so developers can actively track issues? Why are web developers left in the dark through most of the process? It doesn’t seem like anything is really a closely guarded secret. You can keep the UI stuff private and just release updates to the rendering engine. That’s essentially what WebKit does. CSS3 isn’t exactly a business secret.”

The CVS pharmacy website is notorious for blocking Opera users from accessing its homepage. When visiting cvs.com with Opera, you’re forwarded to a page saying:

“You have landed on this page, because we do not currently support your web browser and/or browser version.”

“Our site currently supports the majority of Mozilla-based and Internet Explorer browsers on Windows and Macintosh systems. However, we do not support Opera, Beta versions, or recent releases of some browsers. We hope to remedy this in the near future.”

Google Search Bot also blocked
Here’s the problem for CVS and others who only allow Internet Explorer (IE) and Mozilla browsers: The GoogleBot is neither IE nor Mozilla, and thus they too will be blocked from view the site.

Here’s proof. Take a look at the Google’s cached version of cvs.com; it shows the same ‘upgrade’ message Opera users see. (See screenshot below)

We at Opera have contacted CVS a few times over the past few years, each time telling us that they’re working on ‘Opera support.’ Nothing has ever happened. Needless to say, Opera works perfectly on cvs.com; I see no issues at all.

So after cvs.com neglected Opera users for this long, we’ve taken the matter into our own hands.

Fixing sites with Browser.js ua.ini
We’ve just updated our browser.js ua.ini to give the ability for Opera users to visit the cvs.com homepage.

With browser.js, Opera is able to modify and change the code of the webpage before the browser renders the page. We use it to fix sites that refuse to recognize Opera. The browser.js file is automatically updated on your computer every two weeks. (To manually get the latest browser.js version, go to Help > Check for updates).

Now when you go to cvs.com, Opera will identify itself as Firefox when it requests the page from the server. CVS now gives you the correct webpage instead of the bogus upgrade error.

Of course we’re taking a risk with this (i.e. identifying as another browser). CVS won’t see any Opera visitors in their site logs, which surely won’t compel them to fix their issues with Opera.

Sprint and Open the Web
My next Open the Web pet project is Sprint. I can’t login into my Sprint account when not identifying myself as either IE or Firefox. I’ve emailed the developers working on that part of Sprint’s site, but have yet to receive a response.

(This is how Google sees cvs.com)

A complaint I hear many times about Opera is “why don’t some sites work in Opera when they do perfectly in Internet Explorer (IE) and Firefox?”

The answer to that question is quite tricky. There can be many reasons for why sites wouldn’t render or work properly in Opera.

A common issue is that certain Web developers assume there are only two browsers in the world, IE and Netscape/Firefox. These developers write code that specifically is on the lookout for only those browsers, leaving out alternative browsers such as Opera and Safari.

What do I mean by this? I suggest you read the blog post by Haavard, who works in Opera’s QA department, about this very issue.

His post highlights the urgent awareness that is needed among Web developers. Developing websites for only the top two browsers prevents millions of alternative browser users from accessing those sites.

(Read Haavard’s blog post)

From an article on Law.com:

“There is no excuse for failing to design Web sites that are compatible with all major browsers. Sure, IE continues to command the bulk of the market. But why would a firm exclude users of other browsers, particularly when it is the more tech-savvy users who opt out of IE? This is the problem with the careers page on the Web site of Patton Boggs. It works fine in IE, but try to open the page in Firefox and it comes up as a screenful of black. Switch to Opera and you get the same. Did no one at Patton ever test this page in a browser other than IE?”

Hallvord Steen, one of our JavaScript experts wrote a detailed blog post on his quest to get Yahoo Mail to work in Opera. His post, which is very technical, highlights our efforts and determination to fix site compatibility issues with Opera.

Last year Hallvord wrote a post here on Opera Watch detailing the issues of site compatibility in Opera.

The Register published an interview with Opera’s founder CEO Jon von Tetzchner. The interview covers many areas of interest to Opera users: desktop, Opera Mini, Opera Mobile, Firefox, Opera Widgets, Mobile browsing, security and site compatibility.

Reactions in the blogosphere:

“I believe that the future of browsers is in open source based engines, just because the nature of browser engines suiting perfectly for open source development, but Opera keeps proving me wrong along side the massive IE.”
(Source: Northern Dialogue)

“Great interview”
(Source: Open Gardens)

(Read the interview)

Update: Here’s a Slashdot discussion on this interview.

David Berlind’s ZDNet blog post titled “Tragedy: Commercial developer reports 35% of coding time spent on IE/Firefox incompatibilities” highlights the importance for web browser vendors to support Web standards.

Why should your code render and work differently depending on the browser of your choice? As a web developer myself, who’s has spent countless hours and days dealing with many browser incompatibility issues, I see Web standards as a necessary and urgent solution. Web standards add to productivity, and as a result developers have more time to focus on boosting Web innovation.

In an era where the web is increasingly moving outside of the PC to mobile phones, TVs, consumer electronics, gaming consoles, and anywhere else you could possibly imagine, web standards are the only way the keep the web sane and out of chaos.

When Apple released Safari for Windows, part of me was happy. Like Opera, Safari is well known for its commitment to Web standards. Having Safari on Windows, the OS of choice for many web developers, would encourage developers, and more importantly browser vendors, to support standards. Wishful thinking…

Let’s bring an end to the quirks and hacks.

Last week the Opera office in India took upon them a project to contact the webmasters of 50 websites and work with them on fixing their sites in order to make them work properly in the Opera browser.

The India office has a team of 8, but only 2 of them work in Opera’s Open the Web (OtW) department. For this project, however, the entire office joined.

They intended to target these 50 websites in 4 days, but managed to complete it in only 2. (With the extra 2 days left, they went on to create a total of 8 new Opera Widgets.)

Good work guys. Now we have 50 better websites out there.

Yesterday I mentioned that Silverlight will work in the Opera browser. Now David Storey, the Chief Web Opener at Opera, revealed in a blog post a bit more about the support for Opera.

Microsoft is serious about supporting Opera. The Silverlight team has been working with Opera on making sure the browser will support Silverlight. And as you can see from the picture below, Silverlight will work with Opera.

In fact Microsoft invited us to the Mix conference in Las Vegas for the announcement that Opera will be supported in Silverlight.

I commend Microsoft for reaching out and working with us on making Silverlight truly cross-browser compatible (unlike some other big companies that forget about Opera).

(Read David Storey’s blog post)

Microsoft Silverlight 1.1 Developer reference.
(Click to enlarge)

Microsoft Silverlight, which is a cross-browser plug-in for creating rich interactive applications, is getting lots of buzz these days.

I’ve seen many complaints on blogs and forums about Silverlight not working in Opera. I will have a bit more information about this later, but for now I can just say that Silverlight will work in Opera.

More later.

Update: More details on Silverlight support in Opera

Earlier this year I blogged about a patch to get some of the offending Google services, such as Google Spreadsheet, Google Calendar, Picassa Web and Google Docs, to work in the Opera browser.

Long story short, Google made some changes to some of these products, further breaking support in Opera. Now Opera user João Eiras (aka xEarth) fights back again by updating his original patch to make these Google services more Opera-friendly (Downlod the updated patch).

Over in the Opera forums an Opera user wrote the following, which I suspect is a sentiment expressed by many other Opera users about Google’s lack of support for Opera.

“…the severe shortness of a script that fixes all functionality issues with Google docs, Google spreadsheets, Picasa, and Google calendar should be telling. That Google, one of the biggest companies around can’t find the time to test in Opera is shocking; that one man working alone can write a 140 line (including comments) script consisting of a handful of simple fixes should reflect far, far worse on Google than it does on Opera. Especially when you consider that they somehow find the time to work past IE innumerable flaws.”

I’ve spoken with David Storey, who heads Opera’s Web Opening team, about Google. He mentioned to me that various Google teams are working with Opera to solve some of the issues in the browser. For example Opera is actively working with Google’s GWT team (GWT is their Ajax library), and they are currently reporting as well as fixing issues (even working around an opera bug). In addition, their Maps team is also very responsive.

Opera has a dedicated Web Opening team that is constantly working with sites, big and small, to help solve compatibility issues with Opera. This team does a superb job. They don’t merely contact the site and simply let them know there’s a problem with Opera; they actually troubleshoot the problem first and then contact the site webmasters with specific information on what’s causing the problem and instructions on how to fix it.

Opera’s Chief Web Opener, David Storey, posted on his blog a wish list for 2007 (developer edition). If you’re a web developer, take a look at it – especially his 5th item on the list.

David now heads the Web Opening team at Opera Software. When users submit bug reports about sites not working correctly in the Opera browser, and the problem is with the website code (not a bug in the browser itself), the Web Opening team contacts the site developers and usually works with them on fixing the offending code.

The day the Wii Opera browser was released, for some reason YouTube stopped working on the Nintendo device. David was the one to handle the issue; he blogged about it here.

Here’s a neat little hack to make some of the offending Google services work better in the Opera browser.

Joao Eiras, an Opera user, wrote a small Opera User JavaScript file (Download patch — How to install) that patches some of the incompatibilities with Google services, such as Google Docs, Google Spreadsheet, Google Calendar, and Picasa Web.

Opera’s User JavaScript acts in a similar way as GreaseMonkey, the Firefox extension, only it’s built into the Opera browser. These scripts allow you, the visitor of a site, to directly manipulate the content (HTML, JavaScript, etc) of the page.

There’s a collection of other Opera User JavaScript files on this site (UserJS.org); it seems, however, that the site has been dormant for a bit.

(via Google OS and WebProNews)