Enigma Conference 2020 – Browser Privacy Panel

Brave, Mozilla Firefox, Google Chrome and Microsoft Edge presented on our current privacy work at the Enigma 2020 conference in late January. The talks were mostly high-level, but there were a few feature-level slides for each browser.

My ~10 minute presentation on Microsoft Edge was first, followed by Firefox, Chrome, and Brave.

At 40 minutes in a 35min Q&A session starts, first with questions from the panel moderator, followed by questions from the audience.

“Can I… in the new Edge?” (Un-FAQ)

This post is intended to collect a random set of questions I’ve been asked multiple times about the new Chromium-based Edge. I’ll add to it over time. I wouldn’t call this a FAQ because these questions, while repeated, are not frequently asked.

Last Update: May 10, 2021

Can I get a list of all of the command line arguments?

Unfortunately, we are not today publishing the list of command line arguments, although in principle we could use the same tool Chromium does to parse our source and generate a listing.

In general, our command-line arguments are the same as Chromium‘s, with the exception of marketing names (e.g. Chrome uses --incognito while msedge.exe uses --inprivate) and restricted words (sometimes Edge replaces blacklist with denylist and whitelist with allowlist). Note: The peter.sh list linked here is automatically generated; check the Last automated update occurred on text to verify that it was updated recently.

Can I block my employees from accessing the edge://flags page?

You can add “edge://flags” to the URLBlocklist if desired. Generally, we don’t recommend using this policy to block edge://* pages as doing so could have unexpected consequences.

Note that, even if you block access to edge://flags, a user is still able to modify the JSON data storage file backing that page: %LocalAppData%\Microsoft\Edge\User Data\Local State using Notepad or any other text editor.

Similarly, a user might specify command line arguments when launching msedge.exe to change a wide variety of settings.

Can I disable certain ciphers, like 3DES?

The new Edge does not use SChannel, so none of the prior SChannel cipher configuration policies or settings have any effect on the new Edge.

Group Policy may be used to configure the new Edge’s SSLVersionMin (which does impact available cipher suites, but doesn’t disable all of the ciphers considered “Weak” by SSLLabs.com’s test). Microsoft Edge 85+ offers a TLSCipherSuiteDenyList Group Policy. In contrast, Chrome explicitly made a design/philosophical choice (see this and this) not to support disabling individual cipher suites via policy.

Ciphersuites in Edge may also be disabled using a command-line flag:

msedge.exe --cipher-suite-denylist=0x000a https://ssllabs.com

A few other notes:

  • The cipher suite in use is selected by the server from the list offered by the client. So if an organization is worried about ciphers used within their organization, they can simply direct their servers to only negotiate cipher suites acceptable to them.
  • The Chrome team has begun experimenting with disabling some weaker/older ciphersuites; see https://crbug.com/658905
  • If an Enterprise has configured IE Mode, the IE Mode tab’s HTTPS implementation is still controlled by Internet Explorer / Windows / SChannel policy, not the new Edge Chromium policies.
  • If TLS/1.3 is enabled, you cannot use the cipher-suite-denylist to disable ciphers 0x1301, 0x1302, and 0x1303. TLS1.3 spec: “A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).”

Can I use TLS/1.3?

TLS/1.3 is supported natively within the new Chromium-based Edge on all platforms.

Chromium-based Edge does not rely upon OS support for TLS. Windows’ IE 11 and Legacy Edge do not yet support TLS/1.3, but are expected to support TLS/1.3 in a future Windows 10 release.

For the time being, enabling both TLS/1.3 and TLS/1.2 is a best practice for servers.

Can I turn off TLS/1.3?

You can set the SSLVersionMax command line argument, but the associated Group Policy was removed in Chrome 75.

msedge.exe --ssl-version-max=tls1.2 https://ssllabs.com

Can Extensions be installed automatically?

Enterprises can make extension install automatically and prevent disabling them using the ExtensionInstallForcelist Policy. Admins can also install extensions (but allow users to disable them) using the ExtensionSettings policy with the installation_mode set to normal_installed.

Here are the details to install extensions directly via the Windows Registry. Please note that if you want to install extensions from the Chrome WebStore, then you must provide the Chrome store id and update url: https://clients2.google.com/service/update2/crx.

Can specific file types be set to auto-open? Can I change my mind?

After downloading a file, you can click the “…” menu next to the download item and choose “Always open files of this type” from the context menu:

This option is not available for all file types (e.g. file types deemed dangerous cannot be auto-opened).

One challenge with this UI is that after you set this option, the download bar will not be shown for this file type any longer, leaving you no way to untick the “Always open files of this type” menu item.

The secret to changing your mind is to visit edge://settings/downloads and click the Clear all button next to the File types which are opened automatically after downloading list. There is no way to clear just one file type from the list short of editing the profile’s PREFERENCES json directly.

Presently, no Group Policy is available to force file types (except PDF) to open automatically, but this is a common enterprise request. The Master Preferences file can be configured with this option, but those defaults are only used when creating new browser profiles, and users may change them.

Can I go directly to single-word (Intranet) sites without doing a search first?

Can I avoid doing a search with a notification bar saying “Did you mean to go to <http://payroll&gt;?” In Internet Explorer, there was a “Go to an intranet site for a single word entry in the Address bar” checkbox in the Advanced Settings.

Use the GoToIntranetSiteForSingleWordEntryInAddressBar policy to change the default behavior.

Can I use URLs of unlimited size?

Within Chromium, URLs of up to 2mb can be used in general, although some UI surfaces will truncate URLs at 32kb. For performance and other reasons, I would not recommend using URLs over that smaller size.

Can I use configure Edge to use more than 6 connections per host?

No. Using parallel connections as was common in HTTP/1.1 suffers from lower performance and increased load on the server. As a hacky workaround to exceed the 6 connections-per-host limit, some sites use “sharding” which assigns multiple DNS names to a single server. Because browser connection limits are based on the hostname, this allows the client to make 6*NumShards parallel connections.

Chromium exposes only a policy to control the maximum connections per proxy server, but there is no policy to control the maximum connections per web server. This sometimes leads to problems in very niche scenarios, but we have not, as yet, heard a non-trivial number of complaints.

In the ideal case, the site would deploy HTTP/2 or HTTP/3, which multiplex up to ~100 requests over a single TCP/IP connection, eliminating head-of-line blocking and providing much better performance vs. legacy HTTP/1.1.

Can I use Group Policy to turn off HSTS for specific sites?

No. There is no policy that turns of HSTS for a host that had requested it.

The HSTSPolicyBypassList policy description leads users to believe it does something it does not. I filed a bug to get the text clarified.

The policy should read something like:

Setting the policy specifies a list of hostnames that bypass preloaded HSTS upgrades from http to https. Only single-label hostnames are allowed in this policy, and the policy only applies to HSTS-preloaded “static” entries (“app”, “new”, “search”, “play”, etc”). This policy does not prevent HSTS upgrades for servers that have explicitly requested HSTS upgrades using the Strict-Transport-Security response headers. Supplied hostnames must be canonicalized: Any IDNs must be converted to their A-label format, and all ASCII letters must be lowercase. This policy only applies to the specific single-label hostnames specified, not to subdomains of those names.

Some users complain that they’re getting HSTS for “localhost” sites and try to use this policy to prevent that. Localhost is not on the HSTS Preload list. If your browser is HSTS-upgrading localhost, it’s because it received a Strict-Transport-Security response header from Localhost that turned on HSTS. To fix that:

  1. Stop sending the header
  2. On edge://net-internals/#hsts, use the Delete domain security policies section to remove Localhost
  3. Or you can hit Ctrl+Shift+Delete to open the Clear Browsing Data dialog and choose Cached Images and Files. This will delete ALL dynamic HSTS rules.

Can I control Permissions (like Allow Popups) based on the Site’s IP address?

The Permissions system’s “Site Lists” feature does not support specifying an IP-range for allow and block lists.

It does support specification of individual IP literals, but such rules are only respected if the user navigates to the site using said literal (e.g. http://127.0.0.1/). If a hostname is used (http://localhost), the IP Literal rule will not be respected.

How does visiting a site in Internet Explorer open Edge automagically?

Edge installs a Browser Helper Object into Internet Explorer with a pre-provisioned site list.

Other than that, a site can try to launch a link using the microsoft-edge:// URL protocol.

Can I turn off cross-origin security in Edge?

You shouldn’t.

The flag –disable-web-security command line flag is not supported (that is to say, we won’t guarantee what it does or does not allow, and it could disappear at any time), and hasn’t been updated to account for all of the various security features added to the browser over the last few years (see https://crbug.com/1150447). Launching the browser with this flag makes that browser instance inherently unsafe to use. That was also true of the old “Access data sources” flag in IE, although the IE-flag was at least Zone-limited.

The command must be paired with a user-data-dir argument:

msedge.exe –disable-web-security –user-data-dir=C:\temp example.com

Developers should fix the dependent target sites to emit proper Access-Control-Allow-Origin headers so that the web’s same-origin-policy is respected.

If they do not control the target site, they will need to build a server proxy (browser->their-server->remote-server) that sets the correct ACAO headers.

Bypassing AppProtocol Prompts

Starting in Microsoft Edge 77 (and Chrome 77), the prompt shown when launching an AppProtocol from the browser was changed to remove the “Always allow” checkbox. That change was made, in large part, because this prompt is the only thing standing between every arbitrary site on the Internet (loaded inside your browser’s sandbox) and a full-trust application on your computer (running outside of the browser’s sandbox). See the blog post for more details on why AppProtocols are so scary.

After Edge 77, when you try to launch a Microsoft Teams meeting, for instance, you’ll see a UI like this:

Unfortunately, there’s a downside to this security improvement.

The same prompt that protects users from malicious content on https://BadGuy.example also shows every single time the legitimate Microsoft Teams website tries to open its related application. Users complain that the security prompt feels redundant, and IT departments have howled that they’ll have to retrain users and field helpdesk calls.

In Edge 82.0.425.0 Canary, a new flag was added:

…and in Edge 84 it was enabled by default.

The prompt now includes a new checkbox: “Always allow <hostname> to open links of this type in the associated app”:

By storing exemptions on a per-site, per-scheme basis, attack surface is significantly reduced, because only sites you’ve specifically allowed in the past are permitted to bypass the prompt.

This change is also available in other browsers based on Chromium 84+.

Some notes on this change:

  • Exemptions are stored on a per-scheme, per-origin basis (e.g. “Allow teams: from https://teams.microsoft.com“, so if multiple origins use the same scheme, you’ll need to exempt each one.
  • Stored exemptions are origin specific: https://site.example and https://www.site.example and http://site.example are all different origins.
  • Stored exemptions are only available for secure origins (basically: HTTPS, HTTP-to-Localhost, and FILE).
  • This checkbox can be disabled using Group Policy.
  • Starting in Edge 85, a new Group Policy allows an admin to preapprove exemption pairs (including non-secure origins) on behalf of their users.
  • In Edge 86 and later, you can see user-granted and Group Policy pushed exemptions by navigating to edge://settings/content/applicationLinks in the browser. You can also remove user-granted exemptions in this page.
  • To clear all user-granted exemptions (in any version), you may use the “Cookies and other site data” checkbox in the Clear Browsing Data dialog box. Note that you can set the time range to anything you like– all Origin+Scheme exemptions will be cleared.

You can experiment with this feature using the AppProtocol test page.

-Eric

Browser Password Managers: Threat Models

All major browsers have a built-in password manager. So we should use them, right?

I Do

  • I use my browser’s password manager because it’s convenient: with sync, I get all of my passwords on all of my devices.
  • This convenience means that I can use a different password for every website, improving my security.
  • This convenience means that my passwords can be long and hard to type, because I never have to do so.
  • This means that I don’t even know my own passwords for many sites, and because I can rely on my password manager to only fill my passwords on the sites to which they belong, I cannot succumb to a phishing attack.
  • Enabling the Microsoft Edge Password Manager enables security-improving features like Password Monitor (breach detection) and Password Generation (effortless strong passwords)

Should You?

The easy answer is “Yes, use your browser’s password manager!

The more nuanced answer begins: “Tell me about your threat model?

As when evaluating almost any security feature, my threat model might not match your threat model, and as a consequence, our security choices might be different.

Here are the most relevant questions to consider when thinking about whether you should use a password manager:

  • Is a password manager available for your platform(s)?
  • What sort of attackers are you worried about?
  • What sort of websites do you log into?
  • Do you select strong, unique passwords?
  • Are your accounts protected with 2FA?
  • What sort of attacks are most likely?
  • What sort of attacks are possible?
  • How do you protect your devices?
  • What’s your personal tolerance for inconvenience?
  • Are you confident in the security of your password manager’s vendor?
  • If you sync passwords, are you confident in the security of the design of the sync system?
  • Does the password manager offer advanced features like breach detection and automatic password generation?

The answers to these questions might change your decisions about whether to use a password manager, and if so, whether you want to use the built-in password manager or use a password manager provided by a third-party.

For instance, if you’re sharing a Windows/Mac OS login account with someone you don’t trust, you should stop. If you cannot or don’t want to, you should not use a password manager, because there are trivial ways for a local user steal your passwords one-at-a-time and simple ways to steal them all at once. Of course, even if you’re not using a password manager, a co-user can simply use a keylogger to steal your passwords one-by-one as you type them.

Lock (Win+L) your computer when you’re not using it.

While browser passwords are encrypted on disk, they’re encrypted using a key available to any process on your PC, including any locally-running malware. Even if passwords are encrypted in a “vault” by a master key, they’ll be decrypted when loaded in the browser’s memory space and can be harvested after you unlock the vault. Locally-running malware is particularly dire if your threat model includes the possibility of a worm running rampant within your enterprise– it could infect all of your employees’ machines and steal all of their passwords in bulk in seconds. (Yes, dear reader, I know that you’re thinking of clever mechanisms to mitigate these sorts of attacks. I assure you I can defeat every practical idea you have. It’s a fundamental law of computing.)

Concern about instantaneous bulk egress of credentials has led the authors of security configuration guidance to recommend disabling browser password managers. For instance, the Edge Security Baseline and the Chrome STIG both suggest preventing users from using the password manager. (I personally think this is a poor tradeoff that increases the higher risk of individual users getting phished, but I don’t write the configuration guidance.)

Some tech elites advocate for using a 3rd-party password manager, and some users really like them. Most 3rd-party password managers are designed with broader feature sets to satisfy alternative threat models (including using master passwords to help protect against limited local attackers). Many also include additional conveniences like automatic generation of strong passwords and roaming of passwords to mobile platforms and apps. On the other hand, many external password manager applications are themselves a source of security vulnerabilities, and these products often end up growing extremely complicated due to the “Checkbox Wars” endemic to the security products industry.

Parting Advice

Passwords are a poor security mechanism, and should be phased out wherever possible.

When that’s not yet possible (because you don’t control the website): choose strong passwords, use a password manager if it satisfies your threat model, and enable 2FA if available (especially on your email accounts to which password recovery emails are sent).

-Eric

PS: Back in 2017, there was a bunch of press excitement about a privacy threat whereby autofilled credentials from the password manager might allow a website to identify a visitor before the user clicks the Login button. See this post for an exploration of this threat and its mitigations.

Demystifying Browsers

Last update: Feb 24, 2021

I started building browser extensions more than 22 years ago, and I started building browsers directly just over 16 years ago. At this point, I think it’s fair to say that I’m entering the grizzled veteran phase of my career.

With the Edge team continuing to grow with bright young minds from college and industry, I’m increasingly often asked “Where do I learn about browsers?” and I haven’t had a ready answer for that question.

This post aims to answer it.

First, a few prerequisites for developing expertise in browsers:

  1. Curiosity. While browsers are more complicated than ever, there are also better resources than ever to learn how they work. All major browsers are now based on open-source code, and if you’re curious, you no longer need to join a secret priesthood to discover how they operate under the hood.
  2. Willingness to Experiment. Considering how complex browsers are (and because they’re so diverse, across platforms, maker, and version), it’s often easiest to definitively answer questions about how browsers work by trying things, rather than reading an explainer (possibly outdated or a map that doesn’t match the terrain) or reading the code (often complex and potentially misleading). Build test cases and try them in each browser to see what happens. When you encounter surprising behavior, let your curiosity guide you into figuring it out. Browsers contain no magic, but plenty of butterfly effects.
  3. Doggedness. I’ve been doing this for over half of my life, and I’m still learning daily. While historical knowledge will serve you well, things are changing in this space every day, and keeping up is an endless challenge. And it’s often fun.

Now, how do you apply these prerequisites and grow to become a master of browsers? Read on.

Fundamental Understanding

Over the years, a variety of broad resources have been developed that will give you a good foundation in the fundamentals of how browsers work. Taking advantage of these will help you more effectively explore and learn on your own.

  • First, I recommend reading the Chrome Comic Book. This short, 38 page comic book from comics legend Scott McCloud was published alongside the first version of Google Chrome back in 2008. It clearly and simply explains many of the core concepts behind modern browsers as application platforms.
  • HTML5Rocks has a great introduction into How Browsers Work. This is a lengthy and detailed introduction into how browsers turn HTML and CSS into what you see on the screen. Read this article and you’ll understand more about this topic than 90% of web developers.
  • The folks at Google have created a fantastic four-part illustrated series about how modern browsers work: Inside look at modern web browsers. Navigation, the Rendering Engine and Input and Compositing as a part of their Web Fundamentals site.
  • Mozilla wrote a fantastic cartoon introduction to WebAssembly, explaining the basics behind this new technology; there’s tons of other invaluable content on Mozilla Hacks.
  • The Chromium Chronicle is a monthly series geared specifically to the Chromium developers who build the browser.
  • Web Developers should check out Web.Dev, a great source of articles on building fast and secure websites.

Books

If you prefer to learn from books, I can only recommend a few. Sadly, there are few on browsers themselves (largely because they tend to evolve too quickly), but there are good books on web technologies.

Tools

One of the best ways to examine what’s going on with browsers is to just use tools to watch what’s going on as you use your favorite websites.

Update: I’ve written a whole post on Browser-Debugging Tools.

Use the Source, Leia

The fact that all of the major browsers are built atop open-source projects is a wonderful thing. No longer do you need to be a reverse-engineering ninja with a low-level debugger to figure out how things are meant to work (although sometimes such approaches can still be super-valuable).

Source code locations:

Navigating the Code

While simply perusing a browser’s source code might give you a good feel for the project, browsers tend to be enormous. Chromium is over 10 million lines of code, for example.

If you need to find something in particular, one often effective way to find it easily is to search for a string shown in the browser UI near the feature of interest. (Or, if you’re searching for a DOM function name or HTML attribute name, try searching for that.) We might call this method string chasing.

By way of example, today I encountered an unexpected behavior in the handling of the “Go to <url>” command on Chromium’s context menu:

So, to find the code that implements this feature, I first try searching for that string:

…but there are a gazillion hits, which makes it hard to find what I need. So I instead search for a string that’s elsewhere in the context menu, and find only one hit in the Chromium “grd” (resources) file:

When I go look at that grd file, I quickly find the identifier I’m really looking for just below my search result:

So, we now know that we’re looking for usages of IDS_CONTENT_CONTEXT_GOTOURL, probably in a .CC file, and we find that almost immediately:

From here, we see that the menu item has the command identifier IDC_CONTENT_CONTEXT_GOTOURL, which we can then continue to chase down through the source until we find the code that handles the command. That command makes use of a variable selection_navigation_url_, which is filled elsewhere by some pretty complicated logic.

After you gain experience in the Chromium code, you might learn “Oh, yeah, all of the context menu stuff is easy to find, it’s in the renderer_context_menu directory” and limit your searches to that area, but after four years of working on Chrome, I still usually start my searches broadly.

Optional: Compile the code

If you’d actually like to compile the code of a major browser, things are a bit more involved, but if you follow the configuration instructions to the letter— your first build will succeed. Back in 2015, Monica Dinculescu created an amazing illustrated guide for contributing to Chromium, and in 2020, Marcos Cáceres wrote a thorough explainer about building a feature in Firefox. In 2021, the WebKit team released a guide for contributing to WebKit.

You can compile Chromium or Firefox on a mid-range machine from 2016, but it will take quite a long time. A beefy PC will speed things up a bunch, but until we have cloud compilers available to the public, it’s always going to be pretty slow. Update October 2020: Note that there’s now a simple way to make simple changes to Chromium using just your web browser.

This guide on compiling WebKit suggests that a web platform-only build on a MacBook takes only about 20 minutes; you can run the resulting platform in a minibrowser or instruct Safari to use it.

Look at their Bugs

All browsers except Microsoft Edge have a public bug tracker where you can search for known issues and file new bugs if you encounter them.

  • FirefoxFirefox Bugzilla
  • WebKitWebKit Bugzilla
  • ChromiumCRBug
  • Microsoft Edge‘s – Platform bugs that are inherited from Chromium are tracked using CRBug. Sadly, at present there is no public tracker for bugs that reproduce only in Edge. Bugs reported by the “Feedback” button are tracked internally by Microsoft.
  • Braveon GitHub
  • HTML5 Specification – on GitHub

Here are instructions for filing a great browser bug.

Binge on Online Video

The Chrome team has an excellent set of educational content used to train new and long-time Chrome engineers. Titled Chrome University, it is periodically updated. Here’s the Chrome Security 101 course, for instance.

Blogs to Read

  • This One – I write mostly about browsers.
  • My (archived) IEInternals – I started writing this blog because it was the only reliable way for me to find my notes from investigations and troubleshooting years later.
  • Cloudflare’s – Cloudflare is a $5B company whose primary product is their amazing blog. I understand they also run a CDN on the side to generate interesting topics for their blog to talk about.
  • Nasko Oskov’s – Nasko is an engineer on the Chrome Security team and writes mostly about security topics.
  • Chris Palmer’s – Chris is an engineer on the Chrome Security team and writes about secure design.
  • Adam Langley’s – Google’s expert cryptographer
  • Bruce Dawson’s – Bruce is a Chrome Engineer who posts lots of interesting information about debugging and performance troubleshooting, especially on Windows.
  • Anne van Kesteren’s – Anne works on the HTML5 spec.
  • Mark Nottingham’s – Mark co-chairs the HTTP and QUIC working groups

Specific Posts of Interest

People to Follow

I’ve doubtless forgotten some, see who I follow.

The Business of Browsers

Public data reveals each point of marketshare in the browser market is worth at least $100,000,000 USD annually, most directly in the form of payments from the browser’s configured search engine. (Apple reportedly gets $9-$12Billion a year for sending search traffic to Google, and Mozilla has yielded ~$400M/year from the same sort of deal.)

Remembering this fact will help you understand many other things, from how browsers pay their large teams of expensive software engineers, to how they manage to give browsers away for free, to why certain features behave the way that they do.

Extra Resources

Browsers are hugely complicated beasts, and tons of fun. If the resources above leave you feeling both overwhelmed and excited, maybe you should become a browser builder.

Want to change the world? Come join the new Microsoft Edge team today!

-Eric

App-to-Web Communication: Launching Web Apps

In recent posts, I’ve explored mechanisms to communicate from web content to local (native) apps, and I explained how web apps can use the HTML5 registerProtocolHandler API to allow launching them from either local apps or other websites.

In today’s post, we’ll explore how local apps can launch web apps in the browser.

It’s Simple…

In most cases, it’s trivial for an app to launch a web app and send data to it. The app simply invokes the operating system’s “launch” API and passes it the desired URL for the web app.

Any data to be communicated to the web app is passed in the URL query string or the fragment component of the URL.

On Windows, such an invocation might look like this:

ShellExecute(hwnd, "open", "https://bayden.com/echo.aspx?DataTo=Pass#GoesHere", 0, 0, SW_SHOW);

Calling this API results in the user’s default browser being opened and a new tab navigated to the target URL.

This same simple approach works great on most operating systems and with virtually any browser a user might have configured as their default.

…Unless It’s Not

Unfortunately, this well-lit path adjoins a complexity cliff— if your scenario has requirements beyond the basic [Launch the default browser to this URL], things get much more challenging. The problem is that there is no API contract that provides a richer feature set and works across different browsers.

For instance, consider the case where you’d like your app to direct the browser to POST a form to a target server. Today, popular operating systems have no such concept– they know how to open a browser by passing it a URL, but they expose no API that says “Open the User’s browser to the following URL, sending the navigation request via the HTTP POST method and containing the following POST body data.

Over the years, a few workarounds have been used (e.g. see StackOverflow1 and StackOverflow2).

For instance, if the target webservice simply requires a HTTP POST and you cannot change it, your app could launch the browser to a webpage you control, passing the required data in the querystring component of a HTTP GET. Your web server could then reformat the data into the required POST body format and either proxy that request (server-side) to the target webservice, or it could return a web page with an auto-submitting form element with a method of POST and and action attribute pointed at the target webservice. The user’s browser will submit the form, posting the data to the target server.

Similarly, a more common approach involves having the app write a local HTML file in a temporary folder, then direct the Operating System to open that file using the appropriate API (again ShellExecute, in the case of Windows). Presuming that the user’s default HTML handler is also their default HTTPS protocol handler, opening the file will result in the default browser opening, and the HTML/script in the file will automatically submit the included form element to the target server. This “bounce through a local temporary form” approach has the advantage of making it possible to submit sizable of data to the server (e.g. the contents of a local file), unlike using a GET request’s size-limited querystring.

Caveats:

  • Unfortunately it is generally not possible to construct a HTML form that will submit a data field that exactly matches what you would get when sending an <input type=file> control. If the web service demands a format that was generated by a file upload control, you may not be able to emulate that.
  • Some browsers will not run JavaScript in local files by default.
  • Don’t forget to delete the temporary file!

If your scenario requires uploading files, an alternative approach is to:

  1. Upload the files directly from your app to a web service
  2. Have that web service return a secret token associated with the upload
  3. Have your app spawn a browser with a GET request whose querystring contains that secret token

Browser-Specific Approaches

Back in the Windows 7 days, the IE8 team created a very cool feature called Accelerators that would allow users to invoke web services in their browser from any other application. Interestingly, the API contract supported web services that required POST requests.

Because there was no API in Windows that supported launching the default browser with anything other than a URL, a different approach was needed. A browser that wished to participate as a handler for accelerators could implement a IOpenServiceActivityOutputContext::Navigate function which was expected to launch the browser and pass the data. The example implementation provided by our documentation called into Internet Explorer’s Navigate2() COM API, which accepted as a parameter the POST body to be sent in the navigation. As far as I know, no other browser ever implemented IOpenServiceActivityOutputContext.

These days, Accelerators are long dead, and no one should be using Internet Explorer anymore. In the intervening years, no browser-agnostic mechanism to transfer a POST request from an app to a browser has been created.

Perhaps the closest we’ve come is the W3C’s WebDriver Standard, designed for automated testing of websites across arbitrary browsers. Unfortunately, at present, there’s still no way for mainstream apps to take a dependency on WebDriver to deliver a reliable browser-agnostic solution enabling rich transfers from a local app to a web app. Similarly, Puppeteer can be used for some web automation scenarios in Chrome or Edge, and the new Microsoft Playwright enables automated testing in Chromium, WebKit, and Firefox.

Future Possibilities

While the current picture is bleak, the future is a bit brighter. That’s because a major goal of browsers’ investment in Progressive Web Apps is to make them rich enough to take the place of native apps. Today’s native apps have very rich mechanisms for passing data and files to one another and PWAs will need such capabilities in order to achieve their goals.

Perhaps one day, not too far in the future, your OS and your browser (regardless of vendor) will better interoperate.

-Eric

Microsoft’s Three Browsers

It’s an interesting time. Microsoft now maintains three different web browsers:

  • Internet Explorer 11
  • Microsoft Edge Legacy (Spartan, v18 and below)
  • Chromium-based Microsoft Edge (v79+)

If you’re using Internet Explorer 11, you should stop; sometimes, this is easier said than done.

If you’re using Legacy Microsoft Edge, you should upgrade to the new Microsoft Edge which is better in almost every way. When you install the Stable version of the new Microsoft Edge (either by downloading it or eventually by using WindowsUpdate), it will replace your existing Legacy Edge with the new version.

Update: Microsoft has announced that Edge Legacy will fall out of support on March 9th, 2021.

What if I still need to test in Edge Legacy?

If you’re a web developer and need to keep testing your sites and services in the legacy Microsoft Edge, you’ll need to set a registry key to prevent the Edge installer from removing the entry points to the old Edge.

Simply import this registry script before the new Edge is installed. When the AllowSxS key is set to 1, the new Edge installer will keep the old entry point, renaming it to “Microsoft Edge Legacy”:

Thereafter, you can use both versions of Edge on the same PC.

If you didn’t have this registry key set and your legacy Edge entry points have disappeared when you installed the new Edge, you can use the Add or Remove Programs applet in the system control panel to uninstall the new Edge, then set the registry key, then reinstall the new Edge.

Note: If you’re a Web Developer, you should also be testing in the Edge Beta or Edge Dev builds because these will allow you to see the changes coming to Edge before your users do. These builds install side-by-side (replacing no browser) and can be installed from https://MicrosoftEdgeInsider.com.

What if my company has sites that only work in Internet Explorer?

In order to help speed migration to the new Microsoft Edge, it offers an Internet Explorer Mode feature when running on Windows. IE Mode allows IT administrators to configure PCs running Windows 7, 8.1, and 10 such that specified sites will load inside a browser tab that uses the Internet Explorer 11 rendering engine.

  • IE Mode is not designed for or available to consumers.
  • Because IE Mode relies upon the IE11 binaries on the current machine, it is not available in Edge for MacOS, iOS, or Android.
  • IE Mode tabs run inside the legacy security sandbox (weaker than the regular Edge sandbox) and ActiveX controls like Silverlight are available to web pages.
  • IE Mode does not share a cache, cookies, or web storage with Microsoft Edge, so scenarios that depend upon using these storage mechanisms in a cross-site+cross-engine context will not work correctly. IT administrators should carefully set their policies such that user flows occur within a single engine.
  • Most Edge browser extensions will not work on IE Mode tabs–extensions which only look at the tab’s URL should work, but extensions which try to view or modify the page content will not function correctly.

In an ideal world, users will migrate to the latest version of Microsoft Edge as quickly as possible, and enjoy a faster, more compatible, more reliable browser. Nevertheless, Microsoft will continue to patch both Legacy Edge and Internet Explorer 11 according to their existing support lifecycle.

-Eric

My New Chromium Build PC

While I do most of my work in an office, from time to time I work on code changes to Chromium at home. With the recent deprecation of Jumbo Builds, building the browser on my cheap 2016-era Dell XPS 8900 (i7-6700K) went from unpleasant to impractical. While I pondered buying a high-end Threadripper, I couldn’t justify the high cost, especially given the limited performance characteristics for low-thread workloads (basically, everything other than compilation).

The introduction of the moderately-priced (nominally $750), 16 Core Ryzen 3950X hit the sweet spot, so I plunked down my credit card and got a new machine from a system builder. Disappointingly, it took almost two months to arrive in a working state, but things seem to be good now.

The AMD Ryzen 3950X has 16 cores with two threads each, and runs around 3.95ghz when they’re all fully-loaded; it’s cooled by a CyberPowerPC DeepCool Castle 360EX liquid cooler. An Intel Optane 905P 480GB system drive holds the OS, compilers, and Chromium code. The key advantage of the Optane over more affordable SSDs is that it has a much higher random read rate (~400% as fast as the Samsung 970 Pro I originally planned to use):

Following the Chromium build instructions, I configured my environment and set up a 32bit component build with reduced symbols:

is_component_build = true
enable_nacl = false
target_cpu = "x86"
blink_symbol_level = 0
symbol_level = 1

Atop Windows 10 1909, I disabled Windows Defender entirely, and didn’t do anything too taxing with the PC while the build was underway.

Ultimately, a clean build of the “chrome” target took just under 53 minutes, achieving 33.3x parallelism.

While this isn’t a fast result by any stretch of the definition, it’s still faster than my non-jumbo local build times back when I worked at Google in 2016/2017 and used a $6000 Xeon 48 thread workstation to build Chrome, at somewhere around half of the cost.

Cloud Compilation

When I first joined Google, I learned about the seemingly magical engineering systems available to Googlers, quickly followed by the crushing revelation that most of those magic tools were not available to those of us working on the Chromium open-source project.

The one significant exception was that Google Chrome engineers had access to a distributed build system called “Goma” which would allow compiling Chrome using servers in the Google cloud. My queries around the team suggested that only a minority of engineers took advantage of it, partly because (at the time) it didn’t generate very debuggable Windows builds. Nevertheless, I eventually gave it a shot and found that it cut perhaps five minutes off my forty-five minute jumbo build times on my Xeon workstation. I rationalized this by concluding that the build must not be very parallelizable, and the fact that I worked remotely from Austin, so any build-artifacts from the Goma cloud would be much further away than from my colleagues in Mountain View.

Given the complexity of the configuration, I stopped using Goma, and spent perhaps half of my tenure on Chrome with forty-five minute build times[1]. Then, one day I needed to do some development on my Macbook, and I figured its puny specs would benefit from Goma in a way my Xeon workstation never would. So I went back to read the Goma documentation and found a different reference than I saw originally. This one mentioned a then unknown to me “-j” command line argument that tells the build system how many cloud cores to use.

This new, better, documentation noted that by default the build system would just match your local core count, but when using Goma you should instead demand ~20x your local core count– so -j 960 for my workstation. With one command line argument, my typical compiles dropped from 45 minutes to around 6.

::suitable_meme_of_wonder_and_fury::

Returning to Edge

I returned to Microsoft as a Program Manager on the Edge team in mid-2018, unaware that replatforming atop Chromium was even a possibility until the day before I started. Just before I began, a lead sent me a 27 page PDF file containing the Edge-on-Chromium proposal. “What do you think?” he asked. I had a lot of thoughts (most of the form “OMG, yes!“) but one thing I told everyone who would listen is that we would never be able to keep up without having a cloud-compilation system akin to Goma. The Google team had recently open-sourced the Goma client, but hadn’t yet open-sourced the cloud server component. I figured the Edge team had engineering years worth of work ahead of us to replicate that piece.

When an engineer on the team announced two weeks later that he had “MSGoma” building Chromium using an Azure cloud backend, it was the first strong sign that this crazy bet could actually pay off.

And pay off it has. While I still build locally from time to time, I typically build Chromium using MSGoma from my late 2018 Lenovo X1 Extreme laptop, with build times hovering just over ten minutes. Cloud compilation is a game changer.

The Chrome team has since released a Goma Server implementation, and several other major Chromium contributors are using distributed build systems of their own design.

I haven’t yet tried using MSGoma from my new Ryzen workstation, but I’ve been told that the Optane drive is especially helpful when performing distributed builds, due to the high incidence of small random reads.

-Eric

[1] This experience recalled a much earlier one: my family moving to Michigan shortly after I turned 11. Our new house featured a huge yard. My dad bought a self-propelled lawn mower and my brother and I took turns mowing the yard weekly. The self-propelled mower was perhaps fifteen pounds heavier than our last mower, and the self-propelling system didn’t really seem to do much of anything.

After two years of weekly mows from my brother and I, my dad took a turn mowing. He pushed the lawn mower perhaps five feet before he said “That isn’t right,” reached under the control panel and flipped a switch. My brother and I watched in amazement and dismay as the mower began pulling him across the yard.

Moral of the story: Knowledge is power.

Security Zones in Edge

Browsers As Decision Makers

As a part of every page load, browsers have to make dozens, hundreds, or even thousands of decisions — should a particular API be available? Should a resource load be permitted? Should script be allowed to run? Should video be allowed to start playing automatically? Should cookies or credentials be sent on network requests? The list is long.

In many cases, decisions are governed by two inputs: a user setting, and the URL of the page for which the decision is being made.

In the old Internet Explorer web platform, each of these decisions was called an URLAction, and the ProcessUrlAction(url, action,…) API allowed the browser or another web client to query its security manager for guidance on how to behave.

To simplify the configuration for the user or their administrator, the legacy platform classified sites into five1 different Security Zones:

  • Local Machine
  • Local Intranet
  • Trusted
  • Internet
  • Restricted

Users could use the Internet Control Panel to assign specific sites to Zones and to configure the permission results for each zone. When making a decision, the browser would first map the execution context (site) to a Zone, then consult the setting for that URLAction for that Zone to decide what to do.

Reasonable defaults like “Automatically satisfy authentication challenges from my Intranet” meant that most users never needed to change any settings away from their defaults.

INETCPL Configuration

In corporate or other managed environments, administrators can use Group Policy to assign specific sites to Zones (via “Site to Zone Assignment List” policy) and specify the settings for URLActions on a per-zone basis. This allowed Microsoft IT, for instance, to configure the browser with rules like “Treat https://mail.microsoft.com as a part of my Intranet and allow popups and file downloads without warning messages.

Beyond manual administrative or user assignment of sites to Zones, the platform used additional heuristics that could assign sites to the Local Intranet Zone. In particular, the browser would assign dotless hostnames (e.g. https://payroll) to the Intranet Zone, and if a Proxy Configuration script was used, any sites configured to bypass the proxy would be mapped to the Intranet Zone.

Applications hosting Web Browser Controls, by default, inherit the Windows Zone configuration settings, meaning that changes made for Internet Explorer are inherited by other applications. In relatively rare cases, the host application might supply its own Security Manager and override URL Policy decisions for embedded Web Browser Control instances.

The Trouble with Zones

While powerful and convenient, Zones are simultaneously problematic bug farms:

  • Users might find that their mission critical corporate sites stopped working if their computer’s Group Policy configuration was outdated.
  • Users might manually set configuration options to unsafe values without realizing it.
  • Attempts to automatically provide isolation of cookies and other data by Zone led to unexpected behavior, especially for federated authentication scenarios.

Zone-mapping heuristics are extra problematic

  • A Web Developer working on a site locally might find that it worked fine (Intranet Zone), but failed spectacularly for their users when deployed to production (Internet Zone).
  • Users were often completely flummoxed to find that the same page on a single server behaved very differently depending on how they referred to it — e.g. http://localhost/ (Intranet Zone) vs. http://127.0.0.1/ (Internet Zone).

The fact that proxy configuration scripts can push sites into the Intranet zone proves especially challenging, because:

  • A synchronous API call might need to know what Zone a caller is in, but determining that could, in the worst case, take tens of seconds — the time needed to discover the location of the proxy configuration script, download it, and run the FindProxyForUrl() function within it. This could lead to a hang and unresponsive UI.
  • A site’s Zone can change at runtime without restarting the browser (say, when moving a laptop between home and work networks, or when connecting or disconnecting from a VPN).
  • An IT Department might not realize the implications of returning DIRECT from a proxy configuration script and accidentally map the entire untrusted web into the highly-privileged Intranet Zone. (Microsoft IT accidentally did this circa 2011).
  • Some features like AppContainer Network Isolation are based on firewall configuration and have no inherent relationship to the browser’s Zone settings.

Legacy Edge

The legacy Edge browser (aka Spartan, Edge 18 and below) inherited the Zone architecture from its Internet Explorer predecessor with a few simplifying changes:

  • Windows’ five built-in Zones were collapsed to three: Internet (Internet), the Trusted Zone (Intranet+Trusted), and the Local Computer Zone. The Restricted Zone was removed.
  • Zone to URLAction mappings were hardcoded into the browser, ignoring group policies and settings in the Internet Control Panel.

Use of Zones in Chromium

Chromium goes further and favors making decisions based on explicitly-configured site lists and/or command-line arguments.

Nevertheless, in the interest of expediency, Chromium today uses Windows’ Security Zones by default in two places:

  1. When deciding how to handle File Downloads, and
  2. When deciding whether or not to release Windows Integrated Authentication (Kerberos/NTLM) credentials automatically.

For the first one, if you’ve configured the setting Launching applications and unsafe files to Disable in your Internet Control Panel’s Security tab, Chromium will block file downloads with a note: “Couldn’t download – Blocked.”

For the second, Chromium will process URLACTION_CREDENTIALS_USE to decide whether Windows Integrated Authentication is used automatically, or the user should instead see a manual authentication prompt. (Aside: the manual authentication prompt is really a bit of a mistake– the browser should instead just show a prompt: “Would you like to [Send Credentials] or [Stay Anonymous]” dialog box, rather than forcing the user to reenter the credentials that Windows already has.

Even Limited Use is Controversial

Respect for Zones2 in Chromium remains controversial—the Chrome team has launched and abandoned plans to remove them a few times, but ultimately given up under the weight of enterprise compat concerns. Their arguments for complete removal include:

  1. Zones are poorly documented, and Windows Zone behavior is poorly understood.
  2. The performance/deadlock risks mentioned earlier (Intranet Zone mappings can come from a system-discovered proxy script).
  3. Zones are Windows-only (meaning they prevent drop-in replacement of ChromeOS).

Note: By configuring an explicit site list policy for Windows Authentication, an administrator disables the browser’s URLACTION_CREDENTIALS_USE check, so Zones Policy is not consulted. A similar option is not presently available for Downloads.

Zones in the New Edge

Beyond the two usages of Zones inherited from upstream, the new Chromium-based Edge browser (v79+) adds one more:

  1. Administrators can configure Internet Explorer Mode to open all Intranet sites in IEMode. Those IEMode tabs are really running Internet Explorer, and they use Zones for everything that IE did.

Update: This is very much a corner case, but I’ll mention it anyway. On downlevel operating systems (Windows 7/8/8.1), logging into the browser for sync makes use of a Windows dialog box that contains a Web Browser Control (based on MSHTML) that loads the login page. If you adjust your Windows Security Zones settings to block JavaScript from running in the Internet Zone, you will find that you’re unable to log into the new browser. Oops.

Downsides/Limitations

While it’s somewhat liberating that we’ve moved away from the bug farm of Security Zones, it also gives us one less tool to make things convenient or compatible for our users and IT admins.

We’ve already heard from some customers that they’d like to have a different security and privacy posture for sites on their Intranet, with behavior like:

  • Disable the Tracking Prevention, “Block 3rd party cookie”, and other privacy-related controls for the Intranet (like IE/Edge did).
  • Allow navigation to file:// URIs from the Intranet (like IE/Edge did)
  • Disable “HTTP and mixed content are unsafe” and “TLS/1.0 and TLS/1.1 are deprecated” nags.
  • Skip SmartScreen checks for the Intranet.
  • Allow ClickOnce/DirectInvoke/Auto-opening Downloads from the Intranet without a prompt. Previously, Edge (Spartan)/IE respected the FTA_OpenIsSafe bit in the EditFlags for the application.manifest progid if-and-only-if the download source was in the Intranet/Trusted Sites Zone.
  • Allow launching application protocols from the Intranet without a prompt.
  • Drop all Referers when navigating from the Intranet to the Internet; leave Referers alone when browsing the Intranet.
  • Internet Explorer and legacy Edge will automatically send your client certificate to Intranet sites that ask for it. The AutoSelectCertificateForUrls policy permits Edge to send a client certificate to specified sites without a prompt, but this policy requires the administrator to manually list the sites.
  • Block all (or most) extensions from touching Intranet pages to reduce the threat of data leaks.
  • Guide all Intranet navigations into an appropriate profile or container (a la Detangle).
  • Upstream, there’s a longstanding desire to help protect intranets/local machine from cross-site-request-forgery attacks; blocking loads and navigations of private resources from the Internet Zone is somewhat simpler than blocking them from Intranet Sites.

At present, only AutoSelectCertificateForUrls, manual cookie controls, and mixed content nags support policy-pushed site lists, but their list syntax doesn’t have any concept of “Intranet” (dotless hosts, hosts that bypass proxy).

You’ll notice that each of these has potential security impact (e.g. an XSS on a privileged “Intranet” page becomes more dangerous; unqualified hostnames can result in name collisions), but having the ability to scope some features to only “Intranet” sites might also improve security by reducing attack surface.

As browser designers, we must weigh the enterprise impact of every change we make, and being able to say “This won’t apply to your intranet if you don’t want it to” would be very liberating. Unfortunately, building such an escape hatch is also the recipe for accumulating technical debt and permitting the corporate intranets to “rust” to the point that they barely resemble the modern public web.

Best Practices

Throughout Chromium, many features are designed respect an individual policy-pushed list of sites to control their behavior. If you were forward-thinking enough to structure your intranet such that your hostnames are of the form:

Congratulations, you’ve lucked into a best practice. You can configure each desired policy with a *.contoso-intranet.com entry and your entire Intranet will be opted in.

Unfortunately, while wildcards are supported, there’s presently no way (as far as I can tell) to express the concept of “any dotless hostname.”

Why is that unfortunate? For over twenty years, Internet Explorer and legacy Edge mapped domain names like https://payroll, https://timecard, and https://sharepoint/ to the Intranet Zone by default. As a result, many smaller companies have benefitted from this simple heuristic that requires no configuration changes by the user or the IT department.

Opportunity: Maybe such a DOTLESS_HOSTS token should exist in the Chromium policy syntax. TODO: figure out if this is worth doing.

Summary

  • Internet Explorer and Legacy Edge use a system of five Zones and 88+ URLActions to make security decisions for web content, based on the host of a target site.
  • Chromium (New Edge, Chrome) uses a system of Site Lists and permission checks to make security decisions for web content, based on the host of a target site.

There does not exist an exact mapping between these two systems, which exist for similar reasons but implemented using very different mechanisms.

In general, users should expect to be able to use the new Edge without configuring anything; many of the URLActions that were exposed by IE/Spartan have no logical equivalent in modern browsers.

If the new Edge browser does not behave in the desired way for some customer scenario, then we must examine the details of what isn’t working as desired to determine whether there exists a setting (e.g. a Group Policy-pushed SiteList) that provides the desired experience.

-Eric

1 Technically, it was possible for an administrator to create “Custom Security Zones” (with increasing ZoneIds starting at #5), but such a configuration has not been officially supported for at least fifteen years, and it’s been a periodic source of never-to-be-fixed bugs.

2 Beyond those explicit uses of Windows’ Zone Manager, various components in Chromium have special handling for localhost/loopback addresses, and some have special recognition of RFC1918 private IP Address ranges (e.g. SafeBrowsing handling) and Network Quality Estimation.

Within Edge, the EMIE List is another mechanism by which sites’ hostnames may result in different handling.

Retiring Internet Explorer

Prelude

In late 2004, I was the Program Manager for Microsoft’s clipart website, delivering a million pieces of clipart to Microsoft Office customers every day. It was great fun. But there was a problem– our “Clip of the Day” feature, meant to spotlight a new and topical piece of clipart every day, wasn’t changing as expected.

After much investigation (could the browser itself really be wrong?!?), I wrote to the IE team to complain about what looked like bugs in its caching implementation. In a terse reply, I was informed that the handful of people then left on the browser team were only working on critical security fixes, and my caching problems weren’t nearly important enough to even look at.

That night, unable to sleep, I tossed and turned and fumed at the seeming arrogance of the job link in the respondent’s email signature… “Want to change the world? Join the new IE team today!

Gradually, though, I calmed down and reasoned it through… While the product wasn’t exactly beloved, everyone I knew with a computer used Internet Explorer. Arrogant or not, it was probably accurate that there was nothing I could do with my career at that time that would have as big an impact as joining the IE team. And, I smugly realized that if I joined the team, I’d get access to the IE source code, and could go root out those caching bugs myself.

I reached out to the IE lead for an informational interview the following day, and passed an interview loop shortly thereafter.

After joining the team, I printed out the source code for the network stack and sat down with a red pen. There were no fewer than six different bugs causing my “Clip of the Day gets stuck” issue. When my devs fixed the last of them, I mentioned this and my story to my GPM (boss’ boss).

Does this mean you’re a retention risk?” Tony asked.

Maybe after we fix the rest of these…” I retorted, pointing at the pile of paper with almost a hundred red circles.

No one in the world loved IE as much as I did, warts and all. Investigating, documenting, and fixing problems in Internet Explorer was a nearly all-consuming passion throughout my twenties. Internet Explorer pioneered a broad range of (mostly overlooked) innovations, and in rediscovering them, I felt like one of the characters on Lost — a castaway in a codebase whose brilliant designers were long gone. IE9 was a fantastic, best-of-its-time browser, and I’ll forever be proud of it. But as IE9 wound down and the Windows 8 adventure began, it was already clear that its lead would not last against the Chrome juggernaut.

I shipped IE7, IE8, IE9, and IE10, leaving Microsoft in late 2012, shortly after IE10 was finished, to build Fiddler for Telerik.

In 2015, I changed my default browser to Chrome. In 2016, I joined the Chrome Security team. I left Google in the summer of 2018 and rejoined the Microsoft Edge team, and that summer and fall I spent 50% of my time rediscovering bugs that I’d first found in IE and blogged about a decade before.

Fortunately, Edge’s faster development pace meant that we actually got to fix some of the bugs this time, but Chrome’s advantages in nearly every dimension left Edge very much in an underdog status. Fortunately, the other half of my time was spent working on our (then) secret project to replatform the next version of our Edge browser atop the open-source Chromium project.

We’ve now shipped our best browser ever — the Chromium-based Microsoft Edge. I hope you’ll try it out.

It’s with love that I beg you… please let Internet Explorer retire to the great bitbucket in the sky. It’s time. It’s been time for a long time.

Burndown List

Last night, as I read the details of yet another 0-day security bug in Internet Explorer, I posted the following throwaway tweet, which netted a surprising number of interactions:

I expected the usual slew of “Yeah, IE is terrible,” and “IE was always terrible,” and “Somebody tell my {boss,school,parents}” responses, but I didn’t really expect serious replies. I got some, however, and they’re interesting.

Shared Credentials

https://twitter.com/c0ld_fire/status/1219038213081378816

Internet Explorer shares a common networking stack (WinINET) and Cookie Jar (for Intranet/Trusted sites) with many native code applications on Windows, including Windows Explorer. Tim identifies a scenario where Windows Explorer relies on an auth cookie being found in the WinINET cookie jar, put there by Internet Explorer. We’ve seen similar scenarios in some Microsoft Office flows.

Depending on a cookie set by Internet Explorer might’ve been somewhat reasonable in 2003, but Vista/IE7’s introduction of Protected Mode (and cookie jar partitioning) in 2006 made this a fragile architecture. The fact that anything depends upon it in 2020 is appalling.

Thoughts: I need to bang on some doors. This is depressing.

Certificate Issuance

Developers who apply digital signatures to their apps and server operators who expose their sites over HTTPS do so using a digital certificate. In ideal cases, getting a certificate is automatic and doesn’t involve a browser at all, but some Certificate Authorities require browser-based flows. Those flows often demand that the user use either Internet Explorer or Firefox because the former supports ActiveX Controls for certificate issuance, while Firefox, until recently, supported the Keygen element.

WebCrypto, now supported in all modern browsers, serves as a modern replacement for these deprecated approaches, and some certificate issuers are starting to build issuance flows atop it.

Thoughts: We all need to send some angry emails. Companies in the Trust space should not be built atop insecure technologies.

Banking, especially in Asia

A fascinating set of circumstances led to Internet Explorer’s dominance in Asian markets. First, early browsers had poor support for Unicode and East Asian character sets, forcing website developers to build their own text rendering atop native code plugins (ActiveX). South Korea mandated use of a locally-developed cipher (SEED) for banking transactions[1], and this cipher was not implemented by browser developers… ActiveX again to the rescue. Finally, since all users were using IE, and were accustomed to installing ActiveX controls, malware started running rampant, so banks and other financial institutions started bundling “security solutions” (aka rootkits) into their ActiveX controls. Every user’s browser was a battlefield with warring native code trying to get the upper hand. A series of beleaguered Microsoft engineers (including Ed Praitis, who helped inspire me to make my first significant code commits to the browser) spent long weeks trying to keep all of this mess working as we rearchitected the browser, built Protected Mode and later Enhanced Protected Mode, and otherwise modernized a codebase nearing its second decade.

Thoughts: IE marketshare in Asia may be higher than other places, but it can’t be nearly as high as it once was. Haven’t these sites all pivoted to mobile apps yet?

Reader Survey: Do you have any especially interesting scenarios where you’re forced to use Internet Explorer? Sound off in the comments below!

Q&A

Q: I get that IE is terrible, but I’m an enterprise admin and I own 400 websites running lousy websites written by a vendor in a hurry back in 2004. These sites will not be updated, and my employees need to keep using them. What can I do?

A: The new Chromium-based Edge has an IE Mode; you can configure your users so that Edge will use an Internet Explorer tab when loading those sites, directly within Edge itself. Consumers with unmanaged PCs can enable IEMode while users on Enterprise-managed PCs must have an IE Mode site list configured (or set two debug policies).

As of March 2021, Windows Group Policy is now available to prevent the use of Internet Explorer, allowing access only via Edge IE Mode.

Q: Uh, isn’t IE Mode a security risk?

A: Any use of an ancient web engine poses some risk, but IE Mode dramatically reduces the risk, by ensuring that only sites selected by the IT Administrator load in IE mode. Everything else seamlessly transitions back to the modern, performant and secure Chromium Edge engine.

Q: How do I debug? The Chromium F12 Developer Tools don’t work for IE Mode tabs?

A: Yes. You can either debug in full IE, or run C:\windows\system32\f12\IEChooser.exe, select the tab running in IEMode, and get an IE F12 Dev Tools window for that tab. This tool also works for WebOCs!

Q: What about Web Browser Controls (WebOCs) inside my native code applications?

A: In many cases, WebOCs inside a native application are used to render trusted content delivered from the application itself, or from a server controlled by the application’s vendor. In such cases, and presuming that all content is loaded over HTTPS, the security risk of the use of a WebOC is significantly lower. Rendering untrusted HTML in a WebOC is strongly discouraged, as WebOCs are even less secure than Internet Explorer itself. For compatibility reasons, numerous security features are disabled-by-default in WebOCs, and the WebOC does not run content in any type of process sandbox.

Looking forward, the new Chromium-based WebView2 control should be preferred over WebOCs for scenarios that require the rendering of HTML content within an application.

Q: Does this post mean anything has changed with regard to Internet Explorer’s support lifecycle, etc?

A: No. Internet Explorer will remain a supported product until its support lifecycle runs out. I’m simply begging you to not use it except to download a better browser.

Footnotes

[1] The SEED cipher wasn’t just a case of the South Korean government suffering from not-invented-here, but instead a response to the fact that the US Government at the time forbid export of strong crypto.