HTTPSEverywhere will not magically upgrade a site that doesn't serve HTTPS to HTTPS. If you connect to a site that doesn't support HTTPS, you are vulnerable.
It has the option to block HTTP traffic, making sites that don't support HTTPS unusable.
You could create a separate "secure" profile and feel safe that all traffic is secured, while still being able to browse HTTP in another profile, for instance.
Theoretically. The extension can refuse to load sites that aren’t using HTTPS, but the real flaw is sites that use SSL instead of TLS. Attackers can reject SSL but they can’t do anything about TLS, so the security of your browsing would be affected by the website’s HTTPS configuration, and whether they use SSL, TLS, or both (the only 100% safe method is TLS only). I know for most people disabling SSL and going TLS-only isn’t high on their list of priorities so I expect this attack to be very successful on the internet as it is right now.
ive been trying keypirinha since a few weeks ago. its not bad. its nice improvement over launchy and is being developed unlike launchy which hasnt been touched in years.
having to change the settings from a text file in keypirinha is bit of a pain though.
anyway, from what i can tell, cerebro is able to show you a lot more things and also has plugins. keypirinha just shows basic things like files and apps i think
That (most likely) would of used oauth. So instead of sending your FB password to the site to log you into FB with. You give your FB password (if your not signed in) to FB and then facebook give the site using "sign in with Facebook" a token they can use with facebook to get account info / do actions on your FB account.
Now depending on which "sign in with" system you used then often the code handed back to the site (via a callback URL handled by the client) is a single use code. So once the site using "sign in with" has used the code with FB they get another set of tokens they will use with Facebook directly.
After the initial "sign in with" process the Facebook tokens are most likely never handed to clients (because they often need to be mixed with a site secret during requests to the likes of Facebook).
So you _should_ be ok if you used a decent "sign in with" system like facebooks as the only thing that would of been handed back to the client and then sent from the client to the site is that single use code. The communication with the site and facebook would of used an API endpoint.
Now... If you used another sites (not facebook) "sign in with" system and their API is also behind Cloudflare it could well be that some API keys could be in a cache somewhere. If those requests were signed with secrets you should be fine because without the sites secrets to lets say create a hmac signature for the request then while there might be some personally identifiable information in caches somewhere the signatures should of already expired meaning that they can't be used in say a replay attack and the data cached can't be used to create fresh requests.
BUT this all depends on everyone doing things right, which may not be the case. But either way, oauth tokens are often not revoked when you change your password. I.e. you might change your FB password and then still be able to auto login on somesmallsite.org because the tokens shared between FB and somesmallsite.whatever haven't changed.
