- Credits
- 52,633
I hope DuckDuckGo future web browser uses less RAM and CPU resources than Chrome and Firefox which can use a lot of system resoutces.
I've never used Duck Duck Go. I see their ads all of the time which always makes me wonder how do they make their money to be able to afford so many ads.
Virtual machines do nothing about privacy protection. VM’s are for playing with sandbox environments, testing out OS’s, or separating single system application servers. Anything regarding security is a waste of time.There's a lot of garbage already on apps we just don't know about. Simply because there's a contractual agreement involved. There's a lot of information stored about what we do simply while being on internet providers. Used for and against us. I've heard virtual machines are the way. Browsers? There is typically more than one option.
Well, I saw a video a while back it helps detain viruses due to browser insecurities.Virtual machines do nothing about privacy protection. VM’s are for playing with sandbox environments, testing out OS’s, or separating single system application servers. Anything regarding security is a waste of time.
He’s technically not wrong, but you should have a VM that’s completely isolated from the host, and like he said, don’t use any of your personal accounts on it. You also shouldn’t transfer your files from the VM to the host as those could be infected.Well, I saw a video a while back it helps detain viruses due to browser insecurities.
About halfway through.
VMs can definitely cross over. Usually you have them networked, so any malware with a network component (i.e. worms) will propagate to wherever their addressing/routing allows them to. Regular viruses tend to only operate in usermode, so while they couldn't communicate overtly, they could still set up a covert channel. If you are sharing CPUs, a busy process on one VM can effectively communicate state to another VM (that's your prototypical timing covert channel). Storage covert channel would be a bit harder as the virtual disks tend to have a hard limit on them, so unless you have a system that can over-commit disk space, it should not be an issue.
The most interesting approach to securing VMs is called the Separation Kernel. It's a result of John Rushby's 1981 paper which basically states that in order to have VMs isolated in a manner that could be equivalent to physical separation, the computer must export its resources to specific VMs in a way where at no point any resource that can store state is shared between VMs. This has deep consequences, as it requires the underlying computer architecture to be designed in a way in which this can be carried out in a non-bypassable manner.
30yrs after this paper, we finally have few products that claim to do it. x86 isn't the greatest platform for it, as there are many instructions that cannot be virtualized, to fully support the 'no sharing' idea. It is also not very practical for common systems, as to have four VMs, you'd need four harddrives hanging off four disk controllers, four video cards, four USB controllers with four mice, etc..
2020 update: all the recent hardware based vulnerabilities (Meltdown,Spectre,Foreshadow,ZombieLoad,CacheOut,SPOILER,etc) family of vulnerabilities are great examples of how VM's are always going to be able to communicate, simply because they share hardware (caches, TLB, branch prediction, TSX, SGX) that were never intended or prepared to be partitioned and isolated.