While each of these fine web browsers has its own way doing things, ranging from keyboard shortcuts to tab management and process handling, they all more or less pull these off a bit nicer than Internet Explorer ever code. But the one Internet Explorer feature I can honestly say I miss when using Google Chrome is the ability to submit the form being currently modified/filled-in with a keyboard shortcut, especially if it works even if there are multiple forms on the screen.

Searching about for a cross-platform solution to this problem, perhaps a previously unknown keyboard shortcut or else some method of assigning a keyboard shortcut that would let Google Chrome intelligently submit the current form via a keyboard shortcut on both Mac and Windows, it became clear that this feature just doesn’t exist for Chrome. Well, as of yesterday, at any rate…

As of today, this feature does exist and it can be yours by just installing Chrome Form QuickSubmit, a Google Chrome extension that will add the keyboard shortcut alt+shift+s on Windows/Linux and cmd+shift+s on Mac to your Chrome, letting you easily and quickly submit the form you’re filling in without needing to resort to tabs, or gasp the mouse:

Google Chrome QuickSubmit 0.2

Again, the keyboard shortcuts are alt+shift+s on Windows/Linux and cmd+shift+s on OS X. These shortcuts do not, to the best of my knowledge, conflict with any others and there aren’t any known issues with this extension. So go ahead, click the link above, authorize the extension, refresh this page, and test it out in the box below!

My first post on Google+ was a questioning

I’m not sure I like Google Plus?

to which Google+ obliged with

Nice post!

Need I say more?

Google Chrome has a new logo, and it wants to make sure everyone knows.

Those of you updating to the latest Chrome builds (in this case, 11.0.696.12 dev, running on Mac OS X 10.7) will find that the new version comes with a bold new icon. We’re not sure if we like it just yet, because it definitely takes some getting used to.

The new icon is at the top-right of this post. For comparison, here’s the old one:

The new one is distinctly more 2d, less shiny, and far more abstract. They say that’s the natural progression of logos, but Chrome and its logo certainly haven’t been around since the 60s for us to be discussing that.

Us? We can’t stop seeing a big, colorful ’9′ whenever we glance at the icon.

And (after the jump), here’s the new Chrome logo in super-size. [Click it on it to load the image itself at full resolution]

Follow us on Twitter @neosmart or on Facebook at http://facebook.com/NeoSmart

Perhaps even more shocking than that link is where it takes you. One would expect it to show a nice selection of pre-prepared background designs showing taste and style. Perhaps some swirls, some modern art, some crazy tie-dye… Certainly not letting you choose and upload any photo of your liking to serve as your new Google background! Even more, the feature is directly connected to Picassa, letting you browse your own albums, the public Picassa uploads of other users, and more.

Update: This appears to be working only on Windows, at the moment. Looks like Google is taking this for a test-drive.

Chrome 4.0 now shows the status of file uploads as a percentage, making it very clear just how quickly (or not) your uploads are progressing – and it’s something that all browsers should add ASAP. Many social websites rely heavily on uploads of photos, videos, music, and other files and are forced to implement nasty workarounds (such as using Flash upload forms) to present a more user-friendly upload system.

A screenshot of Chrome 4.0′s new upload progress indicator:

Chrome has quickly become our favorite browser at NST: it’s fast, light, and doesn’t get in the way.

As an example, search Google for “libmhash” right now. The first result is the result you want, but you’d never know it from looking at the search result:

Personally, I clicked on the second result. In this case, it too led to the correct page, but the actual, valid result is the first. But where the URI should be in the search result, it instead says “sourceforge.net > Projects” which honestly leads one to think it points to a list of projects on SourceForge rather than the libmhash project. Google needs to either add the complete bread-crumb trail “sourceforge.net > Projects > libmhash” or else keep the full URI visible because it currently stands, the results are confusing and misleading.

In the article, Ben Goodger, lead Chrome UI developer, states

[Google avoids] cross platform UI toolkits because while they may offer what superficially appears to be a quick path to native looking UI on a variety of target platforms, once you go a bit deeper it turns out to be a bit more problematic.” [... Your applications end up] speaking with a foreign accent.

But there’s something we’re not getting here. Obviously given enough brilliant programmers and a good team lead to keep the different codebases in sync, going with native APIs is the better approach. But the reasons Goodger is offering aren’t very convincing.

The problem is…. Google’s Chrome for Windows doesn’t look native. In fact, it’s about as far from native Win32 as you can get. We had originally explained away the non-win32 looks by assuming it was because Google wanted an interface that was consistent across the different platforms and different at the same time from any of the operating systems native UI toolkits: in line with Google’s vision of turning the browser into an OS, regardless of the platform beneath.

A non-native UI that looks the same on Mac, Windows, and Linux would be the answer to such a browser OS. It would indicate that Chrome is its own product – from the codebase to the user experience – and that to the end user it shouldn’t matter what OS you’re on. And that in the future Google could ship a standalone (OS-free) browser that looks like Chrome and acts like Chrome, regardless of the platform beneath?

Otherwise there is no good explanation for the horrendously-different user interface that comes with Chrome. It requires learning the tips & tricks to a whole new UI, and forgetting a number of “niceties” you may have been accustomed to (such as pressing the ‘spacebar’ to OK pop-up dialogs, etc.).

With the preliminary screenshots of Chrome for Mac, the platform Chrome runs on begins to peek through.

Does this mean that Google’s vision of Chrome as its own OS has come to pass – with Google now content to just launch a cross-platform browser without attempting to lull users away from the platforms they’ve come to love?

Whatever the case, it’s sure to be interesting watching and waiting to see what Google has planned for its users. Whether its a cross-platform browser experience that’s different enough to be the same across all platforms while retaining a feel of the platform or if it’s paving the way for the OS to come it’s quite obvious that the gears are now in motion and something big just might happen.

But it looks like someone may have been a bit to hasty to pull that switch (perhaps itching to get some of the limelight Microsoft has been receiving for adding OpenID to all Live ID accounts just the day before yesterday)… because whatever it is that Google has released support for, it sure as hell isn’t OpenID, as they even so kindly point out in their OpenID developer documentation (that media outlets certainly won’t be reading):

1. The web application asks the end user to log in by offering a set of log-in options, including Google.
2. The user selects the "Sign in with Google" option.
3. The web application sends a "discovery" request to Google to get information on the Google authentication endpoint. This is a departure from the process outlined in OpenID 1.0. [Emphasis added]
4. Google returns an XRDS document, which contains endpoint address.
5. The web application sends a login authentication request to the Google endpoint address.
6. This action redirects the user to a Google Federated Login page.

As Google points out, this isn’t OpenID. This is something that Google cooked up that resembles OpenID masquerading as OpenID since that’s what people want to see – and that’s what Microsoft announced just the day before.

It’s not just a “departure” from OpenID, it’s a whole new standard.

With OpenID, the user memorizes a web URI, and provides it to the sites he or she would like to sign in to. The site then POSTs an OpenID request to that URI where the OpenID backend server proceeds to perform the requested authentication.

In Google’s version of the OpenID “standard,” users would enter their @gmail.com email addresses in the OpenID login box on OpenID-enabled sites, who would then detect that a Google email was entered. The server then requests permission from Google to use the OpenID standard in the first place by POSTing an XML document to Google’s “OpenID” servers. If Google decides it’ll accept the request from the server, it’ll return an XML document back to the site in question that contains a link to the actual OpenID URI for the email account in question.

This is shown quite clearly in the following image (courtesy of Google, ironically):

As you can see, steps 3 & 4 are not part of OpenID and leave Google’s implementation of OpenID, such as it is, incompatible with everyone else.

Google actually mentions this in passing:

Starting today, we are providing limited access to an API for an OpenID identity provider that is based on the user experience research of the OpenID community. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service is www.zoho.com.

Eric Sachs, author of the blog post in question, doesn’t actually come out and say, but he does come very close.

Basically, Google has rewritten OpenID. Not only is it not exactly the same as the current OpenID protocol, it’s so different that existing OpenID relying parties won’t be able to use it. Only a handful of “partner sites” have been updated to understand Google’s perverted version of the OpenID standard, and anyone else hoping to authenticate via “OpenID” to Google’s servers will need to do the same.

But OpenID is an open, community-based standard. Stabbing them in the back by creating an incompatible standard “based on” the same technology and masquerading under the same name isn’t the way to go. Google may have the best interests of decentralized authentication in mind, and perhaps even the better protocol to boot; but this is no way to prove a point.

OpenID is on tenterhooks as it is, and cannot withstand any more efforts to splinter its adoption. Never mind the fact that almost all the big names adopting OpenID are joining only as providers and not as relying parties (rendering the whole basis of OpenID useless) – now even the provider side of things is chaos.

Thanks, Google. Good to see you’re still doing the whole “Do no evil” thing, the community really appreciates this kind of approach to improving de facto standards and pushing decentralized authentication!

It would seem that between the way Gmail saves and retrieves sessions, existing sessions are authenticated, and views are cached there are one or more loopholes that allow data from a different account (that has nothing to do with yours) to be served instead of the correct data.

I don’t know why, but here’s the how:

• Firefox 3 opened to Gmail on Ubuntu.
• Session accidentally reset with ctrl+alt+bkspc
• Upon reboot & restarting of Firefox, Firefox requested the URIs that were previously open before the crash, partially loading data from local cache and the rest dynamically from the web (because of the AJAX portions of the Gmail interface).

The result:

• Gmail loaded up the email account of a user I’d never contacted before, never heard of, and never knew existed.
• I could see the front page of this user’s inbox, including the people he’d recently contacted, the brief summary of all messages, the total number of messages in the inbox, the number of unread messages in other folders, the dates of all correspondences, and a number of contacts (again, none that I have had contact with) in the sidebar.
• The number of remaining Gmail invites, the amount of space used, and other status values also reflected this mysterious individual’s account.
• I couldn’t browse deeper than the main page of the inbox. Emails couldn’t be opened, nothing past the first 50 correspondences could be seen, and I couldn’t switch to another folder.
• Attempts to do any of the above resulted in Gmail’s “Oops… the system encountered a problem (#102) – Retrying in XXs… <Retry Now>”

Parts of the Gmail interface contained values pertaining to my own account (for instance, the online status indicator) while others referred to this other individual’s account instead.

It’s very bizarre. I don’t know if it can be readily reproduced, but I’d imagine if you forced an exit of Firefox 3 and kept on firing it back up at some point or another you’d see similar behavior. Of course, a deeper analysis of what data Firefox 3 requests from Gmail’s servers verses what’s served from the local session cache may yield further information that could possibly be used to actively take advantage of this data leak.

It seems that Firefox requests a cached session complete with cookies and all from the Gmail URI, which in turn loads the Gmail javascript files that are responsible for retrieving the data associated with a particular email account via AJAX. At this point, either the session key is associated with another account and so Gmail retrieves the information assumming the session to be properly authenticated or else the expired session somehow causes Gmail to get data from elsewhere…

Screenshots of this behavior:

Gmail displaying the other user’s information:

Searching for this user in my own account yields no results:

As we’ve previously mentioned, NeoSmart Technologies is a big proponent of Full Disclosure. We’ve contacted the security department at Google and will post their reply if/when it’s available. We’ve also taken what we feel are the appropriate steps in this case with regards to the screenshots above in terms of what’s been made visible and what’s been blanked out for privacy concerns.

Update

The Google Security Team sent a reply to our inquiry. According to them, this behavior might be caused by broken ISP proxying, pending further investigation. This post will be further updated as soon as new information becomes available.

Update

Google has confirmed that was the result of an ISP caching/proxing problem, and that it’s been known to happen. It seems some ISPs are over zealous in their caching attempts (probably to save some money) – and you can add Cyberia to that list. Much thanks to Chris Evans of the Google Security Team for his feedback on the issue and prompt responses – that’s the way security is supposed to be handled!

We’ve long felt that Gmail’s approach was not befitting of the Web 2.0 service with all its sky-blue shades and flashy appearance – and now it seems that Google’s felt that way too.

Here’s the new loading interface… Subtle, simple, and effective:

(Click image to see more changes)
  

After all, first impressions are everything!

Google calls Pay-Per-Action the “complement to AdWords,” but in reality, Pay-Per-Action is an AdWords/AdSense replacement. Look at it from Google’s point of view: Google claims it loses over a billion dollar’s in revenue from click-fraud with AdSense. If Google thinks it’s losing that much money due to click-fraud, and Google sincerely believes that with Pay-Per-Action that loss will no longer exist, they’d be stupid not to switch over.. Unless of course, bloggers refuse to use their new PPA service.

From the bloggers’ point of view: look at the odds. You get several million viewers a day|week|month. Some of them click the ads. You have a CTR rate of around (probably under) 0.5%. Now how many of those 0.5% of your visitors that actually click an ad go through the whole way? How many of them buy the product being advertised? How many sign-up for the subscription on sale? How many go through with the “action?”

If you answered zero, you’d be correct. Even if one or two people did buy a product directly as a result of a link on your site, how many of these people will buy it on the spot? When they do want to make the purchase, are they going to go back to your site and make the click from there, or are they going to use a bookmark/URL to make the purchase? After all, if it’s not a direct referral you won’t get a single penny.

If they find a product they want to buy via a link on your site, and in the remote chance that they buy it on the spot, how much will you get? The product’s price isn’t changing, the revenue is simply being split 3-ways between You, Google, and the company selling the product. Obviously the Company has to make it’s money, and Google’s not in it for the Karma…

The bottom line is, you’re chances of making money just went from near zero (relatively speaking) to zero itself. The amount of money you make per “connection” may increase, but the net amount will almost undoubtedly drop to zero.

Stand up for your rights as a blogger/site-owner to reap the fruits of your toil. Don’t let Google feel that Pay-Per-Action is their freedom ticket, and don’t – whatever you do – fall for it. After all, it’s your pocketbook at stake!

It does seem that the idea was scrapped, as a matter of fact, MSN adCenter was “looking for guinea pigs” since over a year ago. While some sporadic blog posts on the subject, the only contextual-advertising solution coming out of Microsoft’s camp any time soon is for advertisers who want in on the MSN Live Search ads. It seems that Microsoft has finally decided to stop re-inventing the wheel, and learn from the mistakes of others. Yahoo!’s own Yahoo! Publisher Network (YPN) isn’t doing too hot, so perhaps that’s a wise decision in the end.

But has Microsoft completely dropped plans for its publisher-side context-driven ad program? That is highly unlikely. While at the moment MSN’s adCenter can support the demand for ads on its Live Search pages, the fact remains that as demand goes up (and the market saturates), Microsoft is going to need more room to place advertiser’s ads. In the ad-campaign business, it’s quantity that matters. Charging more for limited real-estate space on Live Search (simple rules of supply and demand) is only a temporary solution, since what matters most is exposure – lot’s of it, and the cheaper the better.

While Superbowl ads rake in hundreds of millions every year, if the Superbowl were on TV everyday, no one would pay that much – at least, not for too long. It’s the same thing with MSN’s current adCenter model. Sooner or later, they’ll need to expand it to include content publisher’s websites and visitors into the equation. The only question is, when will this happen? Microsoft certainly has had its hands full this year, especially with the constant delays of its operating system, and the sudden barage of new software needing immediate attention for release. Now that Vista, Office, and Exchange are out of the picture, maybe Microsoft will take this time to focus on context-based ads and re-analyze what they have.

The contextual-advertising market is huge. It’s nowhere near tapped for all it’s worth, and no matter how hard Google tries, it doesn’t have the entire market covered. Yahoo! may have bungled things up with their poor “context-analysis” and absoloutely dismal customer support/response times, but that doesn’t mean that only Google can play this game.

Earlier today, Slashdot featured a story on EarthLink’s “random” dropping of email messages. We just concluded a test of our own, and we find the results may not be as random as they seem. In fact, the results point directly to a big spider of sorts, sitting in the middle of all the tubes and picking what goes through and what doesn’t.

According to EarthLink themselves, “EarthLink’s mail system has been so overloaded that some users have been missing up to 90 percent of their incoming e-mail.” But what they don’t mention is, it isn’t random. As a matter of fact, our tests lead us to believe that EarthLink is indeed prioritizing not only message delivery time but also whether the messages ever get there or not.

We sent out 20 email messages from a EarthLink account, and discovered that 100% of them reached an @Gmail.com email, 30% reached a no-name domain, and 100% of them reached an @Yahoo.com email. This could of course be a coincidence, but at a time like this, we don’t think so.

When a system is under load, generally speaking it (attempts to) deliver messages in the order they were received, and they either go through or they don’t. What makes EarthLink’s results a bit more interesting is, the messages that went through and those that didn’t have absolutely nothing to do with the physical network routes:

EarthLink’s mail servers are hosted in New York; Gmail’s are hosted in Mountain View, CA; Yahoo’s servers are in Redwood City, CA; and our no-name servers are in Chicago. Technically speaking, packets sent from New York should arrive in Chicago before they do all the way on the other end of the continent. But of course, our no-name server isn’t on any high-politics list, nor is it loaded with money.

If “dumb” networks existed, then the packets would have most certainly made it to our server before they reached Gmail’s or Yahoo’s all the way in California. Unless, of course, net-neutrality is no longer just a concept or idea for the future, but something applicable in the here-and-now. If the big names in computing are prioritizing one-another’s networks to such an extent, we’re in trouble.

Move over Google, there’s a new search engine in town! What’s that? SearchMash is Google? Never mind then, scratch that…

It doesn’t make a difference really, stop going to Google.com because that’s not the place to get answers nowadays. SearchMash is, both literally and figuratively speaking, the new Google.

It’s quite a challenge really: how does the Number 1 search engine on the web rewrite its search algorithm and test its effectiveness without hurting its current results and user-experience during the testing process? Sergey Brin and Larry Page seem to have figured it out: create a new search engine, and do your testing there!

SearchMash.com is the evolution of Google, [[GOOG]] and should things go right, what Google will (soon enough) become. It tests a range of new features and methods of bringing information to the users’ fingertips in more ways than immediately obvious to the eyes.

SearchMash was born a couple of months ago, and at first, it was Google.com with a new face. The results were identical, and for those that thought it was a hoax or a scam, the whois results proved otherwise. Since then it has constantly changed, with features and improvements being added and dropped. There is no guarantee that what we review here will make the final product, if such a thing even exists.

Several of the new-found SearchMash qualities are reviewed here, and their impact/accuracy/perfection is analyzed in context with Google, Microsoft, and the web today.

1. Improved Algorithm
   
   We’re geeks, this is what matters to people like us. And indeed, SearchMash does feature a new and improved search algorithm to back its results.
2. Overhauled Search Interface
   
   Some people don’t like Google’s “too-plain” look – which suits others just fine. SearchMash has a different interface and attempts to compromise between style and simplicity.
3. (Really) Related Links
   
   Instead of AdWords on the side, SearchMash features a series of iframes that provide added results and value to your search.
4. Conclusion
   
   It’s new, it’s cool, but is it worth changing your default search engine or even homepage over to?

The trick is – use the Arabic. About a month ago, Google launched its brand-new (beta) English-to-Arabic and Arabic-to-English translation service, making it the first free online translation tool that actually gives decent results… of sorts. At any rate, that’s another story for another day; right now, it’s the (“Web 2.0”) technology we care about: Dynamic switching between source and destination languages on a translated webpage.

For instance, here’s our “WordPress-in-the-Name Issues” story from a couple of weeks ago in Arabic; it’s ideal because of it’s more “natural” language and glaring lack of code boxes, technospeak, and general all-around esoteric content. If you understand Arabic – ignore the grammar, it’s really bad. If you don’t, that’s ok, it doesn’t matter.

Most people have grown so used to the Google “Frame Bar” up at the top, visible when viewing cached content or translated web pages, that they never give it a second thought… until something unexpected happens. Here’s what it says this time:

Notice the “or mouse over text…” portion that isn’t available when viewing it in any other language! What does this do? Well, when you mouse over a block of text, for instance, this (badly translated) one:

becomes

That mouse-over effect is pretty damn cool. Web 2.0 aside for now (and for the rest of the article!), the practical benefits of such a dynamic translation method are quite impressive. How many times have you translated a German/Dutch/French/Spanish page that had a couple of English sentences on it to English – only to find out that already-English text was mangled along the way? Just mouse-over it!

Automated translation isn’t an exact science. Just as people make mistakes translating things, computers do too, and then some. Even Google hasn’t perfected it yet, so every little thing that makes reading or accessing machine-translated content easier certainly is an improvement. And who knows, this could be but a stepping stone. Once this reaches the other languages, it might be used to do side-by-side translations, comparisons of text in several languages, and maybe even block translation so you can translate only the things that need it!