Staying inside the (guide)lines

Posted by: Browsium Tags: , Posted date:


I’m a believer in following the rules. As a company we may challenge some rules to be innovative, but following rules has been part of our DNA from the beginning. Rules are part of our product approach – we believe in opt-in solutions where our products are used in a surgical manner. Following rules has helped us ensure our products don’t break the browsing experience. Most importantly, our approach has avoided any complications when Microsoft updates the Windows OS or Internet Explorer. We comply with Microsoft browser extension developer guidelines for all of our software solutions.

Going back to the early history of Browsium, looking at alphas, betas and release versions, we have delivered products for more than 2.5 years without anything breaking on a single Windows update. It’s an important statistic, and one that I’m very proud to share with customers. Our developers work very hard to make this happen, ensuring they follow only public documentation and use public APIs or other supported Microsoft coding practices.

The Browsium team has a long history of experience working with Microsoft, with many of the “Browsians” having worked on engineering and product management teams at Microsoft. That experience enables us to understand the browser in ways no other group outside Microsoft would, including the quirks and internal workings of Internet Explorer. But we’re also very careful in how we use what we learned at Microsoft. We realize that using our knowledge of the browser code and internal (aka not public) designs would not only raise intellectual property issues, it would leave us exposed to breaking changes. Microsoft is free to make breaking changes to any undocumented API or feature control key, etc. at any time. Using only public sources and APIs prevents that exposure.

Sometimes this means we need to proceed slowly to release new versions, more slowly than we or our customers would like. But the trade-off is too great and we want to do all we can to ensure that patching customer systems won’t break our software.

So what will go wrong if Microsoft needs to change something they expose publicly or deprecate one of their APIs in a future release of the browser? Nothing. Microsoft has made plenty of changes from IE8 to IE9 and beyond. We expect (and want) that to continue. We’ll identify what they did and get to work on ensuring our products work properly with the new version. We’re actively doing that now as we prepare to support IE10 and Windows 8.

What happens if Microsoft makes a change to an existing browser to break or deprecate a function we are using? Given that we follow the rules they’ve established, it would impact the entire extension ecosystem and that’s not something Microsoft is inclined to do without significant advanced notice for everyone to provide a workaround.

Going further than just updates, building our software in this way has a more important impact on customer systems. Your Windows installations are supported. We’re not changing the way Windows works or virtualizing the browser so when you call Microsoft for support, our software meets their guidelines. It’s also easy to disable for troubleshooting, like any well-behaved add-on should.

By staying inside the lines we are able to deliver innovative solutions to solve difficult browser compatibility and management problems for enterprise customers, without the worry of future support by Microsoft. Check out Ion and Catalyst to see how we can solve these problems for you.

Matt Heller
Founder & CEO

  • Share:  

Recent Posts

Unlocking Advanced Solutions for Browser Management and Legacy Applications Compatibility
Posted on: September 13, 2023
Legacy Browser Application Modernization Best Practices
Posted on: August 16, 2023
Enterprise Browsers, AI and Web 3.0
Posted on: June 22, 2023

Request Demo

Internet Explorer End of Life problems?Learn More