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.

Barracuda Labs says it studied the four search engines for about two months and reviewed more than 25,000 trending topics and almost 5.5 million search results. The results aren’t good for Google:

Overall, Google takes the crown for malware distribution – turning up more than twice the amount of malware as Bing, Twitter and Yahoo! combined when searches on popular trending topics were performed. Google presents at 69 per cent; Yahoo! at 18 per cent; Bing at 12 per cent; and Twitter at one per cent.

The study also cites an increase in rogue accounts on Twitter this year. The “Twitter Crime Rate” — the percentage of accounts created each month that Twitter later suspends — was 1.67% for the first half of 2010, with a high of 2.38% in June.

This is a topic we’ve written about before, especially where Google is concerned. In April, one report suggested that some “hot topic” searches on Google returned 90% malicious links. On a more general level, I wrote last year about a McAfee study that examined the web’s riskiest search terms.

Postscript, August 4: A Google spokesperson has sent us this unsolicited statement in reply to the study cited above:

Google has been an industry leader in anti-malware research and technology. We actively work to detect and flag sites that serve malware with warning labels in our search results, reacting to the latest trends and monitoring popular search terms. Similar techniques have since been adopted by other major search engines, but these protections do not appear to have been taken into account by this study.

The example used in the post is a search for [tri energy], a phrase that was the hottest search on Google Trends on Friday, April 2nd. On its first check, Zscaler says 90 of the top 100 results were malicious — 86 of which sent users to a phony anti-virus page that tries to install malware.

For its part, Google is well aware of the problem. “Utilizing popular search terms and events to lure users into visiting malicious web pages is not new,” a Google spokesperson tells us. “Using any Google product to serve or host malware is a violation of our product policies. We actively work to detect and flag sites that serve malware, reacting to the latest trends and watching for popular search terms. To do this, we have manual and automated processes in place to enforce our policies.”

One of the common tricks that spammers use is placing malware on what looks like an anti-virus download page; users think they’re downloading helpful software, but they’re actually downloading the opposite. Google says it’s able (and others are, too) to detect these sites more quickly now, and its internal research shows that these fake anti-virus sites have a lifespan of about an hour.

And in fact, the Zscaler post points out that, after rechecking the search results eight hours later, there were still 90 malicious results, but Google had displayed a warning on 87 of them. But if there are so many malicious sites, why bother to show them in the search results at all?

“While attackers can and do generate new malicious websites,” Google says, “it’s more common for legitimate websites to become compromised and then start delivering malware.”

Both Google and Bing offer help to compromised web site owners via their respective webmaster centers.

Last summer, I reported on a McAfee study that detailed the riskiest search terms. In that report, some terms like “lyrics” and “myspace” produced search results pages with 50% malicious links.

Edelman documents how he disabled the Google Toolbar within the preference, then visited a web page and captured how Google was sending browsing data from the toolbar to Google’s servers. Edelman first clicked the “X” icon at the top left of the Google Toolbar. Then he selected “Disable Google Toolbar only for this window,” and clicked “okay.” While in the same window, requested the Whitehouse.gov site. He noticed that his network monitor showing that the Google Toolbar continued to transmit his browsing to its toolbarqueries.google.com server.

Edelman posted a video screen cast documenting this process.

I reached out for Google for a statement a few hours ago. I have yet to receive anything back. If and when I do, I will update this post.

Postscript: Google sent me a statement on this matter, here it is:

To be clear, this is only an issue until a user restarts the browser, and it only affects the currently open tabs for a small number of users.

Specifically it affects those using Google Toolbar versions 6.3.911.1819 through 6.4.1311.42 in Internet Explorer, with enhanced features enabled, who chose to disable Toolbar without uninstalling it. Once the user restarts the browser, the issue is no longer present. A fix that doesn’t require a browser restart is now available on www.google.com/toolbar and in an automatic update to Google Toolbar that we are starting tomorrow.

I wonder if Ben Edelman knew about restarting I.E. would fix the issue and left it out?