Networking – How to protect theself while using public wifi hotspots

a1) What do you mean by "what are the chances"? What are the chances the wifi owner is malicious, or what are the chances they can do it if they are? The former question I have no data on. The latter depends on what you're using their wifi for. If you are downloading executable files and running them then obviously it's very easy for them to put malware on your computer. The next most likely vectors are PDFs, or malicious Java / Flash / scripts on websites, but all of those would need you to be running vulnerable software (although in the case of Adobe Acrobat, it is vulnerable even if you are 100% up to date, we just don't know what's wrong with it yet ;)

To avoid this I would say, in ascending order of paranoia (i.e. 1 is sensible, the rest are more paranoid):

1. Do not download any executables over an internet connection you don't trust
2. Don't have your browser set up to open PDFs in Acrobat (there are many safer alternatives), Flash, or Java applets without asking you
3. Consider using NoScript

Of course, if you are using SSL websites, then they cannot modify what data you get. Probably. See answer 3.

a2) Assuming no malware has been planted on your computer, and you operate under the rules in answer 1, effectively zero. There might be programs that are leaking information, or have bugs that let people put things on your computer, but that isn't really relevant to the wifi. Minimising the number of applications allowed to use the internet (in the firewall settings) is a good idea for this reason.

a3) When you use HTTPs your browser verifies that the site is who they say they are by checking their certificate. Only certain people can give out these certificates, and your browser knows how to check theirs.

What does this mean for security? Well for one, it means you are trusting those certificate writers. There have been attacks on their systems to produce fraudulent certs in the past, and there have been cases of browsers trusting certificate authorities that no one is quite sure who owns them now.

What can you do? Some browsers have extensions to help you out here. What you want is something that remembers what certificate a given website had last time you visited it, and will put up a big fat warning if that changes. This means even if a certificate authority is compromised in some way, you still won't hand over your data.

This is a very unlikely outcome, by the way - it would require someone to obtain a fraudulent cert AND to then target people using that site over their wifi... Given the value of the cert, and the effort to obtain it, it's much more likely it would be used in a wider attack. But it won't hurt to protect yourself against such things, anyway.

Oh and of course, sites using self-signed certificates are trivial to masquerade as. Having an extension that compares the cert to the last time you accessed them would alert you to any man-in-the-middle going on.

q3) the sensitive data I transmit using https being seen or stolen and unencrypted?

Short answer: As long as you install a Chrome extension from the Chrome Web Store and do not explicitly install a separate standalone binary, then the extension is, by default, trapped within the browser profile and cannot access nor modify other Chrome users. To say that there are "no filesystem protection in place" is inaccurate, as Chrome has never supported XUL-type extensions.

I'll address the two ways the other answer mentions as routes an extension can leverage to escape the confinement of a browser profile and access other parts of the filesystem, plus an extra. The first is through the nativeMessaging WebExtension permission, the second through triggering a file dialog, and the third is through the isAllowedFileSchemeAccess API. None are automatic (background or otherwise) and all require the user to explicitly agree to such access.

1) A WebExtension using the nativeMessaging permission cannot pull in the privileged native application on its own. Until the user explicitly decides to install the native application, the WebExtension is trapped within the browser profile it was installed in.

From the other answer, "[i]f any ... extensio[n] require[s] administrator access to install" then said software comprises more than just a pure Chrome extension, e.g., the extension taps into a standalone nativeMessaging client installed outside of Chrome, and by installing the external client (outside of Chrome) one might as well have installed a system-wide standalone keylogger binary that affects much more than just the browser. Game over, but the user's fault, since s/he has overridden the security provided by the browser.

2) From the other answer: "I was ... able to launch a portable copy of Firefox in which I installed an sqlite browser ... and browse to my old profile and see my history." File dialogs require explicit user interaction, hence this is not a security bug. If the user explicitly loads files into the browser profile for the extension to manipulate, then the user has expressed his/her agreement to having their data shared with the extension. Otherwise, the extension can do nothing but hope for the user to select a file in the Open File dialog, which the user (recalling the profile is meant to trap potentially untrustworthy extensions) can simply close.

3) The isAllowedFileSchemeAccess API on Chrome allows read-only access to the filesystem via the file:// protocol. However, "a user must explicitly permit this behavior for a given extension through the Chrome preferences pane in chrome://extensions" and as of early 2017 only 55 extensions on the CWS ask for it. (Source: Mozilla Wiki) Not only is the likelihood of encountering an extension abusing this privilege to snoop into the filesystem highly unlikely, but the privilege also requires that the user manually grants it to a browser extension.

Using separate browser profiles to isolate potentially dangerous extensions is more than good enough, as separate OS-level user accounts is overkill, unless one is defending against zero-day browser exploits that completely trash Chrome's WebExtension API permission model, in which case VM-level protections are in order. If we're playing with software that leverages exploits, then OS-level user accounts provide insufficient protection as we are now toying with malware.

Chrome Apps are an entirely different kettle of fish since they enjoy more permissions than standard Chrome extensions, but they are a deprecated technology and, more importantly, outside the scope of the OP's question since it asks about Chrome extensions. Thus, Chrome Apps are not covered in this answer.

In conclusion, a Chrome extension cannot jump across browser profiles unless 1) the user has manually installed a standalone executable external to Chrome, in which case all bets are off 2) the user selects a file in a file open dialog generated by an extension, in which case the user has explicitly granted the extension permission for arbitrary file access 3) the user manually ticks a box in chrome://extensions that extensions cannot themselves modify.