Slashdot Mirror


Google Offers Encrypted Web Search Option

alphadogg writes "People who want to shield their use of Google's Web search engine from network snoops now have the option of encrypting the session with SSL protection. In the case of Google search, SSL will protect the transmission of search queries entered by users and the search results returned by Google servers. Google began rolling out the encrypted version of its Web search engine on Friday. 'We think users will appreciate this new option for searching. It's a helpful addition to users' online privacy and security, and we'll continue to add encryption support for more search offerings,' wrote Evan Roseman, a Google software engineer, in an official blog post."

12 of 288 comments (clear)

  1. The real reason by Anonymous Coward · · Score: 5, Interesting

    The real reason is that internet hacking people have been figuring out how to monetize the traffic they sniff. This is merely Google reclaiming the market that is rightfully theirs.

    1. Re:The real reason by Jackie_Chan_Fan · · Score: 4, Interesting

      Exactly right. This is not about your privacy... Its about Google protecting their market from say Verizon who could be packet sniffing anything you search on Google, and then selling that data... which then competes with Google.

      Google is simply protecting their business. It has nothing to do with user rights or privacy.

      But it is a welcomed addition. Its certainly a good thing... but it is also more for Google, than for you.

  2. Now I can Google my SSN and CC#!!! by AmazinglySmooth · · Score: 3, Interesting

    I really wanted to know if any site are posting my SSN and CC#. Thanks you, Google.

  3. Localization? by Anonymous Coward · · Score: 1, Interesting

    So I just tried https://www.google.co.uk/ and it redirects to unencrypted http://www.google.se/ (.se because that's where ipredator connections show-up as, I guess)

  4. Re:All HTTP traffic should be encrypted by jimicus · · Score: 1, Interesting

    IMO, the only reason we don't do it more is because the way browsers handle self-signed certificates is broken.

    There's no reason for a browser to throw up nasty error dialogs when it encounters a self-signed certificate. Instead, browsers should silently accept such certificates and record the public key fingerprint. Browsers shouldn't turn on the lock icon when using a self-signed cert, or do anything else to make the user think they're browsing on a secure connection, because they're really not, but they should go ahead and encrypt the traffic

    Either you're trolling or you honestly have no idea why it's a good idea to throw up all sorts of errors on encountering a self-signed certificate.

    Clue: SSL is intended to guarantee that nobody can eavesdrop on your connection. As soon as you start to see anomalies in the certificate chain (such as a self-signed certificate), that guarantee cannot be upheld. In fact, there was a bug filed against Firefox a while back now when it did flash up such an error and it transpired that the connection was being eavesdropped.

  5. I got a glimpse of this early yesterday by sootman · · Score: 2, Interesting

    After typing in www.google.com to play some Pac-Man yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/. At first I thought all requests to http://.../ were being redirected to https://.../ but after a couple reloads I was back at http://.../ and Pac-Man, and even when I typed in https://.../ it redirected me back to http://./

    My question now is, how long until the built-in browser search box in Safari uses this? (I'm sure the one in Firefox can handle this already, or will soon.) Another question: why not use https all the time? I know it's a bit more CPU to encrypt things, which is unnoticeable on modern clients, but how much of a strain is it on servers? Also, are there any popular clients out that don't support it? Is there any reason not to go all https all the time?

    --
    Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
  6. Check that fingerprint... especially at WORK by yup2000 · · Score: 3, Interesting

    but be sure to write down google's ssl fingerprint... and check it every now and then yourself. You never know when your place of work decides to start intercepting https! Mine did recently until I pointed out issues with HIPAA compliance in conjunction with our limited personal use policy! They (work) installed their own certificate on everyone's computers (but they didn't do Firefox which is why i noticed)... and then they modified the proxy servers to start taking a peek before re-encrypting and sending it along :(

  7. Good by Gonoff · · Score: 2, Interesting

    This will stop nosey people in the middle sniffing my searches.

    Is there a way of doing an "advanced search" that only brings up HTTPS results - apart from putting that as a part of the search string?

    --
    I'll see your Constitution and raise you a Queen.
  8. Close... but what about auto-suggests by poind3xt3r · · Score: 3, Interesting

    While Googles searches are secure, it would appear autosuggests? I use FF's search bar and set the search engine to use SSL. Forcing the autosuggest url to https redirects back to http which means anyone sniffing for suggestqueries.google.com can still find out my queries

  9. Re:All HTTP traffic should be encrypted by bodan · · Score: 2, Interesting

    From the user’s point of view, the suggestion wasn’t to add a new level of security. The suggestion was that a SSL connection with a self-signed certificate should be presented to the user _exactly_ the same as a normal HTTP connection. Which makes sense, as the user still doesn’t have any sort of guarantee about who they’re connected to.

    Again: for the user, there’s secure (which means properly certified SSL, and a lock, and whatever other visual indicators), or insecure (anything else; no lock, no other visual indication).

    The advantages of this are two-fold:
    * the data is encrypted; you still can intercept it, but you need to work much harder; with HTTP you can just passively listen with Wireshark
    * the browser can detect when the self-signed certificate changes, and only _then_ make a fuss. Someone who starts to intercept your traffic (that is, they didn’t do it from the beginning) will be severely inconvenienced when intercepting sites you’ve already visited before they started intercepting

    It’s doesn’t make everything perfectly safe, but it certainly increases safety.

    --
    "I think I am a fallen star. I should wish on myself."
  10. Interesting side effect by mysidia · · Score: 4, Interesting

    Corporate IT will no longer be able to monitor Google search activity merely by intercepting port 80 traffic.

    They also cannot implement a webfilter that simply monitors port 80 traffic, and denies your ability to search, based on keyword.

    They can't block SSL either, since Google requires SSL for certain things (login to Google accounts, google webmaster tools, google checkout) that Enterprise users may require.

  11. Re:and in other news... by grmoc · · Score: 2, Interesting

    In this case you need to put a root cert on the school's computers, and do a MITM for SSL.
    SSL doesn't mean no MITM. It means no *unauthorized* MITM...