Fewest vulnerabilities: I suspect that Chrome and Firefox being open source is a factor here. Thus it seems possible to me that they actually have fewer vulnerabilities than Edge—Edge’s just haven’t been found yet.
This is pure speculation on my part; I have no evidence nor any investigation, deep or otherwise.
Haven't been introduced and haven't been found. It's both. Microsoft's SDL has dramatically reduced number of 0-days in their products. I speculate that eliminating many common vulnerability classes also eliminates a lot of the low-hanging fruit that's easiest to spot in the binaries by reverse engineers. They have potential to raise the security even higher if they apply MS Research's tools like VCC or Dafny. I don't even know what Edge is written in, though.
You're kind of talking out of your ass here, fyi. They have been introduced and they have been found. Don't underestimate Google's resources on chrome. Especially considering that many Google security folks were previously at MS.
Im not sure what comment you read as I mentioned they both have 0-days and that number of them dropped sharply due to SDL. The numbers available prove both. Even more true given attackers are focusing on common applications more than Windows itself. That's because they're easier to attack than Windows code.
Chrome and Firefox has a much larger userbase than Edge has. (As of now). As Edge matures and its userbase grows we will have a chance to see how it measures up :)
Edge's JS engine (Chakra) has had the majority of itself open sourced (ChakraCore). Given how central the JS engine is to overall browser security, I wonder if that changes your suspicions at least a bit?
Also keep in mind that almost no-one is using edge: 4 till 5% browser market share (depending on the source used for such data). Whereas Chrome has a 25-35% market share (again, depending on source). It's just plain obvious that people don't want to put in a lot of effort to find a vulnerability as their target audience/ ROI is only so little...
"We’re determined to make Microsoft Edge the safest and most secure browser."
Then open source the whole thing, not just little parts of it. It has the lowest number of vulnerabilities in the National Vulnerability Database because it has the least number of eyes able to look for them.
The point isn't that every open source app is awesome, it is that now you KNOW.
You're directing snark towards OpenSSL presumably because you think it's a poorly coded. If it was closed source you might not even be aware of the issues and there certainly wouldn't be the open source efforts to code alternatives.
If it was closed-source, we would assume it had lots of issues until reviewed by a qualified, third party that we trust saying otherwise who also gives us signed hash for binary that was reviewed. The way it's been done in proprietary evaluations a long time. It would be done more if companies were actually interested in a real evaluation instead of a stamp that knocks out their liability. ;)
Under DOD's TCSEC criteria, the high-assurance systems (A1-class) also had to be delivered in source form to paying customers with evaluation evidence. They can check hashes/signatures, check the evaluation evidence themselves, and build it on site. So, vendors got paid large sums of money to develop the products, independent evaluation ensured you got some pentesting, and you could inspect the source yourself. My modification to the scheme involved evaluators with hacking background in mutually-suspicious countries working side-by-side with developers every step of the way.
Traditional open-source development is weak against all of these given there's usually a lack of qualified expertise or just people willing to dig into it. Just open-sourcing something gets people almost nothing in security. Has to be reviewed.
I think the main thing is that Microsoft makes billions from what lock-in remains in their tech. They are probably very afraid that open-source would've made things like OpenOffice happen for all their locked-in tech at great development speed and compatibility. Plus on better platforms that Microsoft doesn't sell. Maybe even ReactOS greatly accelerated by the availability of source. ;)
That's my theory anyway. They share source with some but highly selective with plenty restrictions.
Some of the recent proposed international trade treaties would forbid governments from requiring companies to supply source code for their software, if I recall correctly.
What matters most is the amount of security effort paid to the project, not whether it is open- or closed-source. Commercial decompilers, reverse-engineering tools and automated bug finders have come a long way - a determined reverser can find bugs in closed-source code almost as easily as in open-source code. But, both kinds of bug finding take time and loads of manual effort (despite good tools), and will often only happen with appropriate incentives.
This is where closed-source has a major advantage: companies put up money (in the form of bug bounties) to counteract the bug prices that a researcher could obtain on the black market. This incentivizes "good" researchers to spend time on their products. Open-source projects, even highly-successful ones, rarely have enough funding to run good bug bounty programs. Consequently, good guys can't pay the bills finding bugs in open source, whereas bad guys get huge payoffs for finding and exploiting bugs (think the NSA, criminal groups, malicious states, etc.).
As the adage goes, enough eyeballs render all bugs shallow. But, in this day and age, that applies both to open- and to closed-source code.
He means the quality is so bad that users of it could get owned by full, remote execution on a regular basis. That some people saw some flaws didn't mean anything. There were some alternatives, including commercial, where people put extra effort into checking how crypto interfaced or the quality of the code. Some even used static analysis to find common flaws. As I say, the difference in 0-days between them and OpenSSL is the effort that was put into the quality rather than how open they are.
A closed development with good effort is more trustworthy than an open one with low effort or review. One exception being subversion where open-source can spot most idiotic backdoors. Less likely to catch good, obfuscated ones. From there, an open development with strong effort and review is more trustworthy than a similar, close one. Amount of effort and quality of review are only consistent indicators.
>A closed development with good effort is more trustworthy than an open one with low effort or review.
Good code is better than bad code obviously, but how do you know what you have if you can't see the source? It's Schrodinger's code, you don't know it's bad until it's too late.
Independent review of source with published hash for binary or analysis of assembly to compare it to baseline. Many problems that due diligence avoids can be detected at ASM level. You'd know they were at least doing that.
How do you pay for the audits without a conflict of interest? Unless it is crowdfunded in some way, the auditors would have incentives to not find anything.
In the past, it was done by independent parties that everyone had to go through plus the NSA's IAD. These days just evaluation labs but it's more politics these days. The best way left would be to pick people with known skill and unlikely to lie about quality. Especially where reputation is on the line.
I also can't overemphasize having clear standards to evaluate against. Then, you can have it done in a jurisdiction with strong contract law where they legally have to check it against the evidence. Make sure they publish a statement to the effect of what criteria it met to what degree. Potential to use lawsuits against them.
Open sourcing it really only assuages a very tiny sum of people on this axis, as the vast majority of people simply cannot evaluate the code once they have it. They have to trust someone else, the same as they do for vendors.
OpenSSL is a good example of this, because even seasoned programmers trusted the code on the good name of the project and a few notable personalities. All the while told, "Don't write crypto code. It's too hard, let the experts handle it."
And look where that has gotten us. A million eyes all glazed over the same bug.
I'm unaware of concrete evidence that open sourcing code affects security outcomes either way. Do you have any examples?
>I'm unaware of concrete evidence that open sourcing code affects security outcomes either way. Do you have any examples?
An impossible standard, how do you purpose to measure that?
>And look where that has gotten us. A million eyes all glazed over the same bug.
How is a less eyes a solution to that problem?
Allow me this thought experiment: One person holds up a black box and asks you to stick your hand inside promising up and down that it is not full of venomous snakes, another person does the same with a transparent box. You are blind, but there are some well meaning (though not perfect) people in the room who don't want to see you hurt and they see no snakes in the clear box. What box do you choose?
"An impossible standard, how do you purpose to measure that?"
Number of compromises for product/system X vs open alternatives. Number of published vulnerabilities. Time to patch them. Evaluation of binaries for common issues showing if even basic, due diligence was applied. Results of independent evaluations against meaningful criteria, such as QA methods used & results of them. There's quite a few ways to assess this.
"How is a less eyes a solution to that problem?"
How is no eyes looking at specific OSS a solution to the problem? Pointless questions not focusing on the issue.
"Allow me this thought experiment: One person holds up a black box and asks you to stick your hand "
Now, lets say the same thing happens FOSS-style. The box is clear but people dive in blindfolded without being asked. That's vast majority of FOSS with negligible security benefit. Next, someone looks at the box but has neither seen a snake nor knows which are venomous. This is people glancing at the code. Lets say they know 1 or 2 venomous snakes, ask they be removed, and dive into the others because they didn't know how to spot them. This is amateurs or pro's with little domain knowledge knocking out low-hanging fruit (err, snakes). Finally, let's say an expert on all poisonous snakes puts significant time inspecting the box to make sure no adults or even babies lurk in there. After they're gone, the expert inserts their hand with no damage unless a new type of snake was hidden in there.
I choose the box where an expert looked inside to remove as many dangers as possible. I don't care if it's open or closed for my baseline: just that it was vetted by reliable people with evidence it's the same box. Most proprietary and FOSS software doesn't meet this standard although it was mostly proprietary that reached highest level of proof. Took a lot of expensive experts years to do it is why. FOSS theoretically has an advantage due to free labor but they just don't do high-security. Hard to get them to use safer, systems languages and unit testing much less high-security methods.
So, there's your example. It withers away once the truth is once again demonstrated: it's the review(s), what was reviewed, and if you trust reviewer or review methods. OSS only helps in rare case that more pro's or experts are interested in doing that. It occasionally happens but too rare to be the rule for the baseline.
It's been a little while since I was close to Microsoft (they were a client for a bit at Matasano), but: those people spend more on software security for WINMINE.EXE than a lot of startups do for their whole stack.
Would their software be safer if it was open source? Probably. Open code is rarely a loss for security. But it's not easy to say how much safer. Probably less than you think.
I recall the Windows source leaked a long time ago. One programmer wrote an article on it saying it was actually good code. The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking. My bookmark leads to a missing article that's not in Wayback Machine. Do you have a substitute link to a review by a qualified person who got to look at the source? I'd be interested in that.
>One programmer wrote an article on it saying it was actually good code.
"one programmer" commenting about 30+ million lines of code. Yeah. uh-huh. Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase.
>The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking.
Those are mostly relegated to the compatibility shim layer. You can turn it off, in any case.
"Yes, it leaked during the Win2K release cycle I believe. And you're probably thinking about the kuro5hin website, where someone claimed to have analyzed it. "
Yeah, my inability to evaluate the skill level or character of source was main drawback of claim. I gave a little credence to it because I knew that they were ramping up QA due to image problems and potential lost sales. Steve Lipner... who did high-assurance security with legendary Paul Karger... came in to turn it around with the SDL. Massive investment in professional programmers to find quality issues across the lifecycle implies it would have fewer issues than average software.
""one programmer" commenting about 30+ million lines of code. Yeah. uh-huh."
You can tell a lot by glancing at random samples while digging into a bit fewer. Good, well-commented code with various security checks stands out for people that spend years looking at the opposite. All such a review could say, though, was that people were putting in effort. Actual security would need thorough review.
"Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase."
As someone who spent a lot of time in the past 5 years at MSFT and also at tons of other firms doing security work / SDL-work on code bases; there are very few companies where a giant C/C++ code base is getting even close to the quality of Microsofts.
And indeed; very few companies spent as much money as Microsoft on their entire SDL. Sadly never had the chance to get a look into Google's kitchen but I'm hearing that they're great too.
They're also not dealing with the kind of backwards compatibility that Microsoft is dealing with which helps them out a lot too.
Am I reading correctly: WDAGfME (for lack of a better acronum) is essentially starting a VM with a fresh copy of Windows for every site that it is protecting? Does this happen for every open & protected tab/window? What kind of overhead does it have?
The idea sounds similar to Qubes OS, with the exception that it's transparent to the user and doesn't have to be configured by the end-user.
I presume this kills any of the offline-storage approaches?
The idea of starting new fresh copy of Windows software stack for every site is kinda naive. I would say they are using something similar to Linux kernel namespace mechanism for sandboxing in Windows kernel, which is quite efficient and secure sandboxing without going through the pain of virtualization(Google uses this mechanism for implementing Android subsystem in ChromeOS). But how hyper-v fits to this equation, I don't know.Maybe something similar to docker service in hyper-v.
But anyhow this is quite amazing idea, Microsoft really tries hard to improve Edge.
The reason they can overcome technical difficulty of something this cool is because they have very consistent and very limited underlying platform (they don't have to support macOS, Linux, etc). Imagine how hard it would be for Firefox and chrome to pull off something similar.
>I presume this kills any of the offline-storage approaches?
Not necessarily, it depends on how they did implement this.
I see two options: 1) they're using Hyper-V and exposing a small number of hypercalls to allow for rendering and interaction. 2) they've overloaded the Hyper-V name for a user space sandbox.
I'm really hoping for the former, as it'll mean they finally might expose a KVM-esque API. That would mean a drastic change for virtualization dev on Windows.
Maybe I'm misunderstanding the question, but the article clearly describes that they're using Hyper-V to launch a separate instance of the kernel and the browser in a "container" (which is later "discarded").
My understanding (which could easily be wrong) is that it works similar to Sandboxie. However it looks like it is using the Hyper-V container functionality they recently announced.
So basically when you run this protected Edge session it starts the browser in a Hyper-V container, it has some read access to the host file system, registry, etc. but no write and when the session is closed everything else goes with it.
It's actually a feature that goes way back to the Compartmented Mode Workstations that were sold in Orange Book days for higher security than regular UNIX. The higher-security ones often balanced security and performance by figuring out which components had to be secure and shared vs which they could just duplicate without trust. Epstein et al's TX is an example with many details:
So, high-assurance community has been on this with numerous projects and products released. Many had small, strong TCB's. The oldest had the color schemes and everything. QubesOS is the newcomer with less security than many forerunners but great usability & openness. Better than average Linux distro. Closest to prior designs with active community is genode.org.
The one good thing about this is that they're relying on Hyper-V. It may end up much more secure than solutions like Xen simply because Microsoft is investing in so much verification. That started with Verisoft project where they started using their VCC tool to verify the C-level source against specifications. They later extended the tool for assembly. The first report I saw indicated 20% was verified against its spec. So, it should get more robust overtime.
People interested in Microsoft Research's work on secure browsers should look at Gazelle browser and Xax plugin architecture:
I sense this is the same feature that is used to implement Docker containers. Possibly browser isolation was the primary driver and it got co-opted for the server.
Why is this an enterprise-only feature? Do regular user not deserve the same level of security for their browsers? Will this tech even be available to non-Microsoft apps in the future?
It's not very useful for regular users outside of private browsing - the WDAG windows are unable to persist any state at all since their container is discarded at the end of the browsing session to thwart malware persistence.
It does sound like an interesting capability for private browsing, but existing mechanisms mostly cover that. Even if WDAG applied to private Windows, ordinary users aren't so likely to open private browser windows just to check a link from an email.
I expect that if you had a copy of Win10 Enterprise you could configure the feature yourself for added security in paranoid cases (e.g. journalist covering abusive regimes who might be targeted by state-level malware).
virtualize any software on the fly (e.g. web browser,
office suite, media player) into lightweight VMs called
cappsules. Attacks are confined inside cappsules and
therefore don’t have any impact on the host OS.
Applications don’t need to be repackaged, and their usage
remain the same for the end user: it’s completely
transparent. Moreover, the OS doesn’t need to be
reinstalled nor modified.
Bromium and Microsoft partnered in 2015
.. extends VBS – isolating the execution of targeted
applications such as the browser, documents, executables,
downloads, attachments and media files .. to all
vulnerable applications on all Windows 7, 8 and 10
endpoints
So just to be clear, this is basically another sandbox, which starts a private browsing session implicitly for each site and disables the entire password manager?
58 comments
[ 2.9 ms ] story [ 78.9 ms ] thread(Disclosure: Microsoft is my employer.)
This is pure speculation on my part; I have no evidence nor any investigation, deep or otherwise.
Haven't been introduced and haven't been found. It's both. Microsoft's SDL has dramatically reduced number of 0-days in their products. I speculate that eliminating many common vulnerability classes also eliminates a lot of the low-hanging fruit that's easiest to spot in the binaries by reverse engineers. They have potential to raise the security even higher if they apply MS Research's tools like VCC or Dafny. I don't even know what Edge is written in, though.
Then open source the whole thing, not just little parts of it. It has the lowest number of vulnerabilities in the National Vulnerability Database because it has the least number of eyes able to look for them.
You're directing snark towards OpenSSL presumably because you think it's a poorly coded. If it was closed source you might not even be aware of the issues and there certainly wouldn't be the open source efforts to code alternatives.
Under DOD's TCSEC criteria, the high-assurance systems (A1-class) also had to be delivered in source form to paying customers with evaluation evidence. They can check hashes/signatures, check the evaluation evidence themselves, and build it on site. So, vendors got paid large sums of money to develop the products, independent evaluation ensured you got some pentesting, and you could inspect the source yourself. My modification to the scheme involved evaluators with hacking background in mutually-suspicious countries working side-by-side with developers every step of the way.
Traditional open-source development is weak against all of these given there's usually a lack of qualified expertise or just people willing to dig into it. Just open-sourcing something gets people almost nothing in security. Has to be reviewed.
That's my theory anyway. They share source with some but highly selective with plenty restrictions.
This is where closed-source has a major advantage: companies put up money (in the form of bug bounties) to counteract the bug prices that a researcher could obtain on the black market. This incentivizes "good" researchers to spend time on their products. Open-source projects, even highly-successful ones, rarely have enough funding to run good bug bounty programs. Consequently, good guys can't pay the bills finding bugs in open source, whereas bad guys get huge payoffs for finding and exploiting bugs (think the NSA, criminal groups, malicious states, etc.).
As the adage goes, enough eyeballs render all bugs shallow. But, in this day and age, that applies both to open- and to closed-source code.
A closed development with good effort is more trustworthy than an open one with low effort or review. One exception being subversion where open-source can spot most idiotic backdoors. Less likely to catch good, obfuscated ones. From there, an open development with strong effort and review is more trustworthy than a similar, close one. Amount of effort and quality of review are only consistent indicators.
Good code is better than bad code obviously, but how do you know what you have if you can't see the source? It's Schrodinger's code, you don't know it's bad until it's too late.
I also can't overemphasize having clear standards to evaluate against. Then, you can have it done in a jurisdiction with strong contract law where they legally have to check it against the evidence. Make sure they publish a statement to the effect of what criteria it met to what degree. Potential to use lawsuits against them.
OpenSSL is a good example of this, because even seasoned programmers trusted the code on the good name of the project and a few notable personalities. All the while told, "Don't write crypto code. It's too hard, let the experts handle it."
And look where that has gotten us. A million eyes all glazed over the same bug.
I'm unaware of concrete evidence that open sourcing code affects security outcomes either way. Do you have any examples?
An impossible standard, how do you purpose to measure that?
>And look where that has gotten us. A million eyes all glazed over the same bug.
How is a less eyes a solution to that problem?
Allow me this thought experiment: One person holds up a black box and asks you to stick your hand inside promising up and down that it is not full of venomous snakes, another person does the same with a transparent box. You are blind, but there are some well meaning (though not perfect) people in the room who don't want to see you hurt and they see no snakes in the clear box. What box do you choose?
Number of compromises for product/system X vs open alternatives. Number of published vulnerabilities. Time to patch them. Evaluation of binaries for common issues showing if even basic, due diligence was applied. Results of independent evaluations against meaningful criteria, such as QA methods used & results of them. There's quite a few ways to assess this.
"How is a less eyes a solution to that problem?"
How is no eyes looking at specific OSS a solution to the problem? Pointless questions not focusing on the issue.
"Allow me this thought experiment: One person holds up a black box and asks you to stick your hand "
Now, lets say the same thing happens FOSS-style. The box is clear but people dive in blindfolded without being asked. That's vast majority of FOSS with negligible security benefit. Next, someone looks at the box but has neither seen a snake nor knows which are venomous. This is people glancing at the code. Lets say they know 1 or 2 venomous snakes, ask they be removed, and dive into the others because they didn't know how to spot them. This is amateurs or pro's with little domain knowledge knocking out low-hanging fruit (err, snakes). Finally, let's say an expert on all poisonous snakes puts significant time inspecting the box to make sure no adults or even babies lurk in there. After they're gone, the expert inserts their hand with no damage unless a new type of snake was hidden in there.
I choose the box where an expert looked inside to remove as many dangers as possible. I don't care if it's open or closed for my baseline: just that it was vetted by reliable people with evidence it's the same box. Most proprietary and FOSS software doesn't meet this standard although it was mostly proprietary that reached highest level of proof. Took a lot of expensive experts years to do it is why. FOSS theoretically has an advantage due to free labor but they just don't do high-security. Hard to get them to use safer, systems languages and unit testing much less high-security methods.
So, there's your example. It withers away once the truth is once again demonstrated: it's the review(s), what was reviewed, and if you trust reviewer or review methods. OSS only helps in rare case that more pro's or experts are interested in doing that. It occasionally happens but too rare to be the rule for the baseline.
Would their software be safer if it was open source? Probably. Open code is rarely a loss for security. But it's not easy to say how much safer. Probably less than you think.
>One programmer wrote an article on it saying it was actually good code.
"one programmer" commenting about 30+ million lines of code. Yeah. uh-huh. Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase.
>The problem areas seem to be little hacks they had littered everywhere to keep 3rd party hardware or software from breaking.
Those are mostly relegated to the compatibility shim layer. You can turn it off, in any case.
Yeah, my inability to evaluate the skill level or character of source was main drawback of claim. I gave a little credence to it because I knew that they were ramping up QA due to image problems and potential lost sales. Steve Lipner... who did high-assurance security with legendary Paul Karger... came in to turn it around with the SDL. Massive investment in professional programmers to find quality issues across the lifecycle implies it would have fewer issues than average software.
https://msdn.microsoft.com/en-us/library/ms995349.aspx
""one programmer" commenting about 30+ million lines of code. Yeah. uh-huh."
You can tell a lot by glancing at random samples while digging into a bit fewer. Good, well-commented code with various security checks stands out for people that spend years looking at the opposite. All such a review could say, though, was that people were putting in effort. Actual security would need thorough review.
"Anyway, you can still find the kernel's source if you care to dig around. Its the Windows Research Kernel but it's mostly unchanged from the commercial codebase."
Will do. Appreciate the tip.
CDCFKW.zip not saying anything.. just sayin :P
And indeed; very few companies spent as much money as Microsoft on their entire SDL. Sadly never had the chance to get a look into Google's kitchen but I'm hearing that they're great too.
They're also not dealing with the kind of backwards compatibility that Microsoft is dealing with which helps them out a lot too.
The idea sounds similar to Qubes OS, with the exception that it's transparent to the user and doesn't have to be configured by the end-user.
I presume this kills any of the offline-storage approaches?
But anyhow this is quite amazing idea, Microsoft really tries hard to improve Edge.
The reason they can overcome technical difficulty of something this cool is because they have very consistent and very limited underlying platform (they don't have to support macOS, Linux, etc). Imagine how hard it would be for Firefox and chrome to pull off something similar.
>I presume this kills any of the offline-storage approaches?
Not necessarily, it depends on how they did implement this.
(I may be wrong,please correct me)
I'm really hoping for the former, as it'll mean they finally might expose a KVM-esque API. That would mean a drastic change for virtualization dev on Windows.
This looks like a use of those containers for running edge processes.
So basically when you run this protected Edge session it starts the browser in a Hyper-V container, it has some read access to the host file system, registry, etc. but no write and when the session is closed everything else goes with it.
https://www.acsa-admin.org/2006/papers/epstein-paper.pdf
Vendors of separation kernels, with Green Hills in lead, started distributing MILS workstations with browser VM's and such in 2005:
http://www.ghs.com/news/20050419_secure_products.html
Tahoma started first browser-oriented OS running on Xen and Linux in 2006:
https://www.gribble.org/papers/gribble-Tahoma.pdf
Finally, OP Web Browser applied POLA and safe languages internally around 2008 with Chrome partly copying it (with less security for performance):
http://www.cse.psu.edu/~trj1/cse543-s15/docs/grier_sp08.pdf
So, high-assurance community has been on this with numerous projects and products released. Many had small, strong TCB's. The oldest had the color schemes and everything. QubesOS is the newcomer with less security than many forerunners but great usability & openness. Better than average Linux distro. Closest to prior designs with active community is genode.org.
People interested in Microsoft Research's work on secure browsers should look at Gazelle browser and Xax plugin architecture:
https://www.microsoft.com/en-us/research/wp-content/uploads/...
https://www.microsoft.com/en-us/research/wp-content/uploads/...
It does sound like an interesting capability for private browsing, but existing mechanisms mostly cover that. Even if WDAG applied to private Windows, ordinary users aren't so likely to open private browser windows just to check a link from an email.
I expect that if you had a copy of Win10 Enterprise you could configure the feature yourself for added security in paranoid cases (e.g. journalist covering abusive regimes who might be targeted by state-level malware).
Cappsule (open-source for Linux), https://cappsule.github.io
Bromium (proprietary for Windows, based on open-source Xen), https://blogs.bromium.com/2016/09/26/introducing-virtualizat...You should enable Ad/tracker-block by default and across the board.