[imardmd1]

If you are only using Google as a search engine, perhaps this one will give you a little protection. Easy to install. I've been using it for about a year.

[RobertClark]

Unless you use a proxy to get to StartPage to begin with, you still have a problem. The traffic from your IP address is visible to have arrived there. On top of that, the backdoors built into Windows and Apple OS’s would stagger most people.

[OneWingedShark]

FireFox Plugin to use IxQuick in the Search drop-down.

[Jyotishi]

Thanks for your post. Please see this discussion:

Alternatives to Microsoft, Yahoo, Google, Facebook, PalTalk, AOL, etc.

http://www.metafilter.com/129454/Alternatives-to-Microsoft-Yahoo-Google-Facebook-PalTalk-AOL-etc

[b4its2late]

Here's another - > DuckDuckGo

[ShadowAce]

[Sergio]

cyber security bookmark

[Pajamajan]

bookmark

[brandon24]

I’ve used Startpage for a year now too. I like that each search result has a link below where you can optionally open it in their built in proxy.

This is a good link >
http://prism-break.org/

This is the best FREE cross platform secure phone app i found so far. https://mocana.com/for-device-manufacturers/keytone/

[cynwoody]

I see a flaw here. When I click StartPage's padlock, Chrome informs me that

Your connection to startpage.com is encrypted with 128-bit encryption.

The connection uses TLS 1.0.

The connection is encrypted using RC4_128, with SHA1 for message authentication and RSA as the key exchange mechanism.

However, when I do the same while connected to Google, I see (bold-face added):

Your connection to www.google.com is encrypted with 128-bit encryption.

The connection uses TLS 1.1.

The connection is encrypted using RC4_128, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.

What does this mean? It's called Perfect Forward Security (PFS). It means that, even if NSA eventually obtains Google's private key, they will still not be able to decrypt previously intercepted traffic. That is not the case for StartPage.

With regular key exchange, the client picks a session key and shares it with the server encrypted with the server's public key. That means anybody who has the server's private key or succeeds in obtaining it in the future can decrypt the session key and recover the session plain text. However, with ECDHE_RSA, the client and server use a far more devious way to share the session key, which does not require the full key to be sent, even encrypted with the server's public key. As Vincent Bernat explains:

Unlike with the classic Diffie-Hellman key exchange, the client and the server need to agree on the various paremeters. Most of this agreement is done inside Client Hello and Server Hello messages. While it is possible to define some arbitrary parameters, web browsers will only support a handful of predefined curves, usually NIST P-256, P-384 and P-521. From here, the key exchange with elliptic curves is pretty similar to the classic Diffie-Hellman one:

1. The server picks a random integer a and compute aG which will be sent, unencrypted but signed with its private key for authentication purpose, in a Server Key Exchange message.
2. The client checks that the signature is correct. It also picks a random integer b and sends bG in a Client Key Exchange message. It will also compute b⋅aG=abG which is the premaster secret from which the master secret is derived.
3. The server will receive bG and compute a⋅bG=abG which is the same premaster secret known by the client.

An eavesdropper will only see aG and bG and won’t be able to compute efficiently abG.

The second E in ECDHE_RSA stands for "ephemeral", referring to the above method of sharing the session key using ephemerally chosen crypto parameters.

[CodeToad]

So long as you are receiving data over the Internet your data can be recorded. It isn’t the distant end that they track. They track exactly what it coming and going from your connection. Yours. Not the website. Not a proxy server. Yours. Directly.

[21stCenturion]

...