Friday, June 26, 2009

[Gd] Spam2.0: Fake user accounts and spam profiles

| More

Official Google Webmaster Central Blog: Spam2.0: Fake user accounts and spam profiles

You're a good webmaster or web developer, and you've done everything you can to keep your site from being hacked and keep your forums and comment sections free of spam. You're now the proud owner of a buzzing web2.0 social community, filling the web with user-generated content, and probably getting lots of visitors from Google and other search engines.

Many of your site's visitors will create user profiles, and some will spend hours posting in forums, joining groups, and getting the sparkles exactly right on the rainbow-and-unicorn image for their BFF's birthday. This is all great.

Others, however, will create accounts and fill their profiles with gibberish, blatherskite and palaver. Even worse, they'll add a sneaky link, a bit of redirecting JavaScript code, or a big fake embedded video that takes your users off to the seediest corners of the web.

Welcome to the world of spam profiles. The social web is growing incredibly quickly and spammers look at every kind of user content on the web as an opportunity for traffic. I've spoken with a number of experienced webmasters who were surprised to find out this was even a problem, so I thought I would talk a little bit about spam profiles and what you might do to find and clean them out of your site.

Why is this important?

Imagine the following scenario:

"Hello there, welcome to our new web2.0 social networking site. Boy, have I got a new friend for you. His name is Mr. BuyMaleEnhancementRingtonesNow, and he'd love for you to check out his profile. He's a NaN-year-old from Pharmadelphia, PA and you can check out his exciting home page at http://example.com/obviousflimflam.


Not interested? Then let me introduce you to my dear friend PrettyGirlsWebCam1234, she says she's an old college friend of yours and has exciting photos and videos you might want to see."


You probably don't want your visitors' first impression of your site to include inappropriate images or bogus business offers. You definitely don't want your users hounded by fake invites to the point where they stop visiting altogether. If your site becomes filled with spammy content and links to bad parts of the web, search engines may lose trust in your otherwise fine site.

Why would anyone create spam profiles?

Spammers create fake profiles for a number of nefarious purposes. Sometimes they're just a way to reach users internally on a social networking site. This is somewhat similar to the way email spam works - the point is to send your users messages or friend invites and trick them into following a link, making a purchase, or downloading malware by sending a fake or low-quality proposition.

Spammers are also using spam profiles as yet another avenue to generate webspam on otherwise good domains. They scour the web for opportunities to get their links, redirects, and malware to users. They use your site because it's no cost to them and they hope to piggyback off your good reputation.

The latter case is becoming more and more common. Some fake profiles are obvious, using popular pharmaceuticals as the profile name, for example; but we've noticed an increase in savvier spammers that try to use real names and realistic data to sneak in their bad links. To make sure their newly-minted gibberish profile shows up in searches they will also generate links on hacked sites, comment spam, and yes, other spam profiles. This results in a lot of bad content on your domain, unwanted incoming links from spam sites, and annoyed users.

Which sites are being abused?

You may be thinking to yourself, "But my site isn't a huge social networking juggernaut; surely I don't need to worry." Unfortunately, we see spam profiles on everything from the largest social networking sites to the smallest forums and bulletin boards. Many popular bulletin boards and content management systems (CMS) such as vBulletin, phpBB, Moodle, Joomla, etc. generate member pages for every user that creates an account. In general CMSs are great because they make it easy for you to deploy content and interactive features to your site, but auto-generated pages can be abused if you're not aware.

For all of you out there who do work for huge social networking juggernauts, your site is a target as well. Spammers want access to your large userbase, hoping that users on social sites will be more trusting of incoming friend requests, leading to larger success rates.

What can you do?

This isn't an easy problem to solve - the bad guys are attacking a wide range of sites and seem to be able to adapt their scripts to get around countermeasures. Google is constantly under attack by spammers trying to create fake accounts and generate spam profiles on our sites, and despite all of our efforts some have managed to slip through. Here are some things you can do to make their lives more difficult and keep your site clean and useful:

  • Make sure you have standard security features in place, including CAPTCHAs, to make it harder for spammers to create accounts en masse. Watch out for unlikely behavior - thousands of new user accounts created from the same IP address, new users sending out thousands of friend requests, etc. There is no simple solution to this problem, but often some simple checks will catch most of the worst spam.

  • Use a blacklist to prevent repetitive spamming attempts. We often see large numbers of fake profiles on one innocent site all linking to the same domain, so once you find one, you should make it simple to remove all of them.

  • Watch out for cross-site scripting (XSS) vulnerabilities and other security holes that allow spammers to inject questionable code onto their profile pages. We've seen techniques such as JavaScript used to redirect users to other sites, iframes that attempt to give users malware, and custom CSS code used to cover over your page with spammy content.

  • Consider nofollowing the links on untrusted user profile pages. This makes your site less attractive to anyone trying to pass PageRank from your site to their spammy site. Spammers seem to go after the low-hanging fruit, so even just nofollowing new profiles with few signals of trustworthiness will go a long way toward mitigating the problem. On the flip side, you could also consider manually or automatically lifting the nofollow attribute on links created by community members that are likely more trustworthy, such as those who have contributed substantive content over time.

  • Consider noindexing profile pages for new, not yet trustworthy users. You may even want to make initial profile pages completely private, especially if the bulk of the content on your site is in blogs, forums, or other types of pages.

  • Add a "report spam" feature to user profiles and friend invitations. Let your users help you solve the problem - they care about your community and are annoyed by spam too.

  • Monitor your site for spammy pages. One of the best tools for this is Google Alerts - set up a site: query along with commercial or adult keywords that you wouldn't expect to see on your site. This is also a great tool to help detect hacked pages. You can also check 'Keywords' data in Webmaster Tools for strange, volatile vocabulary.

  • Watch for spikes in traffic from suspicious queries. It's always great to see the line on your pageviews chart head upward, but pay attention to commercial or adult queries that don't fit your site's content. In cases like this where a spammer has abused your site, that traffic will provide little if any benefit while introducing users to your site as "the place that redirected me to that virus."


Have any other tips to share? Please feel free to comment below. If you have any questions, you can always ask in our Webmaster Help Forum.

Written by Jason Morrison, Search Quality Team
URL: http://googlewebmastercentral.blogspot.com/2009/06/spam20-fake-user-accounts-and-spam.html

Thursday, June 25, 2009

[Gd] Gmail for Mobile HTML5 Series : Cache Pattern For Offline HTML5 Web Applications

| More

Google Code Blog: Gmail for Mobile HTML5 Series : Cache Pattern For Offline HTML5 Web Applications

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow-up blog posts. This week, I'll talk about the cache pattern for building offline-capable web applications.

I recently gave a talk (preserved YouTube here) about the cache pattern and the Web Storage Portability Layer (WSPL) at Google I/O. It was exciting getting to give a talk at the Moscone Center as previously I had only ever been one of the audience members. The conference seemed to go by in a blur for me as I was sleep-deprived from getting the WSPL to "just good enough" to actually be released. (And some ofyou have already pointed out that I missed several bugs.) In my talk, I provided a general overview of the cache pattern and this post expands on the handling of hit determination and merging server and local changes.

The cache pattern is a design pattern for building an offline-capable web application. We implemented the cache pattern to make Gmail for Mobile tolerant of flaky wireless connections but the approach is generally applicable. Here's how it works. Consider a typical AJAX application. As shown in the diagram, we have a web application with a local model, view and controllers. The user interacts with theapplication and the controller dispatches XmlHttpRequests (XHRs for short) to the server. The server sends asynchronous requests to the application which it inserts into the model.

As shown in this next diagram, in the cache pattern, we insert a cache between the application and the server. Having done so, many requests that would otherwise require a round-trip to the network.

A software cache like this one shares a great deal conceptually with hardware caches. When designing the cache used in Gmail for mobile, we used this similarity to guide our design. For example, to keep our cache as simple as possible, we implemented a software equivalent to a write-through cache with early forwarding and LRU eviction. The cache pattern in general (and consequently our implementation) has four important data flows as shown in the diagram.

  • Cached content bound for the UI.
  • Changes made to the cache by the user in the UI. These need to be both reliably sent to the server and updated locally in the cache so that reads from the cache for UI updates show the state including user changes.
  • The changes recorded in the cache need to be sent upstream to the server as the network connection is available.
  • Changes made to the server (like email delivery in the case of Gmail) need to be merged into the contents of the cache.
As shown in the diagram we also need a place to actually write the data. We use the WSPL library to write a cache implementation portable across both Gears and HTML5 databases.

To actually implement these four data flows, we need to decide on a hit determination mechanism, a coherency strategy and a refresh approach.

Hit Determination

At its heart, a cache is a mapping from keys to values: the UI invokes the cache with a key and the cache returns the corresponding element. While this sounds pretty simple, there is an additional source of complexity if the application wants to provide the user with summary listings of some subset of all values available from the server. To provide this feature, the cache needs to contain not only "real" data values but additional "index" values that list the keys (and possibly user-visible summaries) for "data" values. For example, in Gmail for mobile, the cache stores conversations as its "real" data values and lists of conversations (such as the Inbox in Gmail for Mobile) as its "index" values. Keys for index values are computed specially to record what subset of the complete index is cached locally. For example, in Gmail for Mobile, while a user's Inbox may contain thousands of conversations, the cache might contain an index entry whose data values lists metadata for only conversations 1000 through 1100. Consequently, Gmail for Mobile's cache extends keys with the cached range so that a request for metadata for conversations 1101 through1110 would be considered a cache miss.

Coherency and Refresh

Perhaps the most complex aspect of the cache implementation is deciding how to get updated content from the server and how to merge server updates with changes made locally. A traditional hardware cache resolves this problem by only letting one processor modify its a cache at a time and have the memory broadcast any changes to all the other caches in the system. This approach cannot work here because the Gmail server can't connect to all of its clients and update their state. Instead, the approach we took for Gmail for Mobile was for the client device regularly poll the server for alterations.

Polling the server for changes such as new email or the archiving of email by the same user from a different device implies a mechanism for merging local changes with server side changes. As mentioned above, Gmail for Mobile is a write-through cache. By keeping all of the modifications to the cache in a separate queue until they have been acknowledged, they can be played back against updates delivered from the server so that the cache contains the merge of changes from the server and the local user. The following diagram shows the basic idea:


The green box in the diagram shows the contents of the cache's write buffer changing over time and the cloud corresponds to the requests in-flight to the server with time advancing from left to right in the diagram. The function names shown in the diagram are from the simplenotes.js
example file in the Web Storage Portability Layer distribution. Here, the user has applied some change [1] and the cache has written it to the write buffer and has then requested new content resulting in query [Q]. The cache prefixes the outstanding actions from the write buffer to the query. Action [1] is marked as needing a resend on some sort of network failure.

Later, the user makes change [2] to the UI which causes the cache to append it to the write buffer in the applyUIChange call. Later still, another query is made and so, the cache sends [1][2][Q] to the server. In the mean time, the user makes yet another change [3]. This is written to the write buffer. Once changes [1] and [2] are acknowledged by the server along with the new cache contents for query [Q], changes [1] and [2] are removed from the write buffer. However, to keep the cache's state reflecting the user's changes, change [3] is applied (again) over top of the result for [Q].

Simplifying the implementation of this reapplication stage is the most important benefit of implementing a write-through cache. By separating the changes from the state, it becomes much easier to reapply the changes to the cache once the server has delivered new content to the cache. As discussed in a previous post, the use of SQL triggers can greatly improve database performance. Whether updating or re-updating, triggers are a great way to make the application of changes to the cache much more efficient.

Cached Content To the UI

The first of the four data flows is delivering content to the UI is reasonably easy: query the cache for the desired content and when the query completes, forward the request to the UI. If you look at the getNoteList_ function from the simplenotes.js example code included in the WSPL distribution, you'll see that the delivering cached content to the UI has the following basic steps:
perform hit determination: deciding if the requested cache contents are actually in the cache.
  • create a database transaction, and while in the transaction
    • query the database for the desired key
    • accumulate the results
  • then outside of the transaction, return the result to the UI.
Changes From The UI

The second flow (applyUiChange) is recording changes made by the user to the write buffer. It has a very similar structure
  • create a database transaction, and while in the transacation
    • write the change to the write buffer
    • wait for a trigger to update the state of the cache.

Updates Bound For The Server

As discussed above, once the changes have been written to the write buffer, they still have to be sent to the server. This happens by prepending them to queries bound for the server. The fetchFromServer from the example is responsible for this. As might be familiar by now, the flow is

  • create a database transaction and while in the transaction
    • query the write buffer for all the entries that need to be sent to the server
    • accumulate the entries
  • then outside the transaction, send the combination of changes and query to the server

Changes From The Server

Finally, we need to merge the changes from the server into the cache as is done in the insertUpdate method from the example. Here the flow is as follows:

  • create a database transaction and while in the transaction
    • update the directory
    • write the new content into the cache
    • touch the changes in the write buffer that need to be re-applied to the cache
    • wait for the trigger to complete its update
  • then, outside of the transaction, send the response to the UI if it was satisfying a cache miss.
That's a brief intro to the cache architecture as found in Gmail for mobile. We're continuing to improve our implementation of this basic architecture to improve both the performance and robustness of Gmail for mobile. Please stay tuned for follow on blog posts.

Previous posts from Gmail for Mobile HTML5 Series
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance

By Robert Kroeger, Software Engineer, Google Mobile Team
URL: http://googlecode.blogspot.com/2009/06/gmail-for-mobile-html5-series-cache.html

[Gd] [Language][Update] - New Transliteration Languages

| More

Google AJAX API Alerts: [Language][Update] - New Transliteration Languages

The Transliteration API now supports Bengali, Gujarati, Marathi and Nepali.
URL: http://ajax-api-alerts.blogspot.com/2009/06/languageupdate-new-transliteration.html

[Gd] Introducing Android 1.5 NDK, Release 1

| More

Android Developers Blog: Introducing Android 1.5 NDK, Release 1

Many of you have been asking for the ability to call into native code from your Android applications. I'm glad to announce that developers can now download the Android Native Development Kit from the Android developer site.

As you know, Android applications run in the Dalvik virtual machine. The NDK allows developers to implement parts of these applications using native-code languages such as C and C++. This can provide benefits to certain kinds of applications.

The NDK provides:

  • a set of tools and build files used to generate native code libraries from C and C++ sources
  • a way to embed the corresponding native libraries into application packages files (.apks) that can be deployed on Android devices
  • a set of native system headers and libraries that will be supported in all future releases of the Android platform, starting from Android 1.5 documentation, samples and tutorials

This release of the NDK supports the ARMv5TE machine instruction set and provides stable headers for:

  • libc, the standard C library
  • libm, the standard math library
  • the JNI interface
  • libz, the common ZLib compression library
  • liblog, used to send logcat messages to the kernel

Keep in mind that using the NDK will not be relevant for all Android applications. As a developer, you will need to balance its benefits against its drawbacks, which are numerous! Your application will be more complicated, have reduced compatibility, have no access to framework APIs, and be harder to debug. That said, some applications that have self-contained, CPU-intensive operations that don't allocate much memory may still benefit from increased performance and the ability to reuse existing code. Some examples are signal processing, intensive physics simulations, and some kinds of data processing.

For any questions on the NDK, please join the Android NDK forum.

Have fun.

URL: http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html

[Gd] Share Your Work in the Wave Samples Gallery

| More

Google Wave Developer Blog: Share Your Work in the Wave Samples Gallery

In the last three weeks, we've seen an amazing amount of activity in the Wave APIs community, with developers churning out new robots and gadgets by the dozens. Some developers have created waves listing their demos, other developers have posted in the forum, and others have created whole domains listing extensions. We wanted to make one central place for developers to share their work - and for people without Sandbox access to get a glimpse of their work - so we created the Wave Samples Gallery. The gallery is based off the code that powers the Youtube, GWT, and App Engine project galleries, but is customized for the Wave APIs.



If you're a Wave developer looking to show off your extension, you can sign in and fill out a form to submit your sample. After going through a moderation queue(we have to look out for evil robots!), your extension will appear on the front page and you can edit its information at any time.





If you're a Wave developer looking for inspiration, you can browse through recent submissions or filter by the language or API used. For each sample listed, you can check out screenshots, click through to a sample Wave (if you have sandbox access), view the source code, and read the technical details.







Currently, the gallery is mostly Googler-created submissions (denoted by a "G" badge), but the featured sample, Napkin Gadget, is from an Australian developer that attended our Google Wave APIs Day in Sydney. It's a collaborative Flash doodling app, and Marcin has open sourced the Gadget XML as well as an ActionScript <-> JavaScript bridge. Follow his lead, and let the world benefit from your code as well!






Posted by Pamela Fox, Developer Relations
URL: http://googlewavedev.blogspot.com/2009/06/share-your-work-in-wave-samples-gallery.html

Wednesday, June 24, 2009

[Gd] AdSense for Mobile Applications Beta

| More

Google Code Blog: AdSense for Mobile Applications Beta

Are you developing free iPhone or Android applications? With our new beta product - AdSense for Mobile Applications, you can monetize your mobile applications by showing contextually targeted ads and/or placement targeted ads alongside your application content. We provide you with iPhone and Android SDKs and example applications that request and display AdSense ads. Our SDKs also support DoubleClick ads.

You can show 320x50 text and image ads linked to HTML webpages in your application. These ads are targeted to the keywords that you send us in the AdSense (or DoubleClick) ad request. The keywords must be relevant to your application content. If your application content is loaded from a webpage that is customized for iPhones and Android handsets, then you can also send us the webpage URL for us to target ads. The ads may also be placement targeted which means an advertiser can specifically target to your application.

Our iPhone SDK is compatible with iPhone OS 3.0, and our Android SDK is compatible with Android 1.5 SDK. The SDKs include a library that can be linked in to your application which exposes methods to fetch and show ads. You must place a maximum of one ad per screen at the top or bottom (see the screenshot from the Backgrounds iPhone application). When a user clicks on the ad in your application, you can choose whether the user should view the advertiser's website in iPhone Safari or a full-screen UIWebView on the iPhone. For Android applications, our API defaults to opening the advertiser's website in the native browser.

To get started with monetizing your iPhone or Android application, sign up today on the AdSense for Mobile Applications website. We can't wait to have you join our beta network!


By Jennifer Lin, Software Engineer, Google Mobile Team
URL: http://googlecode.blogspot.com/2009/06/adsense-for-mobile-applications-beta.html

[Gd] Tell us what you think!

| More

Official Google Webmaster Central Blog: Tell us what you think!

(Cross-posted on the Google Product Ideas Blog)

The Webmaster Central team does our best to support the webmaster community via Webmaster Tools, the Webmaster Central Blog, the Webmaster YouTube Channel, Help Center, our forum, and a fellow named Matt Cutts.

If you've got ideas and suggestions for Webmaster Central - features you want, things we can do better - tell us. From now until Friday, July 24, 2009, Product Ideas for Webmaster Central will be open for feedback. Every suggestion you add will be seen not only by the Webmaster Central team, but by other users and webmasters. We'll review every submission, and we'll update you regularly with our progress and feedback.

The more feedback the better, so get started now.

Posted by Sagar Kamdar, Product Manager, Webmaster Tools
URL: http://googlewebmastercentral.blogspot.com/2009/06/tell-us-what-you-think.html

[Gd] By James A. Whittaker Let me be clear that these plague posts

| More

Google Testing Blog: By James A. Whittaker
Let me be clear that these plague posts

By James A. Whittaker

Let me be clear that these plague posts are specifically aimed at pointing out problems in testing. I'll get around to the lore and the solutions afterward. But keep up the debate in the comments, that's what this blog is all about.

The plague of repetitiveness

If aimlessness is the result of ‘just doing it’ then repetitiveness is the result of ‘just doing it some more.’ Pass after pass, build after build, sprint after sprint, version after version we test our product. Developers perform reviews, write unit tests and run static analyzers. But we have little insight into this effort and can't take credit for it. Developers test but then we retest. We can’t assume anything about what they did so we retest everything. As our product grows in features and bug fixes get applied, we continue our testing. It isn’t long until new tests become old tests and all of them eventually become stale.


This is Boris Beizer’s pesticide paradox. Pesticide will kill bugs, but spray the same field enough times with the same poison and the remaining bugs will grow immune. Rinse and repeat is a process for cleaning one’s hair, not testing software. The last thing we need is a build full of super-bugs that resist our ‘testicide.’ Even worse, all that so-called successful testing will give us a false sense of thoroughness and make our completeness metrics a pack of very dangerous lies. When you aren't finding bugs it's not because there are no bugs, it's the repetition that's creating the pesticide paradox.


Farmers know to adjust their pesticide formula from time to time and also to adjust the formula for the specific type of pest they expect in their fields. They do this because they understand the history of pesticide they used and know they can't get by with brute force repetition of they same old poison. Testers must pay attention to their test results too and watch for automation that isn’t adding value. A healthy injection of variation into automation is called for. Change the order of tests, change their data source, find new environments, modify input values do something the bugs aren’t prepared for.

URL: http://googletesting.blogspot.com/2009/06/by-james.html

[Gd] Dev update: Bug fixes

| More

Google Chrome Releases: Dev update: Bug fixes


Google Chrome 3.0.190 has been released to the Dev channel (Mac: 190.0, Windows: 190.1, Linux: 190.2).

Highlights in this release:
  • Mostly bug and crash fixes.
  • Linux: Fixed the browser crashing because of missing fonts. (Issue 13007)
  • Lots of progress filling in missing features on Mac and Linux. Random samples:
    • Linux: HTTP authentication now works. 
    • Linux: Render the contents of tabs while dragging.
    • Linux: You can import and export bookmarks. 
    • Mac: You can download more than one item in a tab.
    • Mac: A (preliminary) download shelf at the bottom of the window shows your downloads.
    • Mac: Added the Restore Closed Tabs item to the File menu.
  • The --enable-monitor-profile flag converts web pages from sRGB to your current default monitor profile. It does not handle embedded color profiles in images. (Issue 4938)
  • The 'Print selection' option on the Print dialog works on Windows. (Issue 1682)
Known issues:
  • You cannot drag bookmarklets (javascript: URLs) to the bookmarks bar. (Issue 12290)
  • When you install an extension, two separate toolstrips appear.  The problem will go away when you restart the browser. (Issue 14941)

More details are available in the release notes and the log of all revisions.

You can find out about getting on the Dev channel here: http://dev.chromium.org/getting-involved/dev-channel.

If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry.

Mark Larson
Google Chrome Program Manager
URL: http://googlechromereleases.blogspot.com/2009/06/dev-update-bug-fixes.html

[Gd] Developer Tools for Google Chrome

| More

Chromium Blog: Developer Tools for Google Chrome

Since the initial launch of Google Chrome back in September we have had the Elements and Resources tabs of WebKit's Inspector available. We are now ready to present Inspector's Scripts and Profiles panels built on top of the V8 engine providing web developers with full-featured Javascript debugger and sample-based profiler in the dev channel release of Google Chrome. We are also re-introducing the Elements and Resources tabs running out of process for better robustness, security and support for the new debugger and profiler setup.

You can invoke new developer tools by selecting "JavaScript console" from the Developer menu (or using Ctrl+Shift+J). For example, running the statistical profiler on the V8 benchmark suite (below screenshot) will give exact information on the actual code execution as the data is generated straight from running the optimized code from V8.


As with the rest of Google Chrome, the developer tools are open source and built upon WebKit and in particular WebKit's Inspector. We would love to get feedback - both in terms of bugs reports and feature requests - on the Chromium public issue tracker. Or even better yet, we would love to get contributions to improving developer tools further in WebKit and Google Chrome.

Posted by Yury Semikhatsky, Software Engineer
URL: http://blog.chromium.org/2009/06/developer-tools-for-google-chrome.html

[Gd] Watch out for your .yu domain!

| More

Official Google Webmaster Central Blog: Watch out for your .yu domain!

Are you the owner of a .yu domain? Then you might have heard the news: as of September 30, all .yu domains will stop working, regardless of their renewal date. This means that any content you're hosting on a .yu domain will no longer be online. For those of you who would still like to have your site online, we've prepared some recommendations to make sure that Google keeps crawling, indexing, and serving your content appropriately.
  • Check your backlinks. Since it won't be possible to set up a redirection from the old .yu domain to your new one, all links pointing to .yu domains will lead to dead ends. This means that it will be increasingly difficult for search engines to retrieve your new content. To find out who is linking to you, sign up with Google Webmaster Tools and check the links to your site (you can also download this list as a "comma separated value" -- .csv -- file for ease of use). Then read through the list for sites that you recognize as important and contact their webmasters to make sure that they update their links to your new website.
  • Check your internal links. If you are planning to simply move your content in bulk from the old to the new site, make sure that the new internal navigation is up to date. For example, if you are renaming pages on your site from "www.example.yu/home.htm" to "www.example.com/home.htm" make sure that your internal navigation reflects such changes to prevent broken links.
  • Start moving the site to your new domain. It's a good idea to start moving while you can still maintain control of your old domain, so don't wait! As mentioned in our best practices when moving your site, we recommend starting by moving a single directory or subdomain, and testing the results before completing the move. Remember that you will not be able to keep a 301 redirection on your old domain after September 30, so start your test early.

While you're moving your site, you can test how Google crawls and indexes your new site at its new location by submitting a Sitemap via Google Webmaster Tools. Although we may not crawl or index all the pages listed in each Sitemap, we recommend that you submit one because doing so helps Google understand your site better. You can read more on this topic in our answers to the most frequently asked questions on Sitemaps. And remember that for any question or concerns we're waiting for you in the Google Webmaster Help Forum!

Written by Luisella Mazza, Search Quality Senior Analyst
URL: http://googlewebmastercentral.blogspot.com/2009/06/watch-out-for-your-yu-domain.html

Tuesday, June 23, 2009

[Gd] Let's make the web faster

| More

Official Google Webmaster Central Blog: Let's make the web faster

(Cross-posted on the Official Google Blog and the Google Code Blog)

From building data centers in different parts of the world to designing highly efficient user interfaces, we at Google always strive to make our services faster. We focus on speed as a key requirement in product and infrastructure development, because our research indicates that people prefer faster, more responsive apps. Over the years, through continuous experimentation, we've identified some performance best practices that we'd like to share with the web community on code.google.com/speed, a new site for web developers, with tutorials, tips and performance tools.

We are excited to discuss what we've learned about web performance with the Internet community. However, to optimize the speed of web applications and make browsing the web as fast as turning the pages of a magazine, we need to work together as a community, to tackle some larger challenges that keep the web slow and prevent it from delivering its full potential:
  • Many protocols that power the Internet and the web were developed when broadband and rich interactive web apps were in their infancy. Networks have become much faster in the past 20 years, and by collaborating to update protocols such as HTML and TCP/IP we can create a better web experience for everyone. A great example of the community working together is the HTML5 protocol. With HTML5 features such as AppCache, developers are now able to write JavaScript-heavy web apps that run instantly and work and feel like desktop applications.

  • In the last decade, we have seen close to a 100x improvement in JavaScript speed. Browser developers and the communities around them need to maintain this recent focus on performance improvement in order for the browser to become the platform of choice for more feature-rich and computationally-complex applications.

  • Many websites can become faster with little effort, and collective attention to performance can speed up the entire web. Tools such as Yahoo!'s YSlow and our own recently launched Page Speed help web developers create faster, more responsive web apps. As a community, we need to invest further in developing a new generation of tools for performance measurement, diagnostics, and optimization that work at the click of a button.

  • While there are now more than 400 million broadband subscribers worldwide, broadband penetration is still relatively low in many areas of the world. Steps have been taken to bring the benefits of broadband to more people, such as the FCC's decision to open up the white spaces spectrum, for which the Internet community, including Google, was a strong champion. Bringing the benefits of cheap reliable broadband access around the world should be one of the primary goals of our industry.
To find out what Googlers think about making the web faster, see the video below. If you have ideas on how to speed up the web, please share them with the rest of the community. Let's all work together to make the web faster!



Posted by Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering
URL: http://googlewebmastercentral.blogspot.com/2009/06/lets-make-web-faster.html

[Gd] Let's make the web faster

| More

Google Code Blog: Let's make the web faster

From building data centers in different parts of the world to designing highly efficient user interfaces, we at Google always strive to make our services faster. We focus on speed as a key requirement in product and infrastructure development, because our research indicates that people prefer faster, more responsive apps. Over the years, through continuous experimentation, we've identified some performance best practices that we'd like to share with the web community on code.google.com/speed, a new site for web developers, with tutorials, tips and performance tools.

We are excited to discuss what we've learned about web performance with the Internet community. However, to optimize the speed of web applications and make browsing the web as fast as turning the pages of a magazine, we need to work together as a community, to tackle some larger challenges that keep the web slow and prevent it from delivering its full potential:
  • Many protocols that power the Internet and the web were developed when broadband and rich interactive web apps were in their infancy. Networks have become much faster in the past 20 years, and by collaborating to update protocols such as HTML and TCP/IP we can create a better web experience for everyone. A great example of the community working together is the HTML5 protocol. With HTML5 features such as AppCache, developers are now able to write JavaScript-heavy web apps that run instantly and work and feel like desktop applications.

  • In the last decade, we have seen close to a 100x improvement in JavaScript speed. Browser developers and the communities around them need to maintain this recent focus on performance improvement in order for the browser to become the platform of choice for more feature-rich and computationally-complex applications.

  • Many websites can become faster with little effort, and collective attention to performance can speed up the entire web. Tools such as Yahoo!'s YSlow and our own recently launched Page Speed help web developers create faster, more responsive web apps. As a community, we need to invest further in developing a new generation of tools for performance measurement, diagnostics, and optimization that work at the click of a button.

  • While there are now more than 400 million broadband subscribers worldwide, broadband penetration is still relatively low in many areas of the world. Steps have been taken to bring the benefits of broadband to more people, such as the FCC's decision to open up the white spaces spectrum, for which the Internet community, including Google, was a strong champion. Bringing the benefits of cheap reliable broadband access around the world should be one of the primary goals of our industry.
To find out what Googlers think about making the web faster, see the video below. If you have ideas on how to speed up the web, please share them with the rest of the community. Let's all work together to make the web faster!



Posted by Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering

(Cross-posted on the Official Google Blog, and the Google Webmaster Central Blog)
URL: http://googlecode.blogspot.com/2009/06/lets-make-web-faster.html

[Gd] Why Enterprise Software Provider Atlassian Chose OpenSocial

| More

OpenSocial API Blog: Why Enterprise Software Provider Atlassian Chose OpenSocial

Hi, I'm Mark Halvorson the "Chief Imagineer" at Atlassian Software. Whenever I tell people my title it is usually received in one of two ways - a chuckle and a blank stare, or for those in the know some comment about Walt Disney. No, I don't make rides for an amusement park, but I do get to imagine inventive ways to combine thorny, enterprise challenges with some of the exciting things happening on the consumer web. That is why I'm particularly excited to blog in this forum about how Atlassian is bringing OpenSocial to the Enterprise.

Enterprise, meet OpenSocial

Much like "Imagineer" makes you think Walt Disney when you hear OpenSocial, you are likely thinking: Orkut, MySpace, and other Internet social networks. When we heard OpenSocial we thought: now there's some cool technology we can use to bring our portfolio closer together, and closer to lots of great stuff on the Internet.

Atlassian is a seven-year young software company, hailing from Australia, and building collaboration and productivity tools for developers and teams. Many of you may of come across two of our better known products: JIRA, an issue tracker, and Confluence, an enterprise wiki. The rest of the portfolio includes a series of developer tools: FishEye, for exploring source code on the web; Crucible, for peer code review; Bamboo, a continuous integration server; and Clover, for test coverage analysis. We also offer Studio, which combines several of these products into a hosted integrated development suite.

Development is a social activity

Development is social. Developers work in teams, often with other non-developers like product managers and technical writers. Those teams work together on a variety of shared objects: specifications, tasks, documentation, source code, builds and projects. Each of those shared objects generate lots of activity: comments, subtasks, notifications of changes and edits, build failures, code commits. These teams use lots of different tools and systems: wikis, bug trackers, build automation systems, source code repositories. That's a huge internal social network. People working with people, people working with systems, and systems working with systems - a river of activity that needs to funnel to the people who care about it most. Our mission is to help developers collaborate and communicate easier, and in the process help them write higher quality code faster.

Okay, so why OpenSocial?

With eight products that support various parts of the development process, each with their own dashboard, and each spitting off data and activity that the others could benefit from, OpenSocial gave us an inventive, proven integration pattern: gadgets . We've embraced OpenSocial gadgets as a method of integration between our own products and between other enterprise software, and we're using OpenSocial gadgets as a mechanism to inject functionality and information from our products into other OpenSocial-compliant containers on the Internet, like Gmail or iGoogle.

JIRA 4.0 will be the first OpenSocial container in our portfolio to ship. JIRA has implemented OpenSocial through Shindig as a series of Atlassian plugins, which we call the Atlassian Gadgets plugins. JIRA produces Gadgets that can be displayed by other OpenSocial-compliant containers, including iGoogle and Gmail, and authentication between Gadget producers and consumers is handled through OAuth. We're excited about the possibilities. JIRA dashboards can now quickly assemble build status from Bamboo, project updates from Confluence, assigned code reviews from Crucible, all in the context of the issues and tasks assigned to a developer in the context of a JIRA project. Are you a team lead, and spend most of your time in Gmail? No problem, take all of that same information and park it there, so it's right alongside your inbox.

We've launched a little site that talks more about what we're doing at http://www.atlassian.com/opensocial. You can also follow us on twitter http://twitter.com/atlassian. I hope to do more blogging here about things we learn and cool stuff we're experimenting with. In the meantime, here's short video of how a dev manager, who may live in Gmail, can file issues and track the state of projects and builds using Atlassian Gadgets in Gmail.



Posted by Mark Halvorson, Chief Imagineer, Atlassian Software Team
URL: http://blog.opensocial.org/2009/06/why-enterprise-software-provider.html

[Gd] AdWords API v2009 Sandbox Update

| More

AdWords API Blog: AdWords API v2009 Sandbox Update

We are making major updates to the v2009 Sandbox environment starting today and continuing throughout the week. Because of these changes, the v200902 Sandbox environment will be unavailable. We will post more information about what's new in the v2009 Sandbox environment once the work is complete--please stay tuned, and apologies for the downtime.

The v13 Sandbox environment should remain functional throughout this process.

-The AdWords API Team
URL: http://adwordsapi.blogspot.com/2009/06/adwords-api-v2009-sandbox-update.html

Monday, June 22, 2009

[Gd] [Language][Update] - Persian added to the Language enum

| More

Google AJAX API Alerts: [Language][Update] - Persian added to the Language enum

URL: http://ajax-api-alerts.blogspot.com/2009/06/languageupdate-persian-added-to.html

[Gd] Webmaster Central YouTube update for June 15th - 19th

| More

Official Google Webmaster Central Blog: Webmaster Central YouTube update for June 15th - 19th

Want to know what's new on the Webmaster Central YouTube channel? Here's what we've uploaded in the past week:

Maile Ohye gave a webmaster-focused presentation about Product Search.

Matt Cutts answered a new question each day from the Grab Bag:
To get you started on watching this latest batch of videos, here's Matt's answer about directories and paid links:



Feel free to leave comments letting us know how you liked the videos, and if you have any specific questions, ask the experts in the Webmaster Help Forum.

Posted by Michael Wyszomierski, Search Quality Team
URL: http://googlewebmastercentral.blogspot.com/2009/06/webmaster-central-youtube-update-for_22.html

[Gd] Introducing the Virtual Keyboard API

| More

Google AJAX APIs Blog: Introducing the Virtual Keyboard API

It is often difficult for Internet users to input text in many non-Latin script-based languages for a variety of reasons. The correct keyboard layout may not be installed on the computer they're using - sometimes such a layout may not be well developed or widely available. This poses a challenging problem for web developers because there is no way they can ensure that their users have access to this very basic input technology. Our Transliteration API can help, but requires that the user know multiple languages.

Right on the heels of introducing support for translating Persian (Farsi), we've added a new Virtual Keyboard API into the Google AJAX Language API to further assist with text input. With this, developers can help their users input text without relying on the right software being installed on the computer they happen to be using.

It couldn't be easier to get this on your page. Simply load the right package:

google.load("elements", "1", {
packages: "keyboard"
});

Then create a keyboard, specifying the keyboard layout and text field to bind to:
var kbd = new google.elements.keyboard.Keyboard(
[google.elements.keyboard.LayoutCode.Arabic],
['myTextArea']);

And here's what it looks like:

This gives you the control to provide a better user experience, even for multilingual websites. By creating multiple keyboards with different layouts, each text field can be bound to the appropriate keyboard - and the user will see only the keyboard attached to whichever text field has the focus.

But don't take my word for it - check out a sample for yourself. Notice that in addition to allowing users to click on the virtual keyboard, it also temporarily transforms the key assignments on their physical keyboard, allowing rapid typing for those users accustomed to a given layout.

With this initial release, we are launching 5 language layouts. They are:

  • Arabic (العربية)
  • Hindi (हिन्दी)
  • Polish (Polski)
  • Russian (Русский)
  • Thai (ไทย)


We plan to roll out support for more keyboard layouts in the future. But in the meantime, read through the class reference and see the rest of the Code Playground samples.

After you've had time to experiment, let us know what you think and which other layouts you'd like to see. Feedback is always welcome in our support forum and IRC channel.

URL: http://googleajaxsearchapi.blogspot.com/2009/06/introducing-virtual-keyboard-api.html

[Gd] Introducing the Virtual Keyboard API

| More

Google Code Blog: Introducing the Virtual Keyboard API

Inability to input text in native language has been a problem for many non-latin script based languages. This may happen for many reasons. Sometimes, users do not have the keyboard layout for their native language installed in the system they happen to be using (for example, a tourist using an internet cafe in a foreign country). Sometimes, such a keyboard layout is not well developed or not widely available. It is worse for web developers because there is no way they can ensure that their users have access to this very basic input technology.

To address this issue, today, we added Virtual Keyboard API into the Google AJAX Language API. With this API, developers can help their users to input text, regardless if they have the native keyboard layout installed in their Operating Systems or not.


Pic 1: Russian Virtual Keyboard layout

Another advantage is the ability to provide a better user experience for multilingual web sites. For example, on a Russian/Thai bilingual dictionary editing web site, users would type in Russian in the header, and then see a Thai description. With the Virtual keyboard API, developers can load a Russian virtual keyboard layout and bind with all the Russian text fields, and load a Thai virtual keyboard layout and bind them to Thai fields. The Virtual Keyboard API then will automatically swap to the corresponding keyboard layout depending upon the user action.

Sometimes users may not be familiar with the key assignment of their keyboard layout. Virtual keyboard also shows the key assignment inside the page to allow users to input text by either pressing key or by clicking mouse on the virtual onscreen layout.

With this initial release, we are launching 5 language layouts. These are: Arabic, Hindi, Polish, Russian, and Thai.

We plan to roll out support for more keyboard layouts in the future. You can find more details by reading through the class reference and trying the Code Playground samples. Feedback is always welcome in our support forum and IRC channel.

By Manish Bhargava and Frank Tang, Google Internationalization Team
URL: http://googlecode.blogspot.com/2009/06/introducing-virtual-keyboard-api.html

[Gd] [Language][New] - Virtual Keyboard API Added

| More

Google AJAX API Alerts: [Language][New] - Virtual Keyboard API Added

The Virtual Keyboard API was added to the Language APIs. Learn more here: http://googleajaxsearchapi.blogspot.com/2009/06/introducing-virtual-keyboard-api.html
URL: http://ajax-api-alerts.blogspot.com/2009/06/languagenew-virtual-keyboard-api-added.html

[Gd] The 7 Plagues of Software Testing

| More

Google Testing Blog: The 7 Plagues of Software Testing

By James A. Whittaker

Yes I am going to be speaking at GTAC, thanks for asking. Frankly, I can't wait. I spoke at a Swiss testing conference and at the University of Zurich a couple years ago and I enjoyed the area and the people a lot. Excellent food, good beer and lots of cool European history and quaint back streets to wallow in. I hope to see you there.

Speaking of speaking, I just finished giving my first internal tech talk this past week. I spoke about the 7 Plagues of Software Testing and received a lot of input from Googlers about them. I'm encouraged enough that Googlers found them thought provoking that I've decided to broaden the conversation by posting them here as well. My plan at GTAC is to give you details on how Google is addressing these plagues in our own testing and hopefully you'll be willing to share yours as well. One plague per post lest this blog be quarantined ...


The Plague of Aimlessness


Lore. It’s more than just a cool word. It conjures up a sorcerous image in one’s mind of ancient spell books and learned wizards with arcane and perilously attained knowledge.


And it’s exactly what we lack in software testing. Testing lore? Are you kidding me? Where is it? Who’s bogarting it? Can I have a hit?


The software testing industry is infected with the plague of aimlessness. We lack lore; we lack a body of knowledge that is passed from wizard to apprentice and written down in spell books for the industrious to study. Our apprentices are without their masters. We must all reinvent the wheel in the privacy of our offices only to have other testers the world over reinvent it in theirs.


I suggest we stop this nonsense. Testing is far too aimless. We test because we must or our manager tells us to do so. We automate because we can or because we know how to, not because it is part of some specific and proven strategy and certainly not because our lore dictates it. Is there a plan or some documented wisdom that guides our testing or are we just banging on the keyboard hoping something will fail? Where are the testing spell books? Surely the perilously attained knowledge of our tester forebears is something that we can access in this age of readily available information?


When a hunter makes a kill, they remember the terrain and circumstances. They pass this knowledge on to their successors. Over time they understand the habits of their prey and the collective knowledge of many hunters makes the job of future hunters far easier. When you see this terrain, you can expect game to behave in this manner. Can we say the same of testing? How well do we learn from each other? Do our ‘eureka moments’ get codified so that future testers will not have to suffer the aimless thrashing that we suffered? Can we say when you see functionality like that, the best way to test it is like this?


The plague of aimlessness is widespread. The need for testing lore is acute. Nike tells us to ‘just do it’ but what applies to exercise is not good advice for software testing. The next time you find yourself ‘just doing’ testing, pause for a moment and ask yourself ‘what is my goal?’ and ‘is there a purpose to this test?’ If the answer doesn’t immediately come to mind, you’re aimless, just doing it, and relying on luck and the sheer force of effort to find your quarry.


Luck has no place in sorcery or hunting and it has no place in testing. Luck is a nice happenstance, but it cannot be our plan A. Watch for the plague of aimlessness. Document your successes, scrutinize your failures and make sure you pass on what you learn from this introspection to your colleagues.


Be their wizard. Build a testing spell book and share it with others on your team. Over time you’ll banish the plague of aimlessness.

URL: http://googletesting.blogspot.com/2009/06/7-plagues-of-software-testing.html

[Gd] Stable, Beta update: Security fix

| More

Google Chrome Releases: Stable, Beta update: Security fix


Google Chrome 2.0.172.33 has been released to the Stable and Beta channels. This release fixes a critical security issue and two other networking bugs.

CVE-2009-2121: Buffer overflow processing HTTP responses
Google Chrome is vulnerable to a buffer overflow in handling certain responses from HTTP servers. A specially crafted response from a server could crash the browser and possibly allow an attacker to run arbitrary code. 

More info:  http://code.google.com/p/chromium/issues/detail?id=14508 (This issue will be made public once a majority of users are up to date with the fix.)

Severity: Critical. An attacker might be able to run code with the privileges of the logged on user.

Credit: This issue was found by the Google Chrome security team.

Other issues
This release also fixes two other network issues:
  - NTLM authentication to Squid proxies fails when trying to connect to HTTPS sites (Issue 8771)
  - Browser crash when loading some HTTPS sites (Issue 13226)
  
Mark Larson
Google Chrome Program Manager
URL: http://googlechromereleases.blogspot.com/2009/06/stable-beta-update-security-fix.html

[Gd] [Libraries][Update] - MooTools 1.2.3

| More

Google AJAX API Alerts: [Libraries][Update] - MooTools 1.2.3

MooTools was updated to version 1.2.3
URL: http://ajax-api-alerts.blogspot.com/2009/06/librariesupdate-mootools-123.html