Specifically, Google sent these messages to sites doing “weird redirects.” I’ve personally seen a spike in the number of sites redirecting from their web site to a non-authorized site recently. The webmaster is typically unaware of this redirect because the redirects only occur when someone clicks from Google’s search results to the web site. Typically the site owner doesn’t go to Google to find his web site; the site owner goes directly to the site.

To help webmasters and site owners become aware of this hack, Google has sent out messages to about 20,000 sites effected by this to give them the heads up.

Here is Matt Cutts’ tweet:

Is your site doing weird redirects? We just sent a “your site might be hacked” msg to 20K sites, e.g. goo.gl/S6Ptk

— Matt Cutts (@mattcutts) April 16, 2012

For more on hacked sites and malware, see this Google document.

Related Stories:

• Matt Cutts On Appealing Google Malware Warnings
• Google Warns Of Malware Redirecting To Its Search Results
• Google Adds Site Hacked Notifications To Search Results
• Google Search Results Now May Display Malware Warnings
• Google Warns Of Malware Redirecting To Its Search Results

“We are currently testing the change to use SSL for built-in Google searches in our Firefox nightly channel. If no issues are uncovered, it will move through our Aurora and Beta release channels before eventually shipping to all our Firefox users. This will include migrating the changes to our non-English version of Firefox, as well,” said Johnathan Nightingale, Director of Firefox Engineering, when I emailed Firefox about the posted change.

How The Change Happened

Privacy advocate Christopher Soghoian noted the change on his blog today. Back in February 2011, he pushed for secure search to be the default in Firefox. At that time, Google Chrome engineer Adam Langley said that using a secure version of Google known as Google Encrypted Search wouldn’t work:

We would welcome Firefox giving their users the option to use encrypted search. However, at this time we don’t feel that our encrypted search offers the features and speed that our users expect and so we wouldn’t want it to be the default. We are working towards making encrypted search as fast and complete as unencrypted search, but we’re not there yet

Since then, Google made a different method of secure searching the default for Google for signed-in users at Google.com, Google SSL Search. That renewed discussions about making secure search at Google the default for Firefox users. Both Langley and another Google employee, Mike Graboski, made comments that suggested Google had no issues with Firefox making the switch.

From Langley:

We’re happy to be offering SSL search for our signed-in users on https://www.google.com, and we’ve received a lot of positive feedback. We want to make it available on other Google domains as well, but we’re still working on that.

From Graboski:

Google’s search team is ok with Firefox using https://www.google.com for search suggestions, so please use this endpoint.  Thanks!

Google confirmed for me that Graboksi’s statement is correctly interpreted as a go-ahead for the Firefox team to make the switch, if it wanted to.

The change was formally made yesterday. As the Firefox statement notes, unless there are issues that crop up, all Firefox users who search using Firefox’s built-in features, such as its search box, will have their searches done using a secure connection.

The only exceptions to this will be for Firefox users who have changed their default search engine from Google to something else or for those using the Russian version of Firefox, which uses Yandex as its default search engine.

Impact On Consumers

The shift means more security for millions of Firefox users. It will make it harder for outsiders to potentially eavesdrop on what someone is searching for.

Just as secure connections protect someone’s credit card numbers when by things online, secure connections also mean that what someone is searching for can be seen only by Google and the person who is searching, with two important exceptions: Google’s advertisers and those who use Google Webmaster Central.

Those exceptions can’t be dismissed, even though the privacy risks with either of them is relatively small. When Google turned Google SSL Search on by default last year for logged-in users, it pitched this as protecting privacy. Nevertheless, it went out of its way to leave a loophole open for advertisers. It also seems to be ignoring the hole with Google Webmaster Central.

Make no mistake, searching was made massively more secure by Google’s move, and Firefox’s change will further make it secure for yet more people. But if the goal is to fully protect privacy, Google would upgrade the entirely different Google Encrypted Search service, and Firefox would use that.

The Privacy Loopholes

Let’s revisit secure searching at Google, to understand how with both flavors offered, search data — including potentially very private searches — can escape despite encryption.

Google has two secure searching products, Google Encrypted Search and Google SSL Search. With either, no one can eavesdrop on the searching you do with Google. That’s a big, welcomed change. But when you click on a listing or ad at Google, what you searched for will be contained in what’s called “referrer data” that your browser passes along to the destination site.

For example, do a search for “erectile dysfunction,” click on a listing, and that search term is in the referrer data that normally gets sent to the site you visit by Google. The same thing would happen if you used Yahoo or Bing, by the way. It part of how browsing software itself works.

In most cases, the site you visit isn’t going to know who you really are. They get a fairly anonymous strings of number called an IP address. But with some work, or perhaps by combining the IP address with cookie data or other information, they might be able to figure out more about who you really are.

Another way that search terms are revealed are through two Google programs for publishers: Google AdWords and Google Webmaster Central. With Google AdWords, you purchase ads, and you can see the search terms that people use when clicking on those ads. With Google Webmaster Central, you’re shown the search terms people used to reach your site over the past 30 days.

Neither of these programs link IP addresses with search terms, so there’s really no good way for publishers to match searches back to a particular person. These are helpful and relatively “safe” ways Google helps publishers without harming user privacy.

Think of it all as having a continuing “search conversation” with Google. Secure search prevents anyone from hearing the full conversation. But in some instances, when you speak loudly about a particular person, referrer data allows them to hear a tiny fragment of that talk. Even then, they still probably don’t know it was you who said it.

In short, letting search terms “escape” or “leak” via referrer data is still fairly private for the vast majority of searches that happen out there, I’d say. Despite this, Google decided this data was so sensitive that it blocked non-advertisers from getting it back in October. That magnifies the problem of why it hasn’t blocked its advertisers, as well.

SSL Vs Encrypted

Both versions of Google’s secure search leak referrers. Google Encrypted Search does this for technical reasons. Google SSL Search does it because Google deliberately wants referrers to be passed along to its advertisers.

Google Encrypted Search was launched by Google in May 2010. Originally, you could enable it by going to https://google.com. Note the additional S in the https prefix. That indicated the secure version of Google search was being used. However, the service caused problems for some schools that wanted to use other Google products. It was moved to a new location: https://encrypted.google.com.

When you use Google Encrypted Search, referrers are blocked entirely with one key exception: if you go from Google Encrypted Search to another secure site. It’s a technicality in how browsers work. When you have a secure connection to one site, no referrer data is passed along to the next unless that site also opens a secure connection for you.

This is a tiny security issue. That’s because it’s rare that you’d go from Google Encrypted Search to another secure site, since most sites don’t run secure servers that turn up in search results.

Google SSL Search largely came about in October 2011. That was when Google announced that by default, it would enable a secure searching connection for anyone who was logged into Google.com. Before then, I’m pretty sure you could go to https://google.com and establish a secure connection if you want, but it’s hard to pin this down. But really, October 2011 was the key date. Suddenly, millions of people searching on Google found they had a secure connection on by default.

How about referrer data? Google made a point to block this for anyone who clicked on its “editorial” or non-paid listings, saying this was designed to protect privacy. However, it continued to provide referrer information to its advertisers. Click on an ad after searching for “erectile dysfunction,” and an advertiser would receive both what you searched for and your IP address linked to that search.

Why Google didn’t block ALL referrers was perplexing. If search terms themselves were potentially private, as Google started arguing, then letting any of them out was bad. At best, Google concocted an odd, far-fetched defense that advertisers could run so many ads that potentially, they still might see search data.

I’ve found this unconvincing, as I explain more in 2011: The Year Google & Bing Took Away From SEOs & Publishers. That story also explains why, if search terms are so sensitive, Google should be filtering them in some way from Google Webmaster Central, as well. Also see my other article, Google’s Results Get More Personal With “Search Plus Your World”, for more about this.

The bottom line is that both versions of Google secure search allow referrers to escape, but Google Encrypted Search does this far less than Google SSL Search. If Firefox was really serious about using privacy, it would use that. But it can’t, not easily, and some of the reason for that comes back to Google.

Secure Searching Beyond The US

Firefox isn’t just used by those in the US. There are version of it for those in countries all over the world. It’s better if these country-specific versions point to the correct country-specific versions of Google (except, as mentioned, the Russian version which uses Yandex).

Google Encrypted Search is really a US/English-language service. There’s no ability to change the interface language from English to German that I can see. To even try this, you have to log in. When logged in, even if you set your language to German, Google Encrypted Search keeps speaking English back to you as the overall interface language.

In contrast, using Google SSL Search means that Firefox can point to where SSL search is formally supported already, Google.com, Google UK, Google France and Google Germany. The latter three got support in January. In March, Google announced that it would be coming to more counties over the course of several weeks. I already can see already works now for places like Google Australia, Google Poland and even Google Iceland, even though Google hasn’t formally announced this.

For Firefox, using Google SSL Search makes more sense. Country-specific versions of Firefox can use the right Google SSL Search for the right country, something that Google Encrypted Search wouldn’t allow.

Why Not Kill All Referrers?

Another way that Firefox could make things more secure would be to kill all referrer data within the browser itself. It could do this, and then there would be no leakage of terms from Google nor from other sites, when people surf the web.

I asked Firefox about this, but it didn’t provide any answer on that question, only the quote I have above.

I asked Microsoft the same for Internet Explorer, but I haven’t heard back yet.

Google told me that it doesn’t have anything to announce about this, in relation to its Chrome browser.

Fallout For Publishers

The move will be further bad news for publishers, who have come to depend on search term data passed along by referrers. It’s not uncommon to hear sites report that 20% or more of their search queries are now reported as “not provided” due to Google’s blocking.

Yesterday, I even published an example of how on my personal blog, 35% of my search terms are now withheld. Here’s the illustration, showing traffic for March 19:

The Firefox change to Google SSL Search means that this “not provided” percentage will only climb higher for all publishers. It wouldn’t be so bad if Google provided this data on a long-term basis through Google Webmaster Central. As I explained, this is a safe way for Google to tell publishers how people are reaching their sites through search while also protecting user privacy.

Unfortunately, Google only lets you gather this data back for 30 days. If publishers haven’t been tapping into it regularly, they can’t maintain trends that they’ve had before.

I continue to wish that Google would expand this data. The lack of attention here gives the impression that Google really doesn’t care that much about supporting publishers in this regard. That includes even Google advertisers, who also have “free” listing data that’s been lost.

Why Doesn’t Chrome Offer Google Secure Search?

Another twist to this story is that Firefox’s move means that it’s going to be offering a more secure way to search Google than Google’s own Chrome browser does.

By default, Chrome won’t initiate a secure connection with Google Search. If you’re logged in, however, it will maintain the default secure connection with Google.

Will this change? “We don’t have anything to announce about Chrome at this time,” Google told me.

On Secure Search, It’s Google: 2, Bing & Yahoo: 0

While I have issues with Google for allowing some search terms to leak through referrer data, Google deserves serious kudos for offering secure search overall. Its two big rivals, Bing and Yahoo don’t. As Soghoian put it, when I said it seemed kind of crazy that Google has two ways of secure searching with some referrer leakage:

Better for Google to have two secure search sites, than Microsoft and Yahoo, which have zero.

How about it, Microsoft? The company told me:

Bing does not offer SSL.  To protect themselves from being unknowingly redirected we recommend people install OpenDNS.

Of course, if you really want to be secure, you could always try Duck Duck Go. You can force a secure search there by going to https://duckduckgo.com (surprisingly, this isn’t the default). As for referrers, it doesn’t pass any on.

Related Articles

• Google Launches Encrypted Web Search
• Google Moves SSL Search To Encrypted Sub Domain
• Google To Begin Encrypting Searches & Outbound Clicks By Default With SSL Search
• Google Puts A Price On Privacy
• 2011: The Year Google & Bing Took Away From SEOs & Publishers
• Google’s Results Get More Personal With “Search Plus Your World”
• Google “Search Plus Your World” To Launch Beyond US? Likely, As Secure Search Set To Expand
• How A Google Change May Mistakenly Turn Search Traffic Into Referral Traffic
• Scroogle’s Gone? Here’s Who Still Offers Private Searching

Microsoft quickly learned about the issue on their support forums and issued a patch yesterday to address the issue. Microsoft didn’t explain it was a Google specific issue but said:

On February 14, 2012, an incorrect detection for Exploit:JS/Blacole.BW was introduced. On February 14, 2012, Microsoft released an update that addresses the issue. Signature versions 1.119.1988.0 and higher include this update.

Of course, I am sure Microsoft didn’t mind some of those Google users looking for other search engines to use for the day.

The campaign is named “Good To Know” and leads to google.co.uk/goodtoknow, where users can learn more about online safety tips.

Google teamed up with the Citizens Advice Bureau on this campaign, where the two organizations are using newspaper ads, ads on public transport and online ads to promote the initiative. One of the major pushes is to get people to use “two-factor authentication” to help protect their email and online passwords.

The Telegraph says this is the “first [campaign] that Google has ever run promoting something other than a product.” They also say Google is the organization that is “primarily” funding this campaign.

Anthony House, Google’s communications and policy manager, added that, “Everyone wants to stay safe online, but many people aren’t confident that they know how to.”

For more information, see google.co.uk/goodtoknow.

Related Stories:

• Google Warns Of Malware Redirecting To Its Search Results
• What Every Search Marketer Needs To Know About Web Security
• Google Acquires Security Company, GreenBorder
• Google Buys Security Company Postini For $625 Million
• Google Security: Google Mac Blog Hacked & Google Calendar Users Not Being Safe
• Google Adds Site Hacked Notifications To Search Results
• Google Appoints Privacy Director & Adds New Privacy Measures
• Report: Some Google ‘Hot Topic’ Searches Return 90% Malicious Links

Inside Google’s Time Warp

As searchers, we want fresh results, which Google usually provides. But Google also offers many other services, such as Google Docs, Gmail, and so on, that rely on much more accurate time stamping. Like most other online services, Google uses a service called the “Network Time Protocol” (NTP), which periodically checks a computer’s time against a more accurate server, such as an atomic clock. NTP also takes into account variable factors like how long the NTP server takes to reply, or the speed of the network between you and the server when setting a to-the-second or better time on the computer you’re using. So most of the time (so to speak) you can rely on Google to be spot-on when it comes to time-stamping everything you do.

Problem: Leap years. Of even more concern: Leap seconds. As Christopher Pascoe, Google Site Reliability Engineer writes on the Google blog, “It turns out that being on a revolving imperfect sphere floating in space, being reshaped by earthquakes and volcanic eruptions, and being dragged around by gravitational forces makes your rotation somewhat irregular. These fluctuations in Earth’s rotational speed mean that even very accurate clocks, like the atomic clocks used by global timekeeping services, occasionally have to be adjusted slightly to bring them in line with ‘solar time.’”

For most of us, that second of flux is something that (if we even notice it) is irrelevant. But for Google, which may process thousands or even millions of events during that transitional second, this can lead to major problems.

According to Pascoe, “Our systems are engineered for data integrity, and some will refuse to work if their time is sufficiently “wrong.” We saw some of our clustered systems stop accepting work on a small scale during the leap second in 2005, and while it didn’t affect the site or any of our data, we wanted to fix such issues once and for all.”

Google’s solution? Adding what they call a “leap smear,”—injecting code that would effectively “lie” to its own servers during the day that a leap second was taking place. Pascoe again: “We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day.”

Lest you think this was a trivial patch, Google actually developed some serious math to solve the problem, and performed two “smears” (one going back in time, the other pushing into the future) and tested them using about 10,000 servers, comparing “standard atomic time,” their own servers and a variety of public NTP clients.

The result? Google has figured out how halt the ravages of time (at least in this case). For more of the science and math behind the fix, check out the official Google blog post.

Here’s an example of how it looks:

What malware? Produced by whom? Google’s not giving any details there yet, simply blogging:

This particular malware causes infected computers to send traffic to Google through a small number of intermediary servers called “proxies.” We hope that by taking steps to notify users whose traffic is coming through these proxies, we can help them update their antivirus software and remove the infections.

The blog post itself has the fairly innocuous title of “Using data to protect people from malware.”

This is malware so threatening, so menacing that Google does unprecedented above-the-search results warnings, and Google describes it as an exercise in data analysis? How about: “Warning: Your Computer May Be Infected & Here’s How To Fix It.”

The post also doesn’t mention that the malware is restricted to Windows computers, nor does the help page make this clear. Indeed, the “fix” that the help file talks about is to run an anti-virus program. It doesn’t say exactly what malware that software should detect, if any.

The help page does provide, if you drill down, some guidance that your Windows host file will be changed to apparently reference the IP address of 74.125.45.100 along with some others.

Ironically, doing a search for the IP address quickly suggests that Google is concerned about “Windows Protection Suite,” which one site describes as a fake anti-virus software program.

The IP address, by the way, appears to be Google’s own. The program, I’m guessing, is routing the traffic eventually to Google after monitoring it or logging it for whatever reasons it has.

If you get one of these notices on a Windows computer and don’t already run an anti-virus program, well, that’s as good as reason as any. But it would sure be better if Google provided some more details.

Postscript: A Google spokesperson tells me via email, after I asked why the particular malware wasn’t named:

We detected a large number of variants of the malware. As a result, naming is not so straight-forward. From a user’s perspective, it’s more important to understand that their computer is infected and that they should take steps to fix it. You may have noticed that there is a feedback form in our Help Center for people to report what they’ve found, and they can also ask questions about the results.

I also asked if we’d see more warnings like this going forward and was told:

We haven’t displayed this type of warning before, so we can’t say what we’ll do going forward. We came across this particular type of malware in the course of the work that’s described in the blog post, which is why we were able to take action in this case. As I mentioned, we realized we were in a position to use that information to help our users. Who knows if anyone else would have warned them?

The spokesperson also commented:

The title of your post is not quite accurate. The malware doesn’t redirect to Google’s search results, technically speaking. Something like “modifying traffic to its search results” would be more correct.

I’m uncertain, honestly, what else to change the title to. Originally I’d had the title of:

Google Warns Of Malware Changing Its Search Listings

That was clearly incorrect, and I fixed that a few minutes after the original post went up. There is malware that does alter Google’s search results. It’s a common question we get asked here at Search Engine Land, actually — why do my Google results look this odd way? Malware is often to blame.

That’s not what’s happening here. What is happening is unclear. This malware appears to be redirecting to Google itself, not necessarily its search results. But Google’s putting warnings into its search results, which suggests a search results connection of some type.

Bottom line. Malware isn’t new, nor have users of Windows computers been oblivious to it. Indeed, Windows itself will warn you of the need to protect against malware in various ways. I’m pretty sure Windows Defender even ships with Windows 7, or that Windows 7 at least warns you if you don’t have it installed.

Even if Windows Defender doesn’t detect this type of malware, it’s just not uncommon for Windows users to know they need to have anti-virus / malware detection software. It is uncommon, extremely uncommon, for Google to suddenly issue what seems to be an urgent warning about a particular type of malware.

Over at Krebs On Security, they appear to have interviewed the Google engineer who spotted the malware, which does suggest that the malware was indeed altering search results.

Hacking

Matt’s Cutts recently stated on the official Google blog that, for the fifth year in a row, they will be placing a lot of emphasis on hacked sites in 2011. In 2007 Google started scanning sites for malware and removing them from search listings. At the time Google said, “In the past year, the number of sites affected by malware/badware grew from a handful a week to thousands per week.” In August 2009 Google said, “[W]e have seen a large increase in the number of compromised sites since April. The number of entries on our malware list has more than doubled in one year, and we have seen periods in which 40,000 web sites were compromised per week.”

Malware is inserted in sites by hackers looking to build botnets that can then be rented out for criminal purposes. But not all hacking results in malware deployment. Some hackers are black hat SEOs looking to do link building. When Google detects spam links, they can ban the site, or I think more appropriately, label the site as hacked.

This year I had a client suffer this type of hacking. Another SEO performed a site review, and referred the client to me to fix everything that was wrong. Among the items to be repaired were some oddball links that kept appearing in their header and footer. We’d take out the links, and they’d appear again in a few hours. Apparently the server had been compromised and a hacker had uploaded a php file that would deploy the links. Finding this file among the many thousands of files on this ancient (yet highly profitable) website was the first step. Removing the script helped, but to be safe I convinced the client to switch to a better hosting provider, and they’ve had no trouble since.

How can you prevent hacking? Use a good hosting provider and don’t share File Transfer Protocol (FTP) passwords. Use a unique, strong password for each user for each site. When somebody no longer needs access to a site, cancel their FTP account. If possible configure your web server’s firewall to lock down FTP and web hosting control panel access to the IP addresses where your computers are located. This will prevent anybody from getting in, even if they have stolen or guessed a password. Passwords are typically compromised when one of your developers gets a malware infection on their computer. Given enough time and developers, this is very likely to happen.

Backups

Backups are critical. If you get hacked, or more commonly, make a mistake editing your site, you need to be able to go back to a working version. Too many people assume that their hosting provider is taking backups, only to discover that when needed, the backups aren’t helpful. Ask your provider how often they take backups, what they back up, and how long those backups are retained. Some providers take seven days of rolling backups. If you have a problem, you need to discover it within seven days or you are out of luck. Other providers may take a monthly “image” of your virtual private server. Restoring that backup could take your website, database and email boxes back a month—not something you would want to do. Hosting is a commodity business where cutting corners is rewarded with additional profit. Many hosting provider backups are grossly inadequate.

Another reason to have reliable, up-to-date backups is in case you get into a dispute with your hosting provider or web developer—or they suddenly disappear. If you don’t have your own copy of the latest code, your negotiating position will be much more complicated. Yes, you can hire a lawyer and force the other side to hand over your code and data, if they retained it, but why would you want to suffer that delay and expense? Over the last year I’ve had two clients get into this situation, and it cost them a bundle. Your best option is to choose a third party backup provider so that you don’t leave the fox guarding the hen house.

Site Scanning

All those scanning services that tell people your site is safe are nothing more than security theater. Notable security expert Merrick Furst told me that the best scanning available only detects 30% of threats. Most modern threats are polymorphic, which means that the code changes from instance to instance in order to defeat scanning algorithms. Real security requires verifying the files on your server to ensure that none of them have been tampered with. File integrity monitoring (FIM) systems can do that for you, but they require an expert server administrator. Even without such a system you can reduce your risk by clearing cruft files from your server, periodically inspecting to make sure no unexpected files have appeared, and making sure that the latest timestamps on your files match the last time you edited the site.

Parasitic Hosting

Even if you don’t have a high volume site, there is a risk that cybercriminals could abuse your servers as a platform for distributing malware, sending spam, or launching denial of service attacks. Do you have a portfolio of trusty old websites that you don’t pay much attention to? Those are an attractive target for parasitic hosting. The bad guys can have their fun, misusing your server, your brand and your trust. Meanwhile, you suffer the loss as your virtual property becomes blighted and develops a bad reputation. If you have sites and servers running on autopilot, you need to check them periodically to make sure they aren’t being abused. File integrity monitoring can help, or you can inspect server logs to look for suspicious web traffic.

Denial Of Service Attacks

This year I had a client who was repeatedly hit by denial of service attacks emanating from China. The client believed that a competitor was responsible. The site went down repeatedly for days at a time, and eventually the hosting provider, Earthlink, cut off the victim’s hosting service because the attacks were impacting Earthlinks’s data center. My recommended replacement hosting provider was able to fend off the attacks. It pays to use a competent hosting provider so that your site doesn’t get taken down by an unscrupulous competitor. The cost of web site and email disruption is much greater than the cost of buying the best available hosting. When selecting a hosting provider, look for somebody who has a reputation for responding quickly and is technically competent. Hosting is often priced as a commodity service, but not all hosting is the same quality.

PCI Compliance

What this jargon have to do with search marketing? PCI stands for payment card information. If your conversion action is to take somebody’s money, you may be handling payment card information. Deep in the contract between you and your merchant processor, there is probably a clause that says your site must be certified “PCI compliant” by a vendor such as Trustwave, or else you are liable for hundreds of dollars per customer record if there is a data security breach on your site. In other words, if a hacker steals credit card info from your site or database, you will be sued out of existence. To top if off, states have laws that require you to notify their attorney general and every one of your customers in that state if you suffer a data security breach. This recently happened to one of my friends. It cost him $50,000 in legal fees, printing and mailing costs just to send out the required notification letters. The guy couldn’t sleep for months, worried that he was going to get sued for ten times that amount by Visa.

An excellent approach to solving PCI compliance is not to store or handle any credit card information on your site. You may be able to fob the entire problem off to Google Checkout or Paypal. If however, you have an osCommerce cart, XCart, ZenCart or similar site, and you store customer credit card numbers in your cart’s database, you definitely need to start asking questions. I once found an unencrypted database backup file containing thousands of customer credit card numbers, expiration dates and addresses in the top level directory of a site. It was a half-million dollar penalty waiting to happen. Can you afford to run that risk?

The Importance Of Managing Risk

Risk is an unrealized expense, possibly one that could put you out of business. Now would be an excellent time to review your risk exposures and start managing them properly. Your website is a valuable asset, possibly as valuable as your car, home or office building. You probably have an alarm system and insurance on those assets to protect against loss or liability. Shouldn’t you treat your websites with the same level of care?

If we allow the open internet to become overrun with malware and hacked sites, users will flee to the protection of walled gardens. That would be a very bad thing for search marketers and search engines alike. So let’s work together to confront these problems.

Google had malware notifications in the search results since 2007, but now Google is adding a notification for searchers to be aware that the site they may click on is hacked. It is important to note that a hacked site might not have malware on it.

Here is a picture of a hacked notification, which is a hyperlink that reads “This site may be compromised.”

The link will take you to this Google document explaining why the label is on that result and how the webmaster can remove the label.

Google sent out an email to Google Website Optimizer users saying:

Dear Website Optimiser user,

We are writing to inform you of a potential security issue with Website Optimiser. By exploiting a vulnerability in the Website Optimiser Control Script, an attacker might be able to execute malicious code on your site using a Cross-Site Scripting (XSS) attack. This attack can only take place if a website or browser has already been compromised by a separate attack. While the immediate probability of this attack is low, we urge you to take action to protect your site.

We have fixed the bug, and all new experiments are not susceptible. However, any experiments you are currently running need to be updated to fix the bug on your site. Additionally, if you have any Website Optimiser scripts from paused or stopped experiments created before 3 December 2010, you will need to remove or update that code as well.

There are two ways to update your code. You can either stop current experiments, remove the old scripts and create a new experiment, or you can update the code on your site directly. We strongly recommend creating a new experiment as it is the simpler method.

The email goes on to give specific examples on how to modify your current experiments to make sure you do not have malicious code on your site.

At the end of the email, Google apologized, saying:

We’re committed to keeping Website Optimiser secure, and we’re deeply sorry for this issue. We will continue to work hard to prevent future vulnerabilities.

Yours sincerely, Trevor Google Website Optimiser Team

For more information on this XSS issue, see Dave Naylor’s blog.

On the Google URL shortener issue, Twitter is taking care of it and I don’t believe Google has anything to do with it. TechCrunch has a comment from a Twitter representative that reads, “We’re aware and have sent out password resets for affected users. We’ll monitor the situation in case of further iterations.”

Postscript: Google has a new post on this issue at the Google Website Optimizer bug.

Google has added three broad changes to help secure private data going forward:

(1) They appointed a director of privacy, Alma Whitten to work on the engineering and product side. She will build controls to ensure privacy within Googles products and internal daily routines.

(2) Google will train all of their employees on Google’s privacy principles and add additional privacy training and security programs.

(3) Google will be ramping up their compliance procedures. Each project leader will have to maintain a privacy design document for each project they manage. The privacy design document will show how people within and outside Google have access to private data and will be reviewed by managers at Google and independent internal audit team.

As you may remember, Google stopped the cars that were collecting data after learning what type of data the cars were collecting. Google’s co-founder, Sergey Brin said we screwed up and apologized. The type of data collected included security numbers and other very personal information.

Germany wanted Google to turn over the data but Google fought it. In the end, Google ended the wifi street view cars for collecting packet data while driving.

In addition, Google has fired at least two employees for breaching privacy within Google. Some of those stories were pretty disturbing.

Alan Eustace, Senior VP, Engineering & Research of Google added:

Finally, I would like to take this opportunity to update one point in my May blog post. When I wrote it, no one inside Google had analyzed in detail the data we had mistakenly collected, so we did not know for sure what the disks contained. Since then a number of external regulators have inspected the data as part of their investigations (seven of which have now been concluded). It’s clear from those inspections that while most of the data is fragmentary, in some instances entire emails and URLs were captured, as well as passwords. We want to delete this data as soon as possible, and I would like to apologize again for the fact that we collected it in the first place. We are mortified by what happened, but confident that these changes to our processes and structure will significantly improve our internal privacy and security practices for the benefit of all our users.