Firefox seems to be the only browser in which one can maintain privacy and security (e.g. all the privacy tweaks from privacytools.io). Chrome doesn't allow for most of the tweaks, for example WebRTC can't be disabled.

For privacy the Tor browser - but even then only in a VM because of the prevalence of exploits. Regular Firefox will just get you fingerprinted in any case.

> unstable Chrome/Chromium releases

The build site I linked to lets you switch between trunk/stable

[0] if you know what you're doing you can change the WebRTC route settings with this extension https://chrome.google.com/webstore/detail/webrtc-leak-preven...

https://wiki.mozilla.org/Security/Sandbox

The second difference and a large advantage Google has is the security team they've put together to find and fix bugs. Google between project zero and engineering are probably the best team in the world. Firefox don't really have an equivalent.

Then there is the legacy code that Firefox is built on and the problems that had lead to. In Chrome a successful exploit requires the combination of 5-6 diff bugs/exploits to bypass all the controls and sandboxes, while in FF many straight forward bugs become exploits.

This is most reflected in two places: First the pwn2own contest where FF does poorly[0] and second in the price of 0day between Firefox and Chrome. The Chrome exploit price has never been less than $100k and at the moment $1M+ is being turned down, while OTOH Firefox started at $5-10k and at the moment is $25-30k and are common (common in a browser exploit sense).

The idea situation would be a Chromium fork that is built with the Firefox UI / extensions / settings / profiles etc. built on top of it. I've wanted to build this project for a long time and have a privacy/security specific browser but have never had the chance to do it. I hope at some point somebody does - it's really complicated today to recommend both a secure and private browser.

[0] http://www.extremetech.com/computing/178587-firefox-is-still...

It's in the OP:

"I highly recommend using KeepassX as a password manager, secured using a key file and not a password. Also, you should download the source code, compile it (using a Linux machine) and always look over the source code for rogue functions, you CANNOT afford a vulnerability inside the password manager."

That being said, I'm decent with C++, and yet auditing its code is a little daunting.

I don't really understand the reasoning behind that - so rather than trusting a proven OS and its packages with lots of eyes on the critical code, I should rather read the code of a cryptographic product and then make a decision based on that? Common advice is not to write crypto code yourself, but reading it and deciding that there might be a backdoor based on gut feeling is right? And having identified some stuff I don't understand, then decide for another program that is goofy but easier to read, and compromise security?

So if there are rules to improve the privacy of users, I would worry about making it look to complex or extreme. I suspect rather than picking some parts that work for them they will go "ok this i can do, this I can do, and .. wait compile it myself and read the source?! - ok, I'll stick to post it notes".

1. http://keepass.info/help/base/security.html#secdesktop 2. http://arstechnica.com/security/2014/07/this-thumbdrive-hack... 3. http://keepass.info/help/base/security.html#secdictprotect

Because you're always just one burglary away from passwordocalypse?

My password database is stored on a USB key that I carry with me, with a regular copy made and securely stored.

Key file is stored on devices I use, in a directory restricted to my own access and on a drive which is encrypted. An encrypted copy is also stored on the USB key with the password database; this can be decrypted using a GPG, key stored on a yubikey and also carried; if a device can be trusted enough, this is how I move the key file around.

Access to the database requires 3 things rather than two. A long passphrase could be recorded by an observer, who could then take my USB key. The key file ensures that they still do not have all that they need.

2. I do that. In addition I use this: http://winhelp2002.mvps.org/hosts.htm I have a python script that builds a host file from several sources.

4. Most readers here should be able to build their own router with a banana pi and IPfire

I eventually got many not-so-technical family members and friends to adopt Dashlane - which is easy to use and provides great support.

> 2. I do that. In addition I use this: http://winhelp2002.mvps.org/hosts.htm

That's a good idea - you can also configure a local bind/dnsmasq/unbound server to block based on these lists with ACL's (sure if you google each you'll find tutorials, like this one: https://github.com/jodrell/unbound-block-hosts)

Some of the better home router distros will also do this at the local network level

I don't see how you could do better than something like 1Password. What is missing in your opinion?

I don't understand why they don't offer (at least) 2-factor key for the vault.

Also, they support TouchID on iOS devices, very useful. But in the US, at least one case of someone being legally required to unlock via TouchID, whereas offering up a passcode is still debatable.

So at least offer a short PIN-and-TouchID, and support some 2-factor like Googly Authenticator.

They must have at least considered these things. I don't understand any security issues with this. Implementation is work, and perhaps a support hassle for them.

What are the technical reasons?

This is pretty much the nature of password managers. That password is only ever entered locally. If an attacker can grab local keystrokes, it's game over anyway.

>they don't offer (at least) 2-factor key for the vault

Neither TOTP nor any kind of push/SMS token can be used to secure data at rest. These are mechanisms to authenticate to a server. You could have "2 factor" for data at rest by storing part of the key separately, but there'd be nothing dynamic about it; copying the key material once would be sufficient to use it forever.

LastPass offers 2-factor to authenticate to the LastPass website, but your vault is cached encrypted on the client side, and such a cached copy can be opened using only the master password. (IIRC there is an option to disable this, which works by erasing the cached copy at the end of a session. Hardly bulletproof, and precludes having any sort of backup resilient to the failure of LastPass itself).

I can understand that TOTP cannot be used for encryption.

But the app is asking for authentication. Zero-knowledge proof game might apply. Of course the local app must have the decrypted key in memory.

I wish we could defend against the Evil Maid...

The app is not asking for authentication, it's asking for encryption. Else an attacker could bypass the app's logic and read its data directly.

Take a look on FreeContributor [1]

[1] https://tbds.github.io/FreeContributor/

Its important that you dont host any domains on the VPS you run the VPN on.

Security might not be top priority at the VPS provider.

All your requests come from the same IP address (and the VPN provider might very easily give out your private info).

I think a VPN from a reputable provider (like f-secure) is better for most users.

I think a reputable VPN provider offers the better tradeoff, but there are legitimate reasons for self-hosting a VPN.

To leverage this, it's fairly easy to detect you're on a self-hosted VPN: your IP is in an IP range assigned to a hosting/colocation provider, is not a TOR proxy (there is a public list of those) and doesn't belong to any remotely popular VPN (easy to enumerate for a little money, lots of lists exist).

In exchange for that you have eliminated your ISP (or public wifi) as a threat but instead added the hosting provider to the list of threads. And for any adversary that stands above the law, the routing infrastructure of your hosting provider is already a valuable target.

My Streisand hosted on AWS looks to the outside like anybody else's Streisand hosted on AWS, doesn't it?

Similarly, my f-secure egress looks like anybody else's f-secure egress, so what's the difference?

I don't really know, I don't use a VPN. Really asking.

They certainly let law enforcement and intelligence agencies know, often without a warrant.

Please read my comment as if the threat model includes panopticon governments, not common skids running aircrack-ng.

(I'm not saying you're wrong; again I've not really thought about having to thoroughly anonymize my own traffic.)

Why is that is I may ask? I have the impression that the great firewall blacks a lot of domains by default and they are allowed/blocked after a review after somebody tries to access them the first time. I may be paranoid but often I try to open an obscure site. It is blocked. I have to use a VPN. A few days later the site can be accessed. Why not use a VPN sever with a nice website that makes it look harmless?

- You might forget private whois and expose your identity. - There might be issues with the private whois that exposes your identity. - The contents of the website might expose you.

What does this mean? I've tried to figure it out from context, the article, and a quick google search, but It's not clear how dns sinkholing is going to help me stay secure.

https://support.mozilla.org/en-US/kb/create-secure-passwords...

If you're really personally targeted, then I agree with you. But for a casual person it's probably an easier thing to convince them of doing this instead of installing a password manager.

What accounts? At least for financial fraud this is certainly not true, phishing remains #1 by far.

I'd also hazard to guess that botnet logs result in far more hijackings than password reuse.