Slashdot Mirror

New submitter GreyWanderingRogue writes "Google is looking to expand beyond the three current cities using Google Fiber. They're currently still in the discussion stages, but they've invited 34 cities in 9 major metropolitan areas to talk about deployment. They'll need to study 'topography (e.g. hills, flood zones), housing density, and the condition of local infrastructure' in each of the cities, so it will be interesting to see how many make it to completion. Check the map to see if you're one of the lucky few. The Atlanta, Portland and Raleigh-Durham areas each have a cluster of cities being considered. Not in one of these cities? It might be a while yet..."

New submitter GreyWanderingRogue writes "Google is looking to expand beyond the three current cities using Google Fiber. They're currently still in the discussion stages, but they've invited 34 cities in 9 major metropolitan areas to talk about deployment. They'll need to study 'topography (e.g. hills, flood zones), housing density, and the condition of local infrastructure' in each of the cities, so it will be interesting to see how many make it to completion. Check the map to see if you're one of the lucky few. The Atlanta, Portland and Raleigh-Durham areas each have a cluster of cities being considered. Not in one of these cities? It might be a while yet..."

An anonymous reader writes "One of the biggest worries about the rise of wearable computing is the ease with which random strangers will be able to record your actions without your knowing. Right now, it's pretty easy to tell if somebody's holding up their cellphone to take some video. But when everybody's wearing Google Glass, or something similar, it will become harder to tell. This has led to preemptive bans on Glass in certain places. Now, Google has published a list of Do's and Don'ts to tell Glass users how they should behave politely in public. Do: ask for permission before recording people. Don't: ignore the world around you, expect that people won't notice, or wear it during a cage fight. Most importantly, don't 'be creepy or rude.' Google says, 'Standing alone in the corner of a room staring at people while recording them through Glass is not going to win you any friends.'"

New submitter TheP4st writes "A group of Swedish police officers thought it would be a good idea to use WhatsApp as a work tool for surveillance operations. The officer that set up their chat group mistyped one of the phone numbers to mistakenly include a civilian IT teacher. Once the teacher informed authorities about the mistake, it took more than 24 hours before he stopped receiving sensitive case information, which included criminal records, passport photos, and communications between surveillance teams tailing suspects. When confronted by Computer Sweden (Google translation of Swedish original), the officer responsible for setting up the group said, 'I know this server is not located in Sweden and that one cannot share every kind of information.' The only mobile chat medium approved for sensitive information is BlackBerry, and this initiative by a small group of officers happened because they do not have access to BlackBerry handsets."

itwbennett writes "Google has done what the European Commission declined to do: publish the details of the latest commitments Google made in a bid to settle a long-running antitrust case involving its treatment of rival specialist search services, among other matters. On the company's European policy blog, Google's senior vice president and general counsel, Kent Walker, announced the publication of what he called the 'full text' (PDF) of the company's commitments. In fact, the 93-page document contains a number of redactions, including details of a parameter used to rank search results, the identities of two companies with customized contracts for Adsense For Search, and a proposal for modification of those contracts to comply with the other commitments."

Despite being declared officially lost, the Chinese moon rover may yet have some life left. Hugh Pickens DOT Com writes "CNN reports that reports of Jade Rabbit's demise may have been premature as signs are emerging that China's first lunar rover may be up and running again. Following technical malfunctions Xinhua says that the lunar rover had lost communication with mission control but on Thursday the state news agency said that the rover was "fully awake" and had returned to its normal signal-receiving status. "Jade Rabbit has fully resurrected and is able to receive signals, but still suffers a mechanical control abnormality," says China's lunar program spokesman Pei Zhaoyu. "The rover entered hibernation while in an abnormal state. We were worried it wouldn't be able to make it through the extreme cold of the lunar night. But it came back alive. The rover stands a chance of being saved as it is still alive." The lunar rover's end seemed near when it signed off at the end of January with a poignant message: "Goodnight humanity." Yutu, as the device is known in Mandarin, had been out of action for two weeks following a technical malfunction, and media around the world filed its obituary late on Wednesday after a short statement on Chinese state media alerted the world to its apparent terminal failings. Should Jade Rabbit make a full recovery, it would cap another success for space exploration, which has seen NASA's Opportunity Mars rover, currently exploring the red planet, far outlast its expected lifespan."

First time accepted submitter maratumba writes to explain a bill in Turkey that extends what are already hefty Internet curbs in place under a controversial 2007 law that Earned Turkey equal ranking with China as the world's biggest web censor according to a Google Transparency report published in December. The text notably permits a government agency, the Telecommunications Communications Presidency (TIB), to block Access to websites without court authorization if they are deemed to violate privacy or with content Seen as 'insulting.' Erdogan, Turkey's all-powerful leader since 2003, is openly suspicious of the Internet, branding Twitter a 'menace' for being Utilized in organisation of mass nationwide protests in June in which six people died and thousands were injured."

symbolset writes "On the heels of the smackdown received by cable lobbyists in Kansas, Ars reports out of Utah that the cable companies aren't giving up hopes of preventing competition through legislation. The bill, called Interlocal Entity Service Prohibition, would prevent a regional fiber consortium from building infrastructure outside the boundaries of its member cities and towns — a direct attack on Google's work in Provo and the UTOPIA network. Utah is the third state to be involved in the Google Fiber rollout of gigabit fiber to the home."

Peter Eckersley writes "Over at EFF, we just released a version of our HTTPS Everywhere extension for Firefox for Android. HTTPS Everywhere upgrades your insecure web requests to HTTPS on many thousands of sites, and this means that Firefox on Android with HTTPS Everywhere is now by far the most secure browser against dragnet surveillance attacks like those performed by the NSA, GCHQ, and other intelligence agencies. Android users should install the Firefox app and then add HTTPS Everywhere to it. iPhone and iPad users will unfortunately have to switch to Android to get this level of security because Apple has locked Mozilla Firefox out of their platforms."

Peter Eckersley writes "Over at EFF, we just released a version of our HTTPS Everywhere extension for Firefox for Android. HTTPS Everywhere upgrades your insecure web requests to HTTPS on many thousands of sites, and this means that Firefox on Android with HTTPS Everywhere is now by far the most secure browser against dragnet surveillance attacks like those performed by the NSA, GCHQ, and other intelligence agencies. Android users should install the Firefox app and then add HTTPS Everywhere to it. iPhone and iPad users will unfortunately have to switch to Android to get this level of security because Apple has locked Mozilla Firefox out of their platforms."

sfcrazy writes "Linus Torvalds has had some harsh words for Nvidia in the past. Their failure to work constructively with the Linux community is especially disappointing in light of the company's large presence in the Android market. That said, where there is life, there is change, and that is just what happened yesterday. Torvalds publicly gave a thumbs-up to Nvidia for contributing basic support for the recently released Nvidia K1 processor to Nouveau; something that was totally unexpected but received with open arms. 'Hey, this time I'm raising a thumb for nvidia. Good times,' said Linus."

mikejuk writes "Google and Opera split from WebKit to create Blink, their own HTML rendering engine, and everyone was worried about the effect on standards. Now we have the first big example of a split in the form of CSS Regions support. Essentially Regions are used to provide the web equivalent of text flow, a concept very familiar to anyone who has used a desktop publishing program. The basic idea is that you define containers for a text stream which is then flowed from one container to another to provide a complex multicolumn layout. The W3C standard for Regions has mostly been created by Adobe — a long time DTP company. Now the Blink team has proposed removing Regions support to save 10,000 lines of code in 350,000 in the name of efficiency. If Google does remove the Regions code, which looks highly likely, this would leave Safari and IE 10/11 as the only two major browsers to support Regions. Both Apple and Microsoft have an interest in ensuring that their hardware can be used to create high quality magazine style layouts — Google and Opera aren't so concerned. I thought standards were there to implement not argue with." Although mikejuk thinks this is a bad thing, a lot of people think CSS Regions are awful. Mozilla has never intended to implement them, instead offering the CSS Fragmentation proposal as an alternative. One major flaw of CSS Regions is its reliance upon markup that is used solely for layout, violating the separation of content and style that CSS is intended to enforce.

As the NSA metadata collection scandal has developed, a number of technology and communications companies have fought to increase the transparency of the data collection process by publishing reports on how much data government agencies are asking them for. These transparency reports have been limited, however, because most government requests are entwined with a gag order. In a speech two weeks back, President Obama said this would change, and now the Dept. of Justice has announced new, slightly relaxed rules about what information companies can share. According to an email from the U.S. Deputy Attorney General (PDF) to the General Counsel of Google, Facebook, LinkedIn, Microsoft, and Yahoo, the companies can publish: how many Criminal Process requests they received, how many National Security Letters they received, how many accounts were affected by NSLs, how many Foreign Intelligence Surveillance Act orders were received (both for communications content and 'non-content'), and how many customers were targeted by FISA requests. The companies still aren't allowed to give specific numbers, but they can report them in bands of 1,000 — for example, 0-999, 1,000-1,999, etc. Information requests for old services cannot be disclosed for at least six months. The first information requests for a new service cannot be disclosed for two years. The companies also have the option of lumping all the NSL and FISA requests together — if they do that, they can report in bands of 250 instead of 1,000.

swinferno writes "The Dutch ISPs Ziggo and XS4all are no longer required to block access to the websites of The Pirate Bay. [Original in Dutch; here's Google's translation.] This has been decided by the court in The Hague. The blockade has proven to be ineffective. The Dutch anti-piracy organization BREIN will have to reimburse legal costs of €326,000. The internet provider XS4ALL has already started lifting the ban. The website of The Pirate Bay was ordered to be blocked by the two major ISPs in January 2012. Recent studies by Amsterdam University and CentERdata showed that this did not reduce the number of downloads from illegal sources. Many people circumvented the blockade."

Velcroman1 writes "I've seen the future. It's called gigabit Internet by Google Fiber, and it just launched in my hometown of Provo, Utah, the second of three scheduled cities to get speeds that are 100 times faster than the rest of America. 'What good is really fast Internet if the content stays the same?' you may ask yourself. I certainly did, before testing the service. Besides, my "high speed" Internet from Comcast seemed fast enough, enabling my household to stream HD videos, load web pages quickly, and connect multiple devices as needed, largely without hiccup. I was wrong. Using gigabit Internet, even in its infancy, opened my eyes to speed and reminded me of why I love the Internet."

Velcroman1 writes "I've seen the future. It's called gigabit Internet by Google Fiber, and it just launched in my hometown of Provo, Utah, the second of three scheduled cities to get speeds that are 100 times faster than the rest of America. 'What good is really fast Internet if the content stays the same?' you may ask yourself. I certainly did, before testing the service. Besides, my "high speed" Internet from Comcast seemed fast enough, enabling my household to stream HD videos, load web pages quickly, and connect multiple devices as needed, largely without hiccup. I was wrong. Using gigabit Internet, even in its infancy, opened my eyes to speed and reminded me of why I love the Internet."

An anonymous reader writes "TechCrunch is reporting on an interesting Gmail bug. Apparently, if you run a Google search for Gmail while logged in and click one of the top (and correct) results, it brings up a Compose window with an email address already filled in: the Hotmail account of a Fresno, CA man. He says he's been receiving hundreds every hour, most of which are blank, since yesterday. The article says the bug is related to the Gmail outage from earlier this afternoon."

eggboard writes "The Internet Archive has copies of Web pages corresponding to 378 billion URLs. It's working on several efforts, some of them quite recent, to help deter or assist with link rot, when links go bad. Through an API for developers, WordPress integration, a Chrome plug-in, and a JavaScript lookup, the Archive hopes to help people find at least the most recent copy of a missing or deleted page. More ambitiously, they instantly cache any link added to Wikipedia, and want to become integrated into browsers as a fallback rather than showing a 404 page."

jones_supa sends this AFP report: "Microsoft soared to record revenues in the last quarter, confounding Wall Street forecasts on the back of strong demand for Xbox consoles, Surface tablets and Internet cloud services. The U.S.-based technology titan reported net income of $6.56 billion on revenue that hit a record high of $24.52 billion in the quarter that ended December 31. ... Sales of Surface tablets more than doubled from the previous quarter to hit $893 million, and Microsoft sold 7.4 million Xbox videogame consoles, with 3.9 million of those being new-generation Xbox One. Bing's share of the Internet search market grew to 18.2 percent while its share of the online search ad market grew about a third, according to Microsoft. Meanwhile, money made from selling Windows software to computer makers slid by three percent due to continue soft demand by consumers for personal computers, according to Microsoft."

Hugh Pickens DOT Com writes "Eric Barker writes at TheWeek that while high intelligence has its place, a large-scale study of more than three hundred creative high achievers including Leonardo da Vinci, Galileo, Beethoven, and Rembrandt has found that curiosity, passion, hard work, and persistence bordering on obsession are the hallmarks of genius. 'Successful creative people tend to have two things in abundance, curiosity and drive. They are absolutely fascinated by their subject, and while others may be more brilliant, their sheer desire for accomplishment is the decisive factor,' writes Tom Butler-Bowdon. It's not about formal education. 'The most eminent creators were those who had received a moderate amount of education, equal to about the middle of college. Less education than that — or more — corresponded to reduced eminence for creativity,' says Geoffrey Colvin. Those interested in the 10,000-hour theory of deliberate practice won't be surprised that the vast majority of them are workaholics. 'Sooner or later,' writes V. S. Pritchett, 'the great men turn out to be all alike. They never stop working. They never lose a minute. It is very depressing.' Howard Gardner, who studied geniuses like Picasso, Freud, and Stravinsky, found a similar pattern of analyzing, testing, and feedback used by all of them: 'Creative individuals spend a considerable amount of time reflecting on what they are trying to accomplish, whether or not they are achieving success (and, if not, what they might do differently).' Finally, genius means sacrifice. 'My study reveals that, in one way or another, each of the creators became embedded in some kind of a bargain, deal, or Faustian arrangement, executed as a means of ensuring the preservation of his or her unusual gifts. In general, the creators were so caught up in the pursuit of their work mission that they sacrificed all, especially the possibility of a rounded personal existence,' says Gardner."

According to the company's website, "HAL© is the future of television and media management. Using proprietary gesture and voice control technology..." In this case, HAL© stands for “Human Algorithm LTE.” It looks like it's a lot safer than the original HAL 9000, anyway. Is it ready for prime time? If their CES demo is any indication, not quite. They say HAL© is going to ship in the fall of 2014. The technology? They won't say beyond, "It's proprietary." Ah! Then it must be good, right? Another voice-operated remote control -- that's already available for purchase from major retailers -- is the Ivee Sleek. There are other HALs out there, too. Like this one. And this one, which is a home automation server that costs $2499.00 (& up). Anyway, the retail price for HAL(circle-C) is supposed to be $199 when it hits the streets. And even though it doesn't look like HAL© can do much that I can't already do with my Android phone, Skyvi, and a Chromecast, it might be fun to test and review once it's in production.

First time accepted submitter BillCable writes "One of the most useful and intuitive features of Google's Map tool was the "Search nearby" link. After searching for a location, users could click on a marker on the map to pop open a window with the address and other details. This window also contained a link to 'Search nearby' — extremely useful if you want to find a list of restaurants near a hotel, the closest pharmacy, or any other business you might want to patronize. Google recently updated their map tool, and 'Search nearby' is no longer present. The 300 posts to the Google Product Forums complaining about this omission indicates this is a feature Maps users sorely miss. Google's work-around (detailed by Google staff in said thread) are a poor substitute and unreliable. There is no indication Google will add the feature to their new tool. For now users are able to revert to the original Google Maps with the 'Search nearby' feature intact. But there's concern that when Google discontinues support that the feature will be lost. So why would Google remove one of its best features?"

Recently presented at Linuxconf.au was Glyphy, a text renderer implemented using OpenGL ES2 shaders. Current OpenGL applications rasterize text on the CPU using Freetype or a similar library, uploading glyphs to the GPU as textures. This inherently limits quality and flexibility (e.g. rotation, perspective transforms, etc. cause the font hinting to become incorrect and you cannot perform subpixel antialiasing). Glyphy, on the other hand, uploads typeface vectors to the GPU and renders text in real time, performing perspective correct antialiasing. The presentation can be watched or downloaded on Vimeo. The slide sources are in Python, and I generated a PDF of the slides (warning: 15M due to embedded images). Source code is at Google Code (including a demo application), under the Apache License.

Recently presented at Linuxconf.au was Glyphy, a text renderer implemented using OpenGL ES2 shaders. Current OpenGL applications rasterize text on the CPU using Freetype or a similar library, uploading glyphs to the GPU as textures. This inherently limits quality and flexibility (e.g. rotation, perspective transforms, etc. cause the font hinting to become incorrect and you cannot perform subpixel antialiasing). Glyphy, on the other hand, uploads typeface vectors to the GPU and renders text in real time, performing perspective correct antialiasing. The presentation can be watched or downloaded on Vimeo. The slide sources are in Python, and I generated a PDF of the slides (warning: 15M due to embedded images). Source code is at Google Code (including a demo application), under the Apache License.

An anonymous reader writes "Google today released Chrome version 32 for Windows, Mac, and Linux. The new version includes tab noise indicators, a new look for Windows 8 Metro mode, and automatic blocking of malware downloads. You can update to the latest release now using the browser's built-in silent updater, or download it directly from google.com/chrome."

A number of companies are either selling or preparing to sell 3-D scanners. Aside from fun (but interesting) uses, like duplicating chess pieces or possibly reproducing a miniature of Rodin's famous sculpture, Fallen Caryatid Carrying Her Stone, Matterform anticipates archeologists reproducing artifacts so that students can study them without handling the precious originals. This video is an interview with Matterform co-founder Drew Cox, who was exhibiting Matterform's scanner at CES 2014. MakerBot is also selling a scanner, as are a growing number of others. In fact, even though Matterform talks about being a low-cost (pre-order price $579) scanner for home use, as opposed to a commercial one that costs thousands. There are also several interesting hand-held scanners out there. Sense sells theirs for $399. Structure has one for $349 that's essentially a peripheral for an iPad. And this is just a random selection from a brief Google search. Use "3-D Scanner" as your search term and you'll find multiple Google pages full of 3-D scanners and information about them -- including software being developed at ETH zurich that turns your smartphone into a 3-D scanner.

JDG1980 writes "Google just announced that they will be purchasing Nest, a company best known for their 'smart' thermostats and smoke detectors, for $3.2 billion in cash. What will this mean for Nest devices going forward — greater integration with Android, perhaps?"

In a town called Portsmouth, Ohio, a company called Yost Engineering (YEI) Technology has quietly been making motion sensing devices for military, aerospace, industrial, robotics, and other commercial motion capture uses, including rotoscoping for the film/video industry. Now they want to bring this same technology to gaming. They tried a Kickstarter campaign in 2013, but only got a little less than 1/2 of their target amount pledged. They're going to do Kickstarter again, starting Feb. 14, 2014 -- and this time, they've been working on PR before asking for money. You can see what they're up to in gaming sensor development at www.priovr.com/. Or go to the main YEI Technology corporate site, which has a whole bunch of free downloads in addition to the usual product blurbs.

Bennett Haselton writes "Google created controversy by announcing that Google+ users will now be able to send email to Gmail users even without having those Gmail users' email addresses. I think this debate misses the point, because it's unlikely to create a deluge of unsolicited email to Gmail users, as long as Google can throttle outgoing messages from Google+ users and terminate abusive accounts. The real controversy should be over the fact that Google+ users can search a public database of the names of all Gmail users in the first place. And limiting the ability of Google+ users to write to those Gmail accounts, won't do anything to address that." Read below to see what Bennett has to say.

To begin with, remember that on Facebook (which I no longer use, but which I keep up with) does allow you to search for other members' names and send them messages even if they have not yet accepted your friend request. Facebook users are generally not shy when it comes to complaining about problems with the site, but I've never heard Facebook users complaining about junk messages from strangers. (It's true that if you get a message from a user outside of your friends list, it gets routed to the "Other" folder of your Facebook inbox. But similarly, Google says that messages from strangers on Google+ will get routed to a Gmail user's "Social" tab of the inbox.)

So I expect the amount of actual unsolicited emails from Google+ users to Gmail users to be almost a complete non-issue, for the same reason that it's not an issue on Facebook. I assume the reason that Facebook users get so few junk messages, is that Facebook can limit the number of outgoing messages sent per day by any one account (although I don't know what that limit is), and can shut down accounts that are reported for abuse. Yes, a spammer could continually create new accounts to send more messages, but if you create too many Facebook accounts from the same IP address, and each account created from that IP address gets flagged for abuse, Facebook might start disallowing new accounts created from that IP. You could switch your IP address continually, but at a certain point, spammers must have decided that creating disposable Facebook accounts for spamming purposes wasn't worth the trouble, because the simple fact is that they don't do it. So Gmail users are not in danger of buried in spam from Google+ accounts. (By contrast, conventional email spam grew to unmanageable proportions because anybody with an email server could send out millions of messages per day, unless their provider cut them off.)

On the other hand, I think we should be more concerned about the fact that anyone who creates a Gmail address automatically has a Google+ account created for them. This doesn't just mean that any of Google's claims about the "number of Google+ users" are inflated, if they're including everyone who signs up for a Gmail account. (That's a valid complaint, but it's between Google and their shareholders, since the rest of us don't need to care how many users Google+ actually has.) More importantly, it means that all of those users become part of a public database that is searchable by name.

As a test, I went to Gmail.com and created a new user account, entering the first and last name "Zanzibar Higglesbrain" which I figured was probably unique. (Fan fiction authors: knock yourselves out.) Then I logged back in under my own Google+ account, went to the people search page, searched for "Zanzibar Higglesbrain", and found 1 match. (I didn't even need the exact name -- entering "Zanzibar Hi" into the people search box, listed Mr. Higglesbrain among the results.)

Now, when I created the Higglesbrain account, how much up-front notice was I given that I would be adding myself to a public database? I went through the normal signup process, viewed through the eyes of a novice -- after typing in Gmail.com, I was redirected to a page on accounts.google.com with the innocuous title "Create your Google Account", and entered my personal information. On the next page is the somewhat confusingly worded message (I've also posted a screen shot here):

How you'll appear

Choose how you appear across Google by creating a public Google+ profile.
Include a photo - you can update it at any time.
[Link:] Add a photo
[Button:] Next step

This message is misleadingly worded because the phrase "by creating a public Google+ profile" implies that's something you can do, optionally, if you want to. It doesn't really disclose the fact that the profile is being created for you as a side effect of signing up for Gmail. The wording might be interpreted, rather, to mean that your profile will only be created if you upload a photo (which is not the case; your profile gets created regardless). And besides -- what if the user is a novice who went to Gmail.com because they saw all their friends using Gmail.com addresses, and have never even heard of "Google+"? If they haven't consented to their name being added to a publicly searchable database, it shouldn't be their responsibility to know what "Google+" is, so that they can object to their name being listed there.

After you click the "Next step" button, the final page in the account creation process says:

Welcome, [firstname]

Your new email address is [address]

Thanks for creating a Google Account. Use it to subscribe to channels on YouTube, video chat for free, save favorite places on Maps, and lots more.

Note what's conspicuously missing from this message: It doesn't mention Google+ at all, much less the fact that you have unwittingly "joined" it, where other users can find you.

I can think of a couple of scenarios where a user might object to their name being listed in a searchable user database, apart from just "on general principles". If you have a stalker in your past, and they find your name on Google+, it confirms for them that you're probably still alive, that you're probably active on the Internet, and that you're still going by the name that they knew you under. Or, if you have a very unique first name, anyone who knows it could search on Google+ to find your last name, even if you didn't want them to. Similarly, if you have a very unique last name, someone could use the search feature to find the names of your children and other relatives with the same last name, at least those of them that are using Gmail.

And this lack of user consent is a more serious problem on Gmail/Google+ than on Facebook, because most Facebook users create a profile with the general expectation that other Facebook users can find them. Some Facebook users had chosen not to make their accounts searchable -- and Facebook justifiably received a firestorm of criticism for removing that feature and forcing those users' profiles to become publicly searchable after all -- but the overwhelming majority of Facebook users had joined with the understanding that their profiles could be found by others. That's not a valid assumption about Gmail users -- if someone creates a Gmail.com email address, there's no reason to think that they believed they were joining a publicly searchable name database.

Google has tried to mollify people's concerns about emails from strangers on Google+, by specifying that anyone not already in your Google+ circles will only be able to send one message to your Gmail inbox, and will not be able to send more messages until you reply. But this misunderstands the privacy implications in, for example, the stalker scenario. If a stalker ex "Bob" really did find your name on Google+, they might try to tease out a reply by creating a Google+ account under the name of a friend "Alice" you and your ex had in common, and sending you a generic "How have you been doing lately?" message. Since that message probably won't raise any alarm bells (the message isn't asking for anything like a current address or phone number), you might not realize that just by replying, you've already done the damage (the stalker now knows your email address, plus the fact that it's still an actively used account).

Similarly, although you can modify your Gmail settings to prevent strangers on Google+ from messaging you, the ability to change a setting to fix a problem only helps a user if the user realizes when the problem is happening. For example, if the problem resulting from this new feature switch were a deluge of spam from strangers on Google+, then more and more users would get frustrated and look for information about how to stop the flood of spam, and most of them would find out about this setting and switch it off. But for combatting the stalker problem, this setting is useless, because by definition if a stalker finds you on Google+ (and tricks you into replying to a message and revealing your email address), you wouldn't know about that problem until the damage has already been done, at which point it's too late to solve it by changing a setting.

The only way to avoid this risk to people's privacy, would be for Google to ask Gmail users at the time they create a Gmail account: "Do you also want to create a Google+ account, yes or no? This means you will have a publicly searchable profile, and people who know your name will be able to find you." Some people would like to be found, some people would rather not be, and this would allow them to sort themselves properly.

But instead, we have an untold number of zombie Google+ accounts created whenever someone signs up for Gmail, which serve no purpose except to make it possible to find people who never confirmed that they wanted to be found -- all most likely for the reason given by Chris Taylor at Mashable, so that "Larry Page gets to claim increased Google+ user numbers on the next quarterly earnings call."

An anonymous reader writes "Google has confirmed it is shutting down its goal sharing service Schemer. The company says Schemer's last day will be February 7, after which all data will be permanently deleted. The iOS app has already been pulled from Apple's App Store while the Android app on Google Play hasn't been updated since October 2012."

theodp writes "Purportedly intended to defuse tensions over gentrification that have led to blockades and vandalism of Google's ubiquitous shuttles (video), which make use of public San Francisco bus stops (map), Wired reports that Google is now chartering a ferry to take its workers from SF to Silicon Valley. 'We certainly don't want to cause any inconvenience to SF residents, and we're trying alternative ways to get Googlers to work,' Google explained. Inconveniencing whale-seeking visitors to The Aquarium of the Pacific, however, is apparently not considered evil. After learning that Google had co-opted the $4 million, 83-foot, 150-passenger whale-watching catamaran MV/Triumphant to ferry as few as 30-40 Googlers to work, some expressed concerns on Facebook that Google would be The Grinch That Stole Whale Watching Season (not to worry; the boat's slated to make its 'triumphant' return to Long Beach after Google's '30-day trial')."

davecb writes "The Toronto Star's lead article today is Canada courting U.S. web giants in wake of NSA spy scandal, an effort to convince them their customer data is safer here. This follows related moves like Cisco moving R&D to Toronto. Industry Canada will neither confirm nor deny that European and U.S. companies are negotiating to move confidential data away from the U.S. This critically depends on recent blocking legislation to get around cases like U.S. v. Bank of Nova Scotia, where U.S. courts 'extradited' Canadian bank records to the U.S. Contrary to Canadian law, you understand ..."

hypnosec writes "China has lifted the 13-year-old foreign gaming console ban, which it imposed back in 2000 as a way to protect the nation's youth from unhealthy content that may adversely affect their mental health. The temporary lift of the ban, which was announced Monday by the State Council of PCR (Google Translation into English), will make way for international console vendors including Microsoft, Sony, and Nintendo to setup production facilities in the newly created Shanghai Free Trade Zone and sell their consoles throughout the country. The vendors will still have to go through local checks, including the ones from the Cultural authorities to ensure that they don't violate any of those rules."

Frequent contributor Bennett Haselton writes: "Google has fixed a vulnerability, first discovered by researcher Gergely Kalman, which let users search for credit card numbers by using hex number ranges. However, Google should have acknowledged or at least responded to the original bug finder (and possibly even paid him a bounty for it), and should have been more transparent about the process in general." Read on for the rest of the story.

Back in 2007, I wrote that it was possible to find credit card numbers on Google by searching for the first 8 digits of your credit card number with a space in the middle, e.g. "1234 5678". Some users pointed out in the comments that it was even easier to find card numbers by searching for a number range such as

4147000000000000..4147999999999999

At some point after that discovery was posted, Google altered their search filters so that using number ranges to search for credit cards, was no longer allowed. If you search for that range, you get a denial page which reads

Our systems have detected unusual traffic from your computer network. Please try your request again later.

According to security researcher Gergely Kalman, he had read my 2007 article and thought about the issue occasionally for a few years, then in December 2012 discovered a loophole in Google's search filter: He could search for number ranges matching credit cards by searching using hexadecimal numbers. So that instead of searching for

4060000000000000..4060999999999999

he could search for the same number range in hexadecimal:

0xe6c8c69c9c000..0xe6d753e6ecfff

and Google would allow the search, and return a list of matching pages (most of which contained credit card numbers).

Gergely sent an email to security@google.com on December 28, 2012 (which he later showed to me), describing the vulnerability in detail. After describing the simple trick, his email stated: "I don't know if this qualifies as a bug bounty bug, but I think it's certainly not in your interest to let these queries through. Using this method one can bypass all your numerical query filters, filters for SSN, TFN, credit cards, maybe DoS prevention and others I can not think of at the moment."

Gergely sent them a follow-up email on August 23, 2013. In both cases he said he received no response except for an auto-reply.

Then on November 8, 2013, I wrote another article bringing up the fact that the original "1234 5678" trick still made it easy to find credit card numbers through Google, and generally wondering if that particular issue was ever going to be fixed (while remaining unaware of Gergely's discovery).

Gergely saw the article, and subsequently posted his discovery publicly on November 12, along with disclosing the fact that he had written to Google and never received a response:

"So I notified Google, and waited. After a month without a response, I notified them again to no avail. With a minor tweak on Haselton's old trick, I was able to Google Credit Card numbers, Social Security numbers, and any other sensitive information."

Gergely emailed me about my article and sent me a link to his blog post. With Gergely's permission, I posted a message in Google's product forums on November 14th, describing the problem and trying to bring it to the attention of a Google employee:

"This is a security issue that I'm trying to bring to the attention of a Google employee. I'm not sure if it fits under 'malware,' but I couldn't find a better place to post it. The original discoverer already emailed security@google.com twice and says he received no response.
[...]
The original discoverer posted about this trick here:
http://www.toptal.com/web/with-a-filter-bypass-credit-card-numbers-are-still-still-google-able

Can we get confirmation from someone at Google that they're aware of this issue, regardless of what they decide to do about it?
Thanks!"

At the same time, I became curious if Google would fix the bug any time in the next couple of days, so I set up a daily reminder on my computer to click the hex-search-link every morning and see if it was blocked. So I checked every morning from November 15th until about November 20th, and then didn't bother for a few days after that. When I checked again on November 26th, the bug had been fixed, and searching on Google for a hexadecimal-number range matching credit card numbers, now gives the denial message:

Our systems have detected unusual traffic from your computer network. Please try your request again later.

Since Google didn't fix the bug for 11 months after first being notified by Gergely, but then fixed it within 2 weeks after Gergely's blog post and my forum question, it seems pretty certain that the blog post or the forum question was what triggered the fixing of the bug. But, then, why not acknowledge either with a response, or a bounty award for Gergely? According to the chart on Google's Application Security bounty program page, it should probably qualify for a $500 reward in the category "XSRF, XSSI and other common web flaws" under "Normal Google applications."

If Google had ignored the discovery completely -- or if they had replied and said that it was too low of a security priority to fix -- that probably would have settled the issue, whether we agreed or not. This is, after all, not exactly a sky-is-falling security hole -- in any case not as long as the "1234 5678" security hole allows people to find credit cards almost as easily.

But once Google decided to fix the bug, there would seem to be no excuse for snubbing the person who discovered it. Even though the fix was probably simple at the code level, pushing a code change through to the almighty Google search engine, is presumably not cheap. If they're going to incur the costs of fixing the bug, what could be the reason for not crediting the discoverer and paying the bounty, which would also establish a good future relationship with a smart bug hunter? (Presumably that's one of the reasons the program exists.)

Maybe both of the original emails to security@google.com got lost, and maybe that has to do with the high volume of emails that the email address receives. I have no idea how those emails are processed internally at Google, but I assume it's likely that there is a pool of security experts to review the incoming emails, and each incoming mail is randomly assigned to one of those experts. If Google wants to reduce the chance of a legitimate bug slipping through the cracks without spending any extra money, my suggestion would be:

Instead of having each email be reviewed by one person chosen at random from a pool of highly paid security experts, have each email be reviewed by five people chosen from a low-paid pool of smart but inexperienced employees. The group of five would each independently vote "Yes" or "No" on whether the security issue needed to be bumped up, with a majority making the decision.

This recommendation is based on two principles. First, if you do a majority vote from a group of five, this reduces the chance of a legitimate issue being mis-categorized by a fluke. If a single "expert" categorizes an issue report correctly 90% of the time, and an intern categorizes an issue correctly 80% of the time, then taking a majority vote from a group of five interns will yield the right answer more often than a single expert. (I'm hand-waving over a few details -- I'm assuming that the probability of the different interns categorizing the issue correctly, are independent, and I'm not weighing the relative cost of missing a legitimate issue versus raising a false alarm -- but the general principle still applies.)

Second, while it may take an experienced security researcher to understand the deeper implications of a bug and the cost of fixing it, in my experience most smart people can quickly see what constitutes a legitimate security hole and what is merely a decoy, even without a lot of coding experience. So it would be ideal work for interns or new employees who want to learn more about the kinds of security reports that come in.

That suggested fix is just based on my assumption that incoming emails to security@google.com are each reviewed by a single person, so that one oversight can cause an email to slip through the cracks.

On the other hand, when someone at Google did read the blog post or the forum question and discover the bug, I have no idea what sequence of events that kicked off, which led to the security hole being plugged without acknowledging the discoverer. That's another process that should be fixed.

Google, of course, deserves credit for fixing the bug, and generally for taking on the issue of filtering credit card searches in the first place. Blocking these searches, after all, mainly prevents harm to others by averting identity theft, without really benefitting Google directly; presumably they filter these searches due to some combination of (1) wanting to be a good corporate netizen and (2) not wanting their search tool abused by script kiddiez searching for credit cards (a class of users who would be singularly unlikely to click on the ads). But since they did fix the bug, they should pay the discoverer, or at least give Gergely a shout-out. If they ever decide to implement my intern-majority-rules idea for emails to security@google.com, a shout-out for that would be fine too.

Frequent contributor Bennett Haselton writes: "Google has fixed a vulnerability, first discovered by researcher Gergely Kalman, which let users search for credit card numbers by using hex number ranges. However, Google should have acknowledged or at least responded to the original bug finder (and possibly even paid him a bounty for it), and should have been more transparent about the process in general." Read on for the rest of the story.

Back in 2007, I wrote that it was possible to find credit card numbers on Google by searching for the first 8 digits of your credit card number with a space in the middle, e.g. "1234 5678". Some users pointed out in the comments that it was even easier to find card numbers by searching for a number range such as

4147000000000000..4147999999999999

At some point after that discovery was posted, Google altered their search filters so that using number ranges to search for credit cards, was no longer allowed. If you search for that range, you get a denial page which reads

Our systems have detected unusual traffic from your computer network. Please try your request again later.

According to security researcher Gergely Kalman, he had read my 2007 article and thought about the issue occasionally for a few years, then in December 2012 discovered a loophole in Google's search filter: He could search for number ranges matching credit cards by searching using hexadecimal numbers. So that instead of searching for

4060000000000000..4060999999999999

he could search for the same number range in hexadecimal:

0xe6c8c69c9c000..0xe6d753e6ecfff

and Google would allow the search, and return a list of matching pages (most of which contained credit card numbers).

Gergely sent an email to security@google.com on December 28, 2012 (which he later showed to me), describing the vulnerability in detail. After describing the simple trick, his email stated: "I don't know if this qualifies as a bug bounty bug, but I think it's certainly not in your interest to let these queries through. Using this method one can bypass all your numerical query filters, filters for SSN, TFN, credit cards, maybe DoS prevention and others I can not think of at the moment."

Gergely sent them a follow-up email on August 23, 2013. In both cases he said he received no response except for an auto-reply.

Then on November 8, 2013, I wrote another article bringing up the fact that the original "1234 5678" trick still made it easy to find credit card numbers through Google, and generally wondering if that particular issue was ever going to be fixed (while remaining unaware of Gergely's discovery).

Gergely saw the article, and subsequently posted his discovery publicly on November 12, along with disclosing the fact that he had written to Google and never received a response:

"So I notified Google, and waited. After a month without a response, I notified them again to no avail. With a minor tweak on Haselton's old trick, I was able to Google Credit Card numbers, Social Security numbers, and any other sensitive information."

Gergely emailed me about my article and sent me a link to his blog post. With Gergely's permission, I posted a message in Google's product forums on November 14th, describing the problem and trying to bring it to the attention of a Google employee:

"This is a security issue that I'm trying to bring to the attention of a Google employee. I'm not sure if it fits under 'malware,' but I couldn't find a better place to post it. The original discoverer already emailed security@google.com twice and says he received no response.
[...]
The original discoverer posted about this trick here:
http://www.toptal.com/web/with-a-filter-bypass-credit-card-numbers-are-still-still-google-able

Can we get confirmation from someone at Google that they're aware of this issue, regardless of what they decide to do about it?
Thanks!"

At the same time, I became curious if Google would fix the bug any time in the next couple of days, so I set up a daily reminder on my computer to click the hex-search-link every morning and see if it was blocked. So I checked every morning from November 15th until about November 20th, and then didn't bother for a few days after that. When I checked again on November 26th, the bug had been fixed, and searching on Google for a hexadecimal-number range matching credit card numbers, now gives the denial message:

Our systems have detected unusual traffic from your computer network. Please try your request again later.

Since Google didn't fix the bug for 11 months after first being notified by Gergely, but then fixed it within 2 weeks after Gergely's blog post and my forum question, it seems pretty certain that the blog post or the forum question was what triggered the fixing of the bug. But, then, why not acknowledge either with a response, or a bounty award for Gergely? According to the chart on Google's Application Security bounty program page, it should probably qualify for a $500 reward in the category "XSRF, XSSI and other common web flaws" under "Normal Google applications."

If Google had ignored the discovery completely -- or if they had replied and said that it was too low of a security priority to fix -- that probably would have settled the issue, whether we agreed or not. This is, after all, not exactly a sky-is-falling security hole -- in any case not as long as the "1234 5678" security hole allows people to find credit cards almost as easily.

But once Google decided to fix the bug, there would seem to be no excuse for snubbing the person who discovered it. Even though the fix was probably simple at the code level, pushing a code change through to the almighty Google search engine, is presumably not cheap. If they're going to incur the costs of fixing the bug, what could be the reason for not crediting the discoverer and paying the bounty, which would also establish a good future relationship with a smart bug hunter? (Presumably that's one of the reasons the program exists.)

Maybe both of the original emails to security@google.com got lost, and maybe that has to do with the high volume of emails that the email address receives. I have no idea how those emails are processed internally at Google, but I assume it's likely that there is a pool of security experts to review the incoming emails, and each incoming mail is randomly assigned to one of those experts. If Google wants to reduce the chance of a legitimate bug slipping through the cracks without spending any extra money, my suggestion would be:

Instead of having each email be reviewed by one person chosen at random from a pool of highly paid security experts, have each email be reviewed by five people chosen from a low-paid pool of smart but inexperienced employees. The group of five would each independently vote "Yes" or "No" on whether the security issue needed to be bumped up, with a majority making the decision.

This recommendation is based on two principles. First, if you do a majority vote from a group of five, this reduces the chance of a legitimate issue being mis-categorized by a fluke. If a single "expert" categorizes an issue report correctly 90% of the time, and an intern categorizes an issue correctly 80% of the time, then taking a majority vote from a group of five interns will yield the right answer more often than a single expert. (I'm hand-waving over a few details -- I'm assuming that the probability of the different interns categorizing the issue correctly, are independent, and I'm not weighing the relative cost of missing a legitimate issue versus raising a false alarm -- but the general principle still applies.)

Second, while it may take an experienced security researcher to understand the deeper implications of a bug and the cost of fixing it, in my experience most smart people can quickly see what constitutes a legitimate security hole and what is merely a decoy, even without a lot of coding experience. So it would be ideal work for interns or new employees who want to learn more about the kinds of security reports that come in.

That suggested fix is just based on my assumption that incoming emails to security@google.com are each reviewed by a single person, so that one oversight can cause an email to slip through the cracks.

On the other hand, when someone at Google did read the blog post or the forum question and discover the bug, I have no idea what sequence of events that kicked off, which led to the security hole being plugged without acknowledging the discoverer. That's another process that should be fixed.

Google, of course, deserves credit for fixing the bug, and generally for taking on the issue of filtering credit card searches in the first place. Blocking these searches, after all, mainly prevents harm to others by averting identity theft, without really benefitting Google directly; presumably they filter these searches due to some combination of (1) wanting to be a good corporate netizen and (2) not wanting their search tool abused by script kiddiez searching for credit cards (a class of users who would be singularly unlikely to click on the ads). But since they did fix the bug, they should pay the discoverer, or at least give Gergely a shout-out. If they ever decide to implement my intern-majority-rules idea for emails to security@google.com, a shout-out for that would be fine too.

Frequent contributor Bennett Haselton writes: "Google has fixed a vulnerability, first discovered by researcher Gergely Kalman, which let users search for credit card numbers by using hex number ranges. However, Google should have acknowledged or at least responded to the original bug finder (and possibly even paid him a bounty for it), and should have been more transparent about the process in general." Read on for the rest of the story.

Back in 2007, I wrote that it was possible to find credit card numbers on Google by searching for the first 8 digits of your credit card number with a space in the middle, e.g. "1234 5678". Some users pointed out in the comments that it was even easier to find card numbers by searching for a number range such as

4147000000000000..4147999999999999

At some point after that discovery was posted, Google altered their search filters so that using number ranges to search for credit cards, was no longer allowed. If you search for that range, you get a denial page which reads

Our systems have detected unusual traffic from your computer network. Please try your request again later.

According to security researcher Gergely Kalman, he had read my 2007 article and thought about the issue occasionally for a few years, then in December 2012 discovered a loophole in Google's search filter: He could search for number ranges matching credit cards by searching using hexadecimal numbers. So that instead of searching for

4060000000000000..4060999999999999

he could search for the same number range in hexadecimal:

0xe6c8c69c9c000..0xe6d753e6ecfff

and Google would allow the search, and return a list of matching pages (most of which contained credit card numbers).

Gergely sent an email to security@google.com on December 28, 2012 (which he later showed to me), describing the vulnerability in detail. After describing the simple trick, his email stated: "I don't know if this qualifies as a bug bounty bug, but I think it's certainly not in your interest to let these queries through. Using this method one can bypass all your numerical query filters, filters for SSN, TFN, credit cards, maybe DoS prevention and others I can not think of at the moment."

Gergely sent them a follow-up email on August 23, 2013. In both cases he said he received no response except for an auto-reply.

Then on November 8, 2013, I wrote another article bringing up the fact that the original "1234 5678" trick still made it easy to find credit card numbers through Google, and generally wondering if that particular issue was ever going to be fixed (while remaining unaware of Gergely's discovery).

Gergely saw the article, and subsequently posted his discovery publicly on November 12, along with disclosing the fact that he had written to Google and never received a response:

"So I notified Google, and waited. After a month without a response, I notified them again to no avail. With a minor tweak on Haselton's old trick, I was able to Google Credit Card numbers, Social Security numbers, and any other sensitive information."

Gergely emailed me about my article and sent me a link to his blog post. With Gergely's permission, I posted a message in Google's product forums on November 14th, describing the problem and trying to bring it to the attention of a Google employee:

"This is a security issue that I'm trying to bring to the attention of a Google employee. I'm not sure if it fits under 'malware,' but I couldn't find a better place to post it. The original discoverer already emailed security@google.com twice and says he received no response.
[...]
The original discoverer posted about this trick here:
http://www.toptal.com/web/with-a-filter-bypass-credit-card-numbers-are-still-still-google-able

Can we get confirmation from someone at Google that they're aware of this issue, regardless of what they decide to do about it?
Thanks!"

At the same time, I became curious if Google would fix the bug any time in the next couple of days, so I set up a daily reminder on my computer to click the hex-search-link every morning and see if it was blocked. So I checked every morning from November 15th until about November 20th, and then didn't bother for a few days after that. When I checked again on November 26th, the bug had been fixed, and searching on Google for a hexadecimal-number range matching credit card numbers, now gives the denial message:

Our systems have detected unusual traffic from your computer network. Please try your request again later.

Since Google didn't fix the bug for 11 months after first being notified by Gergely, but then fixed it within 2 weeks after Gergely's blog post and my forum question, it seems pretty certain that the blog post or the forum question was what triggered the fixing of the bug. But, then, why not acknowledge either with a response, or a bounty award for Gergely? According to the chart on Google's Application Security bounty program page, it should probably qualify for a $500 reward in the category "XSRF, XSSI and other common web flaws" under "Normal Google applications."

If Google had ignored the discovery completely -- or if they had replied and said that it was too low of a security priority to fix -- that probably would have settled the issue, whether we agreed or not. This is, after all, not exactly a sky-is-falling security hole -- in any case not as long as the "1234 5678" security hole allows people to find credit cards almost as easily.

But once Google decided to fix the bug, there would seem to be no excuse for snubbing the person who discovered it. Even though the fix was probably simple at the code level, pushing a code change through to the almighty Google search engine, is presumably not cheap. If they're going to incur the costs of fixing the bug, what could be the reason for not crediting the discoverer and paying the bounty, which would also establish a good future relationship with a smart bug hunter? (Presumably that's one of the reasons the program exists.)

Maybe both of the original emails to security@google.com got lost, and maybe that has to do with the high volume of emails that the email address receives. I have no idea how those emails are processed internally at Google, but I assume it's likely that there is a pool of security experts to review the incoming emails, and each incoming mail is randomly assigned to one of those experts. If Google wants to reduce the chance of a legitimate bug slipping through the cracks without spending any extra money, my suggestion would be:

Instead of having each email be reviewed by one person chosen at random from a pool of highly paid security experts, have each email be reviewed by five people chosen from a low-paid pool of smart but inexperienced employees. The group of five would each independently vote "Yes" or "No" on whether the security issue needed to be bumped up, with a majority making the decision.

This recommendation is based on two principles. First, if you do a majority vote from a group of five, this reduces the chance of a legitimate issue being mis-categorized by a fluke. If a single "expert" categorizes an issue report correctly 90% of the time, and an intern categorizes an issue correctly 80% of the time, then taking a majority vote from a group of five interns will yield the right answer more often than a single expert. (I'm hand-waving over a few details -- I'm assuming that the probability of the different interns categorizing the issue correctly, are independent, and I'm not weighing the relative cost of missing a legitimate issue versus raising a false alarm -- but the general principle still applies.)

Second, while it may take an experienced security researcher to understand the deeper implications of a bug and the cost of fixing it, in my experience most smart people can quickly see what constitutes a legitimate security hole and what is merely a decoy, even without a lot of coding experience. So it would be ideal work for interns or new employees who want to learn more about the kinds of security reports that come in.

That suggested fix is just based on my assumption that incoming emails to security@google.com are each reviewed by a single person, so that one oversight can cause an email to slip through the cracks.

On the other hand, when someone at Google did read the blog post or the forum question and discover the bug, I have no idea what sequence of events that kicked off, which led to the security hole being plugged without acknowledging the discoverer. That's another process that should be fixed.

Google, of course, deserves credit for fixing the bug, and generally for taking on the issue of filtering credit card searches in the first place. Blocking these searches, after all, mainly prevents harm to others by averting identity theft, without really benefitting Google directly; presumably they filter these searches due to some combination of (1) wanting to be a good corporate netizen and (2) not wanting their search tool abused by script kiddiez searching for credit cards (a class of users who would be singularly unlikely to click on the ads). But since they did fix the bug, they should pay the discoverer, or at least give Gergely a shout-out. If they ever decide to implement my intern-majority-rules idea for emails to security@google.com, a shout-out for that would be fine too.

Frequent contributor Bennett Haselton writes: "Google has fixed a vulnerability, first discovered by researcher Gergely Kalman, which let users search for credit card numbers by using hex number ranges. However, Google should have acknowledged or at least responded to the original bug finder (and possibly even paid him a bounty for it), and should have been more transparent about the process in general." Read on for the rest of the story.

Back in 2007, I wrote that it was possible to find credit card numbers on Google by searching for the first 8 digits of your credit card number with a space in the middle, e.g. "1234 5678". Some users pointed out in the comments that it was even easier to find card numbers by searching for a number range such as

4147000000000000..4147999999999999

At some point after that discovery was posted, Google altered their search filters so that using number ranges to search for credit cards, was no longer allowed. If you search for that range, you get a denial page which reads

Our systems have detected unusual traffic from your computer network. Please try your request again later.

According to security researcher Gergely Kalman, he had read my 2007 article and thought about the issue occasionally for a few years, then in December 2012 discovered a loophole in Google's search filter: He could search for number ranges matching credit cards by searching using hexadecimal numbers. So that instead of searching for

4060000000000000..4060999999999999

he could search for the same number range in hexadecimal:

0xe6c8c69c9c000..0xe6d753e6ecfff

and Google would allow the search, and return a list of matching pages (most of which contained credit card numbers).

Gergely sent an email to security@google.com on December 28, 2012 (which he later showed to me), describing the vulnerability in detail. After describing the simple trick, his email stated: "I don't know if this qualifies as a bug bounty bug, but I think it's certainly not in your interest to let these queries through. Using this method one can bypass all your numerical query filters, filters for SSN, TFN, credit cards, maybe DoS prevention and others I can not think of at the moment."

Gergely sent them a follow-up email on August 23, 2013. In both cases he said he received no response except for an auto-reply.

Then on November 8, 2013, I wrote another article bringing up the fact that the original "1234 5678" trick still made it easy to find credit card numbers through Google, and generally wondering if that particular issue was ever going to be fixed (while remaining unaware of Gergely's discovery).

Gergely saw the article, and subsequently posted his discovery publicly on November 12, along with disclosing the fact that he had written to Google and never received a response:

"So I notified Google, and waited. After a month without a response, I notified them again to no avail. With a minor tweak on Haselton's old trick, I was able to Google Credit Card numbers, Social Security numbers, and any other sensitive information."

Gergely emailed me about my article and sent me a link to his blog post. With Gergely's permission, I posted a message in Google's product forums on November 14th, describing the problem and trying to bring it to the attention of a Google employee:

"This is a security issue that I'm trying to bring to the attention of a Google employee. I'm not sure if it fits under 'malware,' but I couldn't find a better place to post it. The original discoverer already emailed security@google.com twice and says he received no response.
[...]
The original discoverer posted about this trick here:
http://www.toptal.com/web/with-a-filter-bypass-credit-card-numbers-are-still-still-google-able

Can we get confirmation from someone at Google that they're aware of this issue, regardless of what they decide to do about it?
Thanks!"

At the same time, I became curious if Google would fix the bug any time in the next couple of days, so I set up a daily reminder on my computer to click the hex-search-link every morning and see if it was blocked. So I checked every morning from November 15th until about November 20th, and then didn't bother for a few days after that. When I checked again on November 26th, the bug had been fixed, and searching on Google for a hexadecimal-number range matching credit card numbers, now gives the denial message:

Our systems have detected unusual traffic from your computer network. Please try your request again later.

Since Google didn't fix the bug for 11 months after first being notified by Gergely, but then fixed it within 2 weeks after Gergely's blog post and my forum question, it seems pretty certain that the blog post or the forum question was what triggered the fixing of the bug. But, then, why not acknowledge either with a response, or a bounty award for Gergely? According to the chart on Google's Application Security bounty program page, it should probably qualify for a $500 reward in the category "XSRF, XSSI and other common web flaws" under "Normal Google applications."

If Google had ignored the discovery completely -- or if they had replied and said that it was too low of a security priority to fix -- that probably would have settled the issue, whether we agreed or not. This is, after all, not exactly a sky-is-falling security hole -- in any case not as long as the "1234 5678" security hole allows people to find credit cards almost as easily.

But once Google decided to fix the bug, there would seem to be no excuse for snubbing the person who discovered it. Even though the fix was probably simple at the code level, pushing a code change through to the almighty Google search engine, is presumably not cheap. If they're going to incur the costs of fixing the bug, what could be the reason for not crediting the discoverer and paying the bounty, which would also establish a good future relationship with a smart bug hunter? (Presumably that's one of the reasons the program exists.)

Maybe both of the original emails to security@google.com got lost, and maybe that has to do with the high volume of emails that the email address receives. I have no idea how those emails are processed internally at Google, but I assume it's likely that there is a pool of security experts to review the incoming emails, and each incoming mail is randomly assigned to one of those experts. If Google wants to reduce the chance of a legitimate bug slipping through the cracks without spending any extra money, my suggestion would be:

Instead of having each email be reviewed by one person chosen at random from a pool of highly paid security experts, have each email be reviewed by five people chosen from a low-paid pool of smart but inexperienced employees. The group of five would each independently vote "Yes" or "No" on whether the security issue needed to be bumped up, with a majority making the decision.

This recommendation is based on two principles. First, if you do a majority vote from a group of five, this reduces the chance of a legitimate issue being mis-categorized by a fluke. If a single "expert" categorizes an issue report correctly 90% of the time, and an intern categorizes an issue correctly 80% of the time, then taking a majority vote from a group of five interns will yield the right answer more often than a single expert. (I'm hand-waving over a few details -- I'm assuming that the probability of the different interns categorizing the issue correctly, are independent, and I'm not weighing the relative cost of missing a legitimate issue versus raising a false alarm -- but the general principle still applies.)

Second, while it may take an experienced security researcher to understand the deeper implications of a bug and the cost of fixing it, in my experience most smart people can quickly see what constitutes a legitimate security hole and what is merely a decoy, even without a lot of coding experience. So it would be ideal work for interns or new employees who want to learn more about the kinds of security reports that come in.

That suggested fix is just based on my assumption that incoming emails to security@google.com are each reviewed by a single person, so that one oversight can cause an email to slip through the cracks.

On the other hand, when someone at Google did read the blog post or the forum question and discover the bug, I have no idea what sequence of events that kicked off, which led to the security hole being plugged without acknowledging the discoverer. That's another process that should be fixed.

Google, of course, deserves credit for fixing the bug, and generally for taking on the issue of filtering credit card searches in the first place. Blocking these searches, after all, mainly prevents harm to others by averting identity theft, without really benefitting Google directly; presumably they filter these searches due to some combination of (1) wanting to be a good corporate netizen and (2) not wanting their search tool abused by script kiddiez searching for credit cards (a class of users who would be singularly unlikely to click on the ads). But since they did fix the bug, they should pay the discoverer, or at least give Gergely a shout-out. If they ever decide to implement my intern-majority-rules idea for emails to security@google.com, a shout-out for that would be fine too.

alphatel writes "The Swedish company Resarchgruppen has discovered a flaw in the Disqus commenting system, enabling them to identify Disqus users by their e-mail addresses. The crack was done in cooperation with the Bonnier Group tabloid Expressen, in order to reveal politicians commenting on Swedish hate speech-sites."

mask.of.sanity writes "Google has revealed details on its Beyond Corp project to scrap the notion of a corporate network and move to a zero-trust model. The company perhaps unsurprisingly considers the traditional notion of perimeter defense and its respective gadgetry as a dead duck, and has moved to authenticate and authorize its 42,000 staff so they can access Google HQ from anywhere (video). Google also revealed it was perhaps the biggest Apple shop in the world, with 43,000 devices deployed and staff only allowed to use Windows with a supporting business case."

An anonymous reader writes "Mozilla today officially launched Firefox 26 for Windows, Mac, Linux, and Android. Additions include Click-to-Play turned on by default for all Java plugins, more seamless updates on Windows, and a new Home design for Android. Firefox 26 has been released over on Firefox.com and all existing users should be able to upgrade to it automatically. As always, the Android version is trickling out slowly on Google Play. Release notes are here: desktop and mobile."

jones_supa writes "The latest PISA (Programme for International Assessment) results are out today. Since 2000, the OECD has attempted to evaluate the knowledge and skills of 15-year olds across the world through its PISA test. More than 510,000 students in 65 economies took part in the latest test, which covered math, reading and science, with the main focus on math — which the OECD state is a 'strong predictor of participation in post-secondary education and future success.' Asian countries outperform the rest of the world, according to the OECD, with Shanghai, Singapore, Hong Kong, Taiwan, South Korea, Macau and Japan amongst the top performing countries and economies. Students in Shanghai performed so well in math that the OECD report compares their scoring to the equivalent of nearly three years of schooling above most OECD countries. The study shows also a slight gender cap: in all countries, boys generally perform a bit better than girls, but this applies only to math." Here's a spreadsheet listing each country's results. The U.S. ranked 26th in math (below average), 17th in reading (slightly above average), and 21st in science (slightly below average).

Daniel_Stuckey writes "Last month, a company working on behalf of the publisher Random House, asked Google to remove links to a free copy of Stephen King's Carrie from search results. Google complied for three out of the four requested links, but didn't remove Kim Dotcom's new website Mega.co.nz as requested — for even if Mega is hosting pirated copies of Carrie, they sure aren't on the homepage. But leaving that link up was an exception to the rule. More and more, copyright owners and the organizations they employ are cutting off where the websites and the public meet — the search engine. Google's transparency reports show that requests to remove links to copyrighted material rose steadily in 2013. The search giant received 6.5 million requests during the week of November 18, 2013, which is over twice as many as the same week a year ago. Google said it complies with 97 percent of requests." I know someone who had his original work taken down by a Warner Bros DMCA bot (without recourse, naturally, since only lawyers are people nowadays).

An anonymous reader writes "Google has launched the Google Voice Search Hotword extension for Chrome, bringing the 'OK Google' feature to the desktop. You can download the new tool, currently in beta, now directly from the Chrome Web Store. Android users with version 4.4 KitKat will recognize the feature: it lets you talk to Google without first clicking or typing. It's completely hands-free, provided you're already on Google.com: just say 'OK Google' and then ask your question." Quick, someone wire Pocketsphinx up to Firefox, or integrate Simon into Krunner.

An anonymous reader writes "Google has launched the Google Voice Search Hotword extension for Chrome, bringing the 'OK Google' feature to the desktop. You can download the new tool, currently in beta, now directly from the Chrome Web Store. Android users with version 4.4 KitKat will recognize the feature: it lets you talk to Google without first clicking or typing. It's completely hands-free, provided you're already on Google.com: just say 'OK Google' and then ask your question." Quick, someone wire Pocketsphinx up to Firefox, or integrate Simon into Krunner.

Jah-Wren Ryel sends this quote from Ars: "Newegg, an online retailer that has made a name for itself fighting the non-practicing patent holders sometimes called 'patent trolls,' sits on the losing end of a lawsuit tonight. An eight-person jury came back shortly after 7:00pm and found that the company infringed all four asserted claims of a patent owned by TQP Development, a company owned by patent enforcement expert Erich Spangenberg. The jury also found that the patent was valid, apparently rejecting arguments by famed cryptographer Whitfield Diffie. Diffie took the stand on Friday to argue on behalf of Newegg and against the patent. In total, the jury ordered Newegg to pay $2.3 million, a bit less than half of the $5.1 million TQP's damage expert suggested. ... TQP's single patent is tied to a failed modem business run by Michael Jones, formerly president of Telequip. TQP has acquired more than $45 million in patent licensing fees by getting settlements from a total of 139 companies since TQP argues that its patent covers SSL or TLS combined with the RC4 cipher, a common Internet security system used by retailers like Newegg."

Nerval's Lobster writes "The Vatican, while notoriously secretive about things buried in its vaults and archives, is being as public as the digital age allows it to be about the nearly completed restoration of catacombs early Christians used as secret churches as well as burial sites. Contractors, archaeologists and art experts spent the past five years restoring the Priscilla catacombs under the Vatican using lasers, among other techniques, to restore frescoes painted on the walls of the burial chambers. The Vatican unveiled the work Nov. 19 with a press conference in the Basilica of San Silvestro outside the burial tunnels, accompanied by a virtual tour of the Priscilla catacombs provided by Google Maps. The basilica is divided into an area for religious services and another that acts as a deposit for sculptures and artifacts dug up during excavations of the catacombs and other areas underneath the Vatican."

An anonymous reader writes "Google has extended its proactive Patch Reward Program to include even more open-source software. Among them is the Android Open Source Project, which the company previously did not reveal was going to be added. Last month, Google started providing financial incentives (between $500 and $3,133.70) for proactive improvements to OSS that go beyond merely fixing a known security bug. Google said at the time it would be rolling out the program gradually, and hinted that more project types would be on the way."

Trailrunner7 writes "Buried underneath the ever-growing pile of information about the mass surveillance methods of the NSA is a small but significant undercurrent of change that's being driven by the anger and resentment of the large tech companies that the agency has used as tools in its collection programs. The changes have been happening since almost the minute the first documents began leaking out of Fort Meade in June. When the NSA's PRISM program was revealed this summer, it implicated some of the larger companies in the industry as apparently willing partners in a system that gave the agency 'direct access' to their servers. Officials at Google, Yahoo and others quickly denied that this was the case, saying they knew of no such program and didn't provide access to their servers to anyone and only complied with court orders. More recent revelations have shown that the NSA has been tapping the links between the data centers run by Google and Yahoo, links that were unencrypted. That revelation led a pair of Google security engineers to post some rather emphatic thoughts on the NSA's infiltration of their networks. It also spurred Google to accelerate projects to encrypt the data flowing between its data centers. These are some of the clearer signs yet that these companies have reached a point where they're no longer willing to be participants, witting or otherwise, in the NSA's surveillance programs."

itwbennett writes "The FCC's new Android app will allow users to measure the speed of their mobile broadband connection, while providing aggregate data to the agency for measuring nationwide mobile broadband network performance. Released as open-source software on Thursday, the free FCC Speed Test App will test network performance for parameters such as upload and download speed, latency and packet loss. An iPhone version of the app is in the works."

theodp writes "'Why do programmers start counting at zero?' wondered Mike Hoye, questioning the conventional programming wisdom. Code.org will soon introduce the practice to a hoped-for audience of 10 million schoolchildren as part of Computer Science Education Week's Hour of Code. In a tutorial created by engineers from Microsoft, Google, Twitter and Facebook that's intended to introduce programming to kids as young as six years old, an otherwise breezy lesson featuring look-ma-no-typing Blockly and characters out of Angry Birds and Plants vs. Zombies, a Mark Zuckerberg video introducing the concept of Repeat Loops includes an out-of-place JavaScript example that shows kids it's as easy as 0-1-2-3 to generate 4 lines of lyrics from Happy Birthday to You by using zero-based numbering with a For-loop and ternary If statement. Accompanying videos by Bill Gates on If Statements and basketball star Chris Bosh on Repeat Until Blocks show the Code.org tutorial is still a work-in-progress. That's no big deal, since CSEdWeek has pushed back the delivery date for final Hour of Code tutorials from its prior little-time-for-testing due date to Dec. 9th, the first day of a five-day period during which teachers are expected to deliver the lessons to 10 million students."