Friday, January 29, 2010

[Gd] Flashy New Authentication: AuthSub Adds Support for ActionScript

| More

Google Code Blog: Flashy New Authentication: AuthSub Adds Support for ActionScript

Today, we are happy to announce the launch of AuthSub for ActionScript, a new component of the well-known AuthSub authentication interface for the Google Data Protocol. This new feature enables Flash and Silverlight applications to access data securely on behalf of a user, without the application ever seeing the user’s private login credentials.

To use AuthSub for Actionscript (or as we’re calling it, AuthSubAS), first ensure that the API you are accessing offers cross-domain support. To do this, simply check for a crossdomain.xml file like those offered by the Picasa Web Albums Data API and the YouTube Data API. Then, if the API supports cross-domain scripting, you can simply point your Flash app to https://accounts.googleapis.com/accounts/AuthSub{Request,SessionToken} and authenticate. If you’re familiar with how AuthSub for JavaScript works, AuthSubAS works in much the same way. For more information, see the AuthSub for ActionScript guide and check out this code sample.

Currently, cross-domain requests are only supported by the Picasa Web Albums Data API and the YouTube Data API.  However, as more APIs offer cross-domain scripting through an open crossdomain.xml file, the AuthSubAS authentication will work automatically. For questions about a specific API or to encourage your API to provide AuthSubAS support sooner, visit your API’s support group in Google Groups.

By Joseph Schorr and Zach Maier, Google Data Protocol Team
URL: http://googlecode.blogspot.com/2010/01/flashy-new-authentication-authsub-adds.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update


The devchannel has been updated to 5.0.307.1 for Windows & Mac

Windows
  • [r37023] Use default downloads directory on Vista and Windows 7 (except where it is the desktop) (Issue: 13610)
  • [r36938 and others] Start work on Content Settings window and sub-dialogs (Issue: 32719)

Mac
  • Improved plugin stability.
  • [r37204][r37210] Cocoa NPAPI plugins will now get NPCocoaEventMouseDragged and NPCocoaEventFlagsChanged events (Issues: 32996, 31846)
  • [r37010] Fix crash that sometimes happened when dragging tabs (Issue: 29906)
  • [r37004] Fix %cpu in task manager. (Issue: 32464)
  • [r37139] Give the cookies manager a search field. (Issue: 32328)
  • [r37247] Make copying of big images more robust (Issue: 26822)
  • [r37114] Improve task manager resizing behavior (Issues: 33134, 33133)

Known Issues
  • [Mac] Crash when deleting cookies (Issue: 33533).

More details about additional changes are available in the svn log of all revision.

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

Orit Mazor
Google Chrome
URL: http://googlechromereleases.blogspot.com/2010/01/dev-channel-update_29.html

Thursday, January 28, 2010

[Gd] Google Wave at I/O

| More

Google Wave Developer Blog: Google Wave at I/O

As you may remember, Google Wave was first unveiled to the world at last year's Google I/O, in the 80-minute (infamous?) keynote. In the handful of sessions that we squeezed in on that second day, we explained the basics of the API, the core operational transformation (OT) algorithm, how we take advantage of GWT to build the client, and a bit about the federation protocol. This year, we are focusing on how you can build upon those basics to take Wave integration to the next level. We'll teach you how to build amazing extensions, how to get your own wave server running, and how to start using Wave inside your business. Check out the sessions below, and make sure you can join us for them by registering for I/O!


Open source Google Wave: Building your own wave provider
Dan Peterson, Jochen Bekmann

Google Wave API design principles + anatomy of a great extension
Pamela Fox, Douwe Osinga

Making smart & scalable Wave robots
Douwe Osinga, David Byttow

Google Wave and the enterprise environment
Greg D'alesandre


We're looking forward to chatting with you all, seeing what you've been working on, and discussing what awesome ideas are brewing in your heads.



Posted by Pamela Fox, Developer Relations
URL: http://googlewavedev.blogspot.com/2010/01/google-wave-at-io.html

[Gd] Request visitors' permission before installing software

| More

Official Google Webmaster Central Blog: Request visitors' permission before installing software

(Cross-posted on the Google Korea Blog)

Webmaster Level: All

Legitimate websites may require that their visitors install software. These sites often do so to provide their users with additional functionality beyond what's available in standard web browsers, like viewing a special type of document. Please note, however, that if your site requires specific software for your visitors, the implementation of this software installation process is very important. Incorrect implementation can appear as though you're installing malware, triggering our malware detection filters, and resulting in your site being labeled with a 'This site may harm your computer' malware warning in our search results.

If using your site requires a special software install, you need to first inform visitors why they need to install additional software. Here are two bad examples and one good example of how to handle the situation of a new visitor to such a site:

Bad: Install the required software without giving the visitor a chance to choose whether or not they want to install the software.

Bad: Pop up a confirmation dialog box that prompts the visitor to agree to install the software, without providing enough detail for the visitor to make an informed choice. (This includes the standard ActiveX control installation dialog box, since it doesn't contain enough meaningful information for a visitor to make an informed decision about that particular piece of software.)

Good: Redirect the new visitor to an information page which provides thorough details on why a special software installation is required to use the site. From this page the visitor can initiate the installation of the required software if they decide to proceed with installation.

Has your site been labeled with a malware warning in our search results due to a poorly implemented software installation requirement? Updating the installation process to ensure that visitors are fully informed on why the installation is necessary, and giving them a chance to opt out, should resolve this issue. Once you've got this in place, you can go to Webmaster Tools and request a malware review to expedite the process of removing any malware warnings associated with your site in Google's search results.

Written by Jonathan Simon, Webmaster Trends Analyst
URL: http://googlewebmastercentral.blogspot.com/2010/01/request-visitors-permission-before.html

[Gd] Encouraging More Chromium Security Research

| More

Chromium Blog: Encouraging More Chromium Security Research

In designing Chromium, we've been working hard to make the browser as secure as possible. We've made strong improvements with the integrated sandboxing and our up-to-date user base. We're always looking to stay on top of the latest browser security features. We've also worked closely with the broader security community to get independent scrutiny and to quickly fix bugs that have been reported.

Some of the most interesting security bugs we've fixed have been reported by researchers external to the Chromium project. For example, this same origin policy bypass from Isaac Dawson or this v8 engine bug found by the Mozilla Security Team. Thanks to the collaborative efforts of these people and others, Chromium security is stronger and our users are safer.

Today, we are introducing an experimental new incentive for external researchers to participate. We will be rewarding select interesting and original vulnerabilities reported to us by the security research community. For existing contributors to Chromium security — who would likely continue to contribute regardless — this may be seen as a token of our appreciation. In addition, we are hoping that the introduction of this program will encourage new individuals to participate in Chromium security. The more people involved in scrutinizing Chromium's code and behavior, the more secure our millions of users will be.

Such a concept is not new; we'd like to give serious kudos to the folks at Mozilla for their long-running and successful vulnerability reward program.

Any bug filed through the Chromium bug tracker (under the template "Security Bug") will qualify for consideration. As this is an experimental program, here are some guidelines in the form of questions and answers:

Q) What reward might I get?
A) As per Mozilla, our base reward for eligible bugs is $500. If the panel finds a particular bug particularly severe or particularly clever, we envisage rewards of $1337. The panel may also decide a single report actually constitutes multiple bugs. As a consumer of the Chromium open source project, Google will be sponsoring the rewards.

Q) What bugs are eligible?
A) Any security bug may be considered. We will typically focus on High and Critical impact bugs, but any clever vulnerability at any severity might get a reward. Obviously, your bug won't be eligible if you worked on the code or review in the area in question.

Q) How do I find out my bug was eligible?
A) You will see a provisional comment to that effect in the bug entry once we have triaged the bug.

Q) What if someone else also found the same bug?
A) Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.

Q) What about bugs present in Google Chrome but not the Chromium open source project?
A) Bugs in either build may be eligible. In addition, bugs in plugins that are part of the Chromium project and shipped with Google Chrome by default (e.g. Google Gears) may be eligible. Bugs in third-party plugins and extensions are ineligible.

Q) Will bugs disclosed publicly without giving Chromium developers an opportunity to fix them first still qualify?
A) We encourage responsible disclosure. Note that we believe responsible disclosure is a two-way street; it's our job to fix serious bugs within a reasonable time frame.

Q) Do I still qualify if I disclose the problem publicly once fixed?
A) Yes, absolutely. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes and nominate you for the Google Security "thank you" section.

Q) What about bugs in channels other than Stable?
A) We are interested in bugs in the Stable, Beta and Dev channels. It's best for everyone to find and fix bugs before they are released to the Stable channel.

Q) What about bugs in third-party components?
A) These bugs may be eligible (e.g. WebKit, libxml, image libraries, compression libraries, etc). Bugs will be ineligible if they are part of the base operating system as opposed to part of the Chromium source tree. In the event of bugs in a component shared with other software, we are happy to take care of responsibly notifying other affected parties.

Q) Who determines whether a given bug is eligible?
A) The panel includes Adam Barth, Chris Evans, Neel Mehta, SkyLined and Michal Zalewski.

Q) Can you keep my identity confidential from the rest of the world?
A) Yes. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However — at your discretion, we can credit the bug to "anonymous" and leave the bug entry private.

Q) No doubt you wanted to make some legal points?
A) Sure. We encourage participation from everyone. However, we are unable to issue rewards to residents of countries where the US has imposed the highest levels of export restriction (e.g. Cuba, Iran, North Korea, Sudan and Syria). We cannot issue rewards to minors, but would be happy to have an adult represent you. This is not a competition, but rather an ongoing reward program. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon local law.

We look forward very much to issuing our first reward and featuring it on our releases blog. We're happy to take questions at security@chromium.org. Alternatively, feel free to leave a comment. We will update this blog post with answers to any popular questions.

Finally, if you're interested in helping out Chromium security on a more permanent basis, we have open positions.

Posted by Chris Evans, Google Chrome Security
URL: http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html

Wednesday, January 27, 2010

[Gd] A proposal to extend the DNS protocol

| More

Google Code Blog: A proposal to extend the DNS protocol

Today a group of DNS and content providers, including Neustar/UltraDNS and Google are publishing a proposal to extend the DNS protocol. DNS is the system that translates an easy-to-remember name like www.google.com to a numeric address like 74.125.45.104. These are the IP addresses that computers use to communicate with one another on the Internet.

By returning different addresses to requests coming from different places, DNS can be used to load balance traffic and send users to a nearby server. For example, if you look up www.google.com from a computer in New York, it may resolve to an IP address pointing to a server in New York City. If you look up www.google.com from the Netherlands, the result could be an IP address pointing to a server in the Netherlands. Sending you to a nearby server improves speed, latency, and network utilization.

Currently, to determine your location, authoritative nameservers look at the source IP address of the incoming request, which is the IP address of your DNS resolver, rather than your IP address. This DNS resolver is often managed by your ISP or alternately is a third-party resolver like Google Public DNS. In most cases the resolver is close to its users, in which case the authoritative nameservers will be able to find the nearest server. However, some DNS resolvers serve many users over a wider area. In these cases, your lookup for www.google.com may return the IP address of a server several countries away from you. If the authoritative nameserver could detect where you were, a closer server might have been available.

Our proposed DNS protocol extension lets recursive DNS resolvers include part of your IP address in the request sent to authoritative nameservers. Only the first three octets, or top 24 bits, are sent providing enough information to the authoritative nameserver to determine your network location, without affecting your privacy.

The Internet-Draft was posted to the dnsext mailing list today, and over the next few months our group hopes to see this proposal accepted as an official Internet standard. We plan to continue working with all interested parties on implementing this solution and are looking forward to a healthy discussion on the dnsext mailing list.

By Wilmer van der Gaast and Carlo Contavalli on behalf of the Google Public DNS team
URL: http://googlecode.blogspot.com/2010/01/proposal-to-extend-dns-protocol.html

[Gd] v2009 Hack Day Video Preview

| More

AdWords API Blog: v2009 Hack Day Video Preview

Our recent AdWords API Hack Days in San Francisco and New York were a huge success, filled with presentations, question and answer sessions, and one-on-one coding help. We were glad to see that many developers have already started the migration to the v2009 API, and these events were a great way to kick off the process for those just getting started. Don't forget that most v13 services will be turned off on April 22.

We will be posting videos of the presentations on YouTube over the coming weeks, starting this week with Migrating from v13 to v2009 by Adam Rogal. The presentation gives an overview of the suggested migration process, provides some tips and tricks, and includes live coding examples.

This video is the first of many, and if you'd like to get the full experience there is still space available in our upcoming Paris Hack Day. Get more information and register for an upcoming Hack Day.



Best,
- Eric Koleda, AdWords API Team
URL: http://adwordsapi.blogspot.com/2010/01/v2009-hack-day-video-preview.html

[Gd] [Libraries][Update] jQuery 1.4.1

| More

Google AJAX API Alerts: [Libraries][Update] jQuery 1.4.1

jQuery was updated to 1.4.1
URL: http://ajax-api-alerts.blogspot.com/2010/01/librariesupdate-jquery-141.html

Tuesday, January 26, 2010

[Gd] Android at Mobile World Congress

| More

Android Developers Blog: Android at Mobile World Congress

I'm happy to announce that we'll be hosting a very special Android Developer Lab at Mobile World Congress (MWC) in Barcelona on Wednesday, February 17th as part of the inaugural App Planet event.

There will be technical presentations throughout the day and a developer lounge where you can talk to Android team members and meet others in the growing Android developer community.

Whether you’re already developing Android apps, you're an experienced mobile developer, or you’re considering making your first foray into writing mobile applications, the Android Developer Lab will provide access to the resources you need to create innovative and compelling apps for the Android platform.

Space is limited in the technical sessions, so if you're attending MWC and want to come by the Android Developer Lab, make sure to sign up now.

Also, we're offering a limited number of complimentary passes that provide access to the Android Developer Lab, the rest of App Planet, and the general exhibition areas for MWC. Sign up to be considered to receive a pass.

Hope to see you in Barcelona!

URL: http://android-developers.blogspot.com/2010/01/android-at-mobile-world-congress.html

[Gd] Create and share Google Sites with new Sites Data API features

| More

Google Code Blog: Create and share Google Sites with new Sites Data API features

Several months ago we launched the Google Sites Data API. Since then, we've worked hard to respond to your top feature requests: the ability to list a user's sites, create new sites, copy existing sites, and manage sharing permissions. Today, we are very excited to announce the release of the Site and Access Control List feeds that make these new features possible.

The Site feed allows your client to list sites and update their properties, such as the title or the theme of the site. Google Apps users can also create new sites. Because creating new sites often involves copying existing ones (perhaps using a site template), we've enabled that feature too.

Here's an example of the kinds of applications you can build with those features. Let's say you're a professor at a university and you'd like to create a Google Site for each of the courses you teach. The Site feed makes it possible for you to create a site course template, use the site feed to create several course sites, and personalize them with the content feed.

But what if you want to restrict access to your sites to just the students taking those courses? With the ACL (Access Control List) feed, you can manage sharing permissions. Everything you can do in the Google Sites admin panel, you can do with the API.

To get the full scoop, review the documentation and change log. We've loaded the Java client library and Python client library with the new features, and offer updated developer guides for both.

Visit us in our new developer forum if you have questions!


By Laurent Tu & Eric Bidelman - Google Sites API Team
URL: http://googlecode.blogspot.com/2010/01/create-and-share-google-sites-with-new.html

[Gd] Security in Depth: New Security Features

| More

Chromium Blog: Security in Depth: New Security Features

We've been hard at work adding proactive security features to Google Chrome, and we're particularly excited about five new security features that make it easier for developers to build secure web sites.

Strict-Transport-Security

Strict-Transport-Security lets a high-security web site tell the browser that it wants to be contacted over a secure connection only. That means the browser will always use HTTPS to connect to the site and will treat all HTTPS errors as hard stops (instead of prompting the user to "click through" certificate errors). This feature strengthens the browser's defenses against attackers who control the network, such as malicious folks disrupting the wireless network at a coffee shop.

Originally proposed in a research paper in 2008, Strict-Transport-Security is now an open specification. In addition to being in Google Chrome 4, Strict-Transport-Security has also been implemented in NoScript, a security add-on for Firefox, and a native implementation is underway in Firefox. A number of high-security web sites have already started to use the feature, including PayPal. As with all of our security improvements, we hope that every browser will adopt Strict-Transport-Security, making the web, as a whole, more secure.

Cross-Origin Communication with postMessage

The postMessage API is a new HTML5 feature that lets web developers establish a communication channel between frames in different origins. Previously, when you wanted to add a gadget to your web page, you had two options: (1) include the gadget via a script tag, or (2) embed the gadget using an iframe tag. If you used a script tag, you could have a rich interaction with the gadget (e.g., the Google Maps API), but you had to trust the gadget author not to inject malicious script into your web page. Alternatively, if you used an iframe tag to embed the gadget (e.g., the Google Calendar web element), you had strong security properties, but it was difficult to interact with the gadget.

postMessage changes the game. By using postMessage to communicate with the gadget, you get the security advantages of an iframe with all the interactivity of a script tag. What's more, you can use postMessage to create more secure versions of existing gadgets. postMessage is now available in the latest versions of all the major browsers: Google Chrome, Internet Explorer, Firefox, Safari, and Opera. A number of web sites, including Facebook, are already using postMessage to make their site safer.

CSRF Protection via Origin Header

The Origin header is a new HTML5 feature that helps you defend your site against cross-site request forgery (CSRF) attacks. In a CSRF attack, a malicious web site, say attacker.com, instructs the user's browser to send an HTTP request to a target server, say example.com, that confuses the example.com server into performing some action. For example, if example.com is a webmail provider, the CSRF attack might trick example.com into forwarding an email message to the attacker.

The Origin header helps sites defend against CSRF attacks by identifying which web site generated the request. In the above example, example.com can see that the request came from the malicious web site because the Origin header contains the value http://attacker.com. To use the Origin header as a CSRF defense, a site should modify state only in response to requests that either (1) lack an Origin header or (2) have an Origin header with a white-listed value.

The details of the Origin header are still being finalized. We will update the implementation in Google Chrome as the specification evolves based on feedback from Mozilla and from the W3C and IETF communities at large. We welcome your feedback on the last draft of the specification.

ClickJacking Protection with X-Frame-Options

First introduced in Internet Explorer 8, X-Frame-Options is a security feature that lets web sites defend themselves against clickjacking attacks. To defend against clickjacking, a web developer can request that a web page not be loaded inside a frame by including the X-Frame-Options: deny HTTP header. X-Frame-Options is implemented in Google Chrome, Internet Explorer 8, and Safari 4.

Reflective XSS Protection

One of the most difficult parts of building a secure web site is protecting against cross-site scripting (XSS) vulnerabilities. In Google Chrome 4, we've added an experimental feature to help mitigate one form of XSS, reflective XSS. The XSS filter checks whether a script that's about to run on a web page is also present in the request that fetched that web page. If the script is present in the request, that's a strong indication that the web server might have been tricked into reflecting the script.

The XSS filter is similar to those found in Internet Explorer 8 and NoScript. Instead of being layered on top of the browser like those filters, our XSS filter is integrated into WebKit, Google Chrome's rendering engine. Integrating the XSS filter into the rendering engine has two benefits: (1) the filter can catch scripts right before they are executed, making it easier to detect some tricky attack variations, and (2) the filter can be used by every WebKit-based browser, including Safari and Epiphany.

We are aware of a few ways to bypass the filter, but, on balance, we think that the filter is providing enough benefit to enable it by default in this release. If you discover a new way to bypass the filter, please let us know. We're very interested in improving the filter in subsequent releases. We're grateful to the security researchers who have helped us with the filter thus far (especially Eduardo "Sirdarckcat" Vela), and we welcome even more participation.

Posted by Adam Barth, Software Engineer
URL: http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html

[Gd] Interviewing Insights and Test Frameworks

| More

Google Testing Blog: Interviewing Insights and Test Frameworks

By James A. Whittaker

Google is hiring. We have openings for security testers, test tool developers, automation experts and manual testers. That's right, I said manual testers.

As a result of all this interviewing I've been reading a lot of interview feedback and wanted to pass along some insights about how these applicants approach solving the testing problems we ask in our interviews. I think the patterns I note in this post are interesting insights into the mind of the software tester, at least the ones who want to work for Google.

One of the things our interviewers like to ask is 'how would you test product xyz?' The answers help us judge a tester's instincts, but after reading many hundreds of these interviews I have noticed marked patterns in how testers approach solving such problems. It's as though testers have a default testing framework built into their thinking that guides them in choosing test cases and defines the way they approach test design.

In fact, these built-in frameworks seem to drive a tester's thinking to the extent that when I manage to identify the framework a tester is using, I can predict with a high degree of accuracy how they will answer the interviewers' questions. The framework defines what kind of tester they are. I find this intriguing and wonder if others have similar or counter examples to cite.

Here are the frameworks I have seen just in the last two weeks:

The Input Domain Framework treats software as an input-output mechanism. Subscribers of this framework think in terms of sets of inputs, rules about which inputs are more important and relationships between inputs, input sequences and outputs. This is a common model in random testing, model-based testing and the testing of protocols and APIs. An applicant who uses this framework will talk about which inputs they would use to test a specific application and try to justify why those inputs are important.

The Divide and Conquer Framework treats software as a set of features. Subscribers begin by decomposing an app into its features, prioritizing them and then working through that list in order. Often the decomposition is multi-layered creating a bunch of small testing problems out of one very large one. You don't test the feature so much as you test its constituent parts. An applicant who uses this framework is less concerned with actual test cases and more concerned with reducing the size of the problem to something manageable.

The Fishbowl Framework is a big picture approach to testing in which we manipulate the application while watching and comparing the results. Put the app in a fishbowl, swirl it around in the water and watch what happens. The emphasis is more on the watching and analyzing than it is on exactly how we manipulate the features. An applicant who uses this framework chooses tests that cause visible output and large state changes.

The Storybook Framework consists of developing specific scenarios and making sure the software does what is is supposed to do when presented with those scenarios. Stories start with the expected path and work outward. They don't always get beyond the expected. This framework tests coherence of behavior more than subtle errors. Applicants who employ this framework often take a user's point of view and talk about using the application to get real work done.

The Pessimists Framework starts with edge cases. Subscribers test erroneous input, bad data, misconfigured environments and so on. This is a common strategy on mature products where the main paths are well trodden. Applicants who use this framework like to assume that the main paths will get tested naturally as part of normal dev use and dog-fooding and that the testing challenge is concentrated on lower probability scenarios. They are quick to take credit for prior testing, assume its rationality and pound on problematic scenarios.

There are more and I am taking furious notes to try and make sense of them all. As I get to know the testers who work in my organization, it doesn't take long to see which frameworks they employ and in what order (many are driven by multiple frameworks). Indeed, after studying an applicant's first interview, I can almost always identify the framework they use to answer testing questions and can often predict how they are going to answer the questions other interviewers ask even before I read that far.

Now some interesting questions come out of this that I am still looking into. Which of these frameworks is best? Which is best suited to certain types of functionality? Which is better for getting a job at Google? Already patterns are emerging.

One thing is for sure, we're interviewing at a rate that will provide me with lots of data on this subject. Contact me if you'd like to participate in this little study!
URL: http://googletesting.blogspot.com/2010/01/interviewing-insights-and-test.html

[Gd] Changes to the hosted home page

| More

Google Custom Search: Changes to the hosted home page

Most Custom Search users choose to deploy a customized search experience on their own websites, using the inline Custom Search Element or an embedded iframe. However, some users choose to use the home page that we create automatically for every search engine. The hosted home page is also optimized for high-end mobile devices, such as the iPhone, iPod Touch and Android phones like the Droid or the Nexus One. The URL of the hosted home page looks like this:

http://www.google.com/cse/home?cx=013315504628135767172:d6shbtxu-uo

You'll notice that we've made a few minor changes to the hosted home page. You're likely to see more changes to this page in the future as we make new features like themes available for the hosted home page.

You can get to this Google-hosted home page for your search engine from the Custom Search control panel by clicking on the name of your search engine anywhere in your control panel.

As always, we're always looking to get your feedback.

Posted by: Radu Cornea, Software Engineer
URL: http://googlecustomsearch.blogspot.com/2010/01/changes-to-hosted-home-page.html

[Gd] Protect your site from spammers with reCAPTCHA

| More

Official Google Webmaster Central Blog: Protect your site from spammers with reCAPTCHA

Webmaster Level: All

If you allow users to publish content on your website, from leaving comments to creating user profiles, you’ll likely see spammers attempt to take advantage of these mechanisms to generate traffic to their own sites. Having this spammy content on your site isn't fun for anyone. Users may be subjected to annoying advertisements directing them to low-quality or dangerous sites containing scams or malware. And you as a webmaster may be hosting content that violates a search engine's quality guidelines, which can harm your site's standing in search results.

There are ways to handle this abuse, such as moderating comments and reviewing new user accounts, but there is often so much spam created that it can become impossible to keep up with. Spam can easily get to this unmanageable level because most spam isn’t created manually by a human spammer. Instead, spammers use computer programs called “bots” to automatically fill out web forms to create spam, and these bots can generate spam much faster than a human can review it.

To level the playing field, you can take steps to make sure that only humans can interact with potentially spammable features of your website. One way to determine which of your visitors are human is by using a CAPTCHA , which stands for "completely automated public Turing test to tell computers and humans apart." A typical CAPTCHA contains an image of distorted letters which humans can read, but are not easily understood by computers. Here's an example:


You can easily take advantage of this technology on your own site by using reCAPTCHA, a free service owned by Google. One unique aspect of reCAPTCHA is that data collected from the service is used to improve the process of scanning text, such as from books or newspapers. By using reCAPTCHA, you're not only protecting your site from spammers; you're helping to digitize the world's books.

Luis Von Ahn, one reCAPTCHA's co-founders, gives more details about how the service works in the video below:


If you’d like to implement reCAPTCHA for free on your own site, you can sign up here. Plugins are available for easy installation on popular applications and programming environments such as WordPress and PHP.

Posted by Michael Wyszomierski, Search Quality Team
URL: http://googlewebmastercentral.blogspot.com/2010/01/protect-your-site-from-spammers-with.html

[Gd] Reminder: Version v200906 will be shut down in one week

| More

AdWords API Blog: Reminder: Version v200906 will be shut down in one week

The v200906 API, which we released as a limited beta in June 2009, will be shut down one week from today, on February 2, 2010. The v200909 API, launched in October of last year, is a full replacement for v200906 and adds significant functionality. Read our earlier post covering the changes required for migration.

Don't forget that most v13 services will be turned off on April 22, 2010, so be sure to begin your migration to v200909 if you haven't already.

The AdWords API team is here to help you transition to v200909. Please post your questions to the Developer Forum.

-- Jason Shafton, Product Marketing Manager
URL: http://adwordsapi.blogspot.com/2010/01/reminder-version-v200906-will-be-shut.html

Monday, January 25, 2010

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

The stable channel has been updated to 4.0.249.78 for Windows, and includes the following features and security fixes (since 3.0):
  • Extensions
  • Bookmark sync
  • Enhanced developer tools
  • HTML5: Notifications, Web Database, Local Storage, WebSockets, Ruby support
  • v8 performance improvements
  • Skia performance improvements
  • Full ACID3 pass, due to re-enabled remote font support (with added defense against bugs in operating system font libraries)
  • HTTP byte range support
  • New security feature: "Strict Transport Security" support
  • Experimental new anti-reflected-XSS feature called "XSS Auditor"
Security Fixes:

Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.
  • [3275] Low Pop-up blocker bypass. Credit to Google Chrome Security Team (SkyLined).
  • [9877] Medium Cross-domain theft due to CSS design error. Credit to Chris Evans of the Google Security Team.
  • [12523] Medium Browser memory error with stale pop-up block menu. Credit to Jacob Balle and Carsten Eiram, Secunia Research.
  • [20450] Low Prevent XHR to directories. Credit to the Chromium development community.
  • [23693] Low Escape more characters in shortcuts. Credit to Michal Zalewski of the Google Security Team and, independently, Inferno of SecureThoughts.com.
  • [8864] [24701] [24646] High Renderer memory errors drawing on canvases. Credit to Michal Zalewski of the Google Security Team and Google Chrome Security Team (SkyLined).
  • [28566] High Image decoding memory error. Credit to Robert Swiecki of the Google Security Team.
  • [29920] Low Corner case failure to strip Referer. Credit to the Chromium development community.
  • [30666] High Cross-domain access error. Credit to Tokuji Akamine, Senior Consultant at Symantec Consulting Services.
  • [31307] High Bitmap deserialization error. Credit to Mark Dowd, under contract to Google Chrome Security Team.
  • [31517] Low Browser crash with nested URL.
Anthony Laforge
Google Chrome Program Manager
URL: http://googlechromereleases.blogspot.com/2010/01/stable-channel-update_25.html

[Gd] More Resources for Developers

| More

Chromium Blog: More Resources for Developers

This morning, we announced a new stable channel update of Google Chrome. For developers, this update represents some significant advances in terms of extensibility and new HTML and JavaScript APIs. Extensions are now available to all Google Chrome users, which enables you to provide additional functionality not just on your site, but to also bring content and functionality from your site into the browser, regardless of what sites a user may have open at any given time.

Google Chrome also includes a number of new HTML and JavaScript APIs. For instance, we now support the Web SQL Database API, which allows you to store data in a structured manner on the user's computer. If you're looking for a simpler client-side storage mechanism for relatively small amounts of data, check out the localStorage portion of the Web Storage API. We're already working on making these new APIs more useful and you should see a couple of improvements on the developer channel soon. In particular, we're working on Application Cache which gives you the ability to serve HTML and JavaScript that references content in the Web SQL Database. SessionStorage, the little brother of localStorage, is coming soon as well.

Besides working on these four storage focused APIs, we have also implemented WebSockets. This is a new API for sending data over a persistent bi-directional communication channel, designed to be easier, more powerful, and less resource intensive than using XHR. Finally, today we are also making available -- in Windows only -- the new notification API that allows you to present information to users, such as event reminders or status updates, via a panel in the user's status-bar area. This panel allows you to provide more styling than window.alert(). It should also be much less irritating to your users - with this API notifications are still visible but do not get a user's attention by stealing cursor, tab or window focus.

If you have questions about the extensions APIs, the extensions discussion group continues to be the best place to get answers. For the new HTML and JavaScript APIs, we've just created a new Chromium HTML5 group. We're excited about these and the other capabilities we'll be adding soon but we're even more excited to see all of the amazing stuff you'll be creating with them!

Posted by Ian Fette, Product Manager
URL: http://blog.chromium.org/2010/01/more-resources-for-developers.html

[Gd] Extensibility + new HTML and JavaScript APIs for Google Chrome

| More

Google Code Blog: Extensibility + new HTML and JavaScript APIs for Google Chrome

Today's new stable release of Google Chrome for Windows includes a bundle of browser goodness, including extensions and new HTML and JavaScript APIs.

Extensions -- previously available on Google Chrome for Windows on the beta channel -- and are now available to all users. Extensions enable you to provide additional functionality not just on your site, but to bring content and functionality from your site into the browser regardless of what sites the user has open. Google Chrome extensions use the same multiprocess technology that makes the browser fast and more secure, so that extensions won't crash or slow down your browser.


In addition, we're excited to introduce a number of new HTML and JavaScript APIs in Google Chrome, including the Web Storage and Web SQL Database APIs, WebSockets, and more. For more details about these APIs, read further on the Chromium Blog.

If you have questions about the extensions APIs, the extensions discussion group continues to be the best place to get answers. For the new HTML and JavaScript APIs, check out the newly created Chromium HTML5 group. And for those of you who are interested in attending Google I/O, check out the current list of Google Chrome sessions.

By Ian Fette, Product Manager, Google Chrome
URL: http://googlecode.blogspot.com/2010/01/extensibility-new-html-and-javascript.html