right - this needs some background, so i'll attempt to explain this backwards first:
When you visit a website, and it's using HTTP, it's all in plain text. Anyone with access to your connection can read your traffic like it's written on a postcard.
HTTPS stops that from happening, because the chats between your browser and the website are encrypted - they're scrambled in a way that only the sender and receiver can decrypt them., because maths.
With me so far? Grand.
So, when you connect to whetever website dot com you're trying to access, the web server says "oh, hello - i'm website dot com" and offers your browser its security credentials - it's SSL (secure socket layer) certificate.
Your browser looks at that, goes "grand, thanks - i accept that this certificate belongs to website.com", you and the server exchange encryption keys (i'm not even going to try to explain this bit), and from then on your communications are in SUPER SECRET CODE and can no longer be read by anyone who happens to have access to the traffic going back and forth between you.
So right now you're probably thinking "Whoooahhh COOL THE JETS THERE - why does my browser just accept whatever the web server tells it?" And the answer is.... It doesn't.
We need to go back a couple of paragraphs. In order for the web server to get an SSL certificate, the owner of the server needs to go to a Certificate Authority, jump through some administrative hoops to prove to them that they are in fact the the website dot com domain in question, and in return they get a certificate that they can install on the server that's been signed by the certificate authority to confirm that, yes, they are in fact website dot com.
"AHA," you're probably thinking, "but how does my browser know to trust that certificate? Couldn't anyone just generate a certificate that says it's for website dot com?"
A very good question - and yes, they could. It's just a bit of software after all.
So this is where Root Certificates come in.
It's all about a chain of trust. Remember I said that the Certificate Authority signs the certificates they issue? Well, by default the top level certificate authority's root certificates are installed in every internet browser. This is how your computer knows to trust a certificate that's offered to them - if the certificate has been issued by LetsEncrypt, and you have the LetsEncrypt root certificate installed, your browser can verify its authenticity by checking the signature on the certificate it's being offered against the root certificate it already has. If they match (or rather if some pretty wild calculations match) it's a legitimate certificate and can be trusted.
And this is where the problem comes in: If you install a root certificate from a dodgy source, you're basically giving the controller of that certificate authority the capability to issue certificates on behalf of any domain out there on the internet AND YOUR BROWSER WILL JUST ACCEPT IT AS 100% TOTES LEGIT NO QUESTIONS ASKED.
If you combine this with control of your connection to the internet, you've got a pretty fucking serious security problem.
Let's say you want to go to gmail.com and someone with control (legitimate or otherwise) of your internet connection decides to route your gmail.com traffic to a server they control instead; and lets say that server has been configured to pretend it's the real gmail.com.
In the normal course of events your browser will take one look and say DANGER WILL ROBINSON, GTFO - because the fake server won't have a legit SSL certificate to verify its claim that it is in fact gmail.com, and all will be right in the world.
BUT if they've also managed to get you to install a root certificate from a certificate authority they control, you're fucked. You're connecting to the wrong server, but your browser (and you) are completely oblivious.
Now, in the real world this is more likely to be used to intercept and pass on communications (like, say, the username and password you just typed into that fake gmail.com server you visited a few paragraphs back) without alerting you to the fact that this is happening.
In a work environment you'll usually see this being used to crack open your https sessions at the firewall / internet proxy server so that content analysis can be performed to make sure you're not looking at filth or leaking secrets. In other words, your employer installs their own root certificate on every browser, then whenever you try to access website dot com, their firewall or proxy server responds and offers your browser a fake website dot com certificate, your browser accepts it (because it's been signed with the root certificate your browser implicitly trusts).
The firewall/proxy server then connects out to website dot com on your behalf, gets the actual ssl cert, then sits there in the middle reading and logging all your messages.
Here's an awful diagram by way of explanation:
Browser---[fake ssl certificate] --- FIREWALL --- [real website.com ssl cert] --- website.com
Anyway you might not like it, but you probably signed something to say you're cool with it as a condition of your employment. Also, GET ON WITH YOUR WORK.
It's actually way more complicated than this and sometimes fails miserably (and rightly so) because of a thing called HSTS being enabled which is designed to prevent this very thing from happening. And there are intermediate certificate authorities and there are other things that i'm not going to go into BUT WAIT - I ACTUALLY HAVE A POINT!
What Facebook were able to do, thanks to a combination of controlling the device's internet access with their "VPN" app mentioned above and getting people who didn't understand what a root certificate is or what the implications of installing one was, was get completely unfettered access to every single bit of data going to or from the device.
Likewise virginmedia and their free wifi service that requires the installation of a root certificate. They control the internet connection, and they control the validation of security.
i reaslise this probably makes little or no sense.
Powerful Permissions, Wimpy Warnings: Installing a Root Certificate Should be Scary
Installing a root certificate should be MUCH scarier