Google Fixes Credit Card Security Hole, But Snubs Discoverer 127
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.
Doesn't make sense (Score:3)
Why are these pages even indexed? Wouldn't it make more sense to just expunge them from the database (perhaps by hostname or even domain name as appropriate) rather than keep them around waiting for someone to figure out a way to trick Google into retrieving them?
Re:Doesn't make sense (Score:4, Interesting)
Google. They are a search engine. They are supposed to index stuff, not to censor it. It's the problem of the fucktards whose site security is so bad that a search engine can get to customer data like such (or the fucktards who leak such things on purpose). I really don't see why Google cares abbot it, and why do other retards classify this as a "security hole". It's not Google who is leaking the data, so why is it upon them to fix it? If I were running a search engine, I'd be fighting requests for such "improvements" tooth and nail. People need to realize how insecure some sites/servers are, and who is to better expose it than a large search engine. Sigh.
Re: (Score:1)
What's stopping you? Last time I heard IMAP was pretty easy to master. Wait, is it because other providers don't offer it for free?
If it was up to me not only would I let those searches trough but also make a nice list of all the fucking idiots who leak private customer data like this. Maybe so the retards running those sites would move on from the "who would guess the link?" security model.
Can someone please explain the law (US)? (Score:5, Interesting)
I still don't get it. When do you go to jail for this [wired.com], and when don't you?
Namely- do you go to jail when...
Is it arbitrary? It seems sometimes you get a reward/bounty, sometimes a thank you, sometimes a threat, and other times you get sent to jail...
What does a reasonable/prudent person do if they stumble onto a potential (or actual) security hole in someone else's system? Someone explain please.
Re:Can someone please explain the law (US)? (Score:5, Informative)
You get all of the above depending on what company/organization you're dealing with. If you're dealing with an entity that has an open attitude about these things, you'll get a reward or a pat on the back. If you're dealing with a private company that isn't open and has a monopoly to protect you'll get usually a CFAA indictment for accessing their system in an inappropriate way...
Re: (Score:1)
You become aware of a security bug?
I manage a motel. The room locks are resistant to shims and cheap lockpicks. They are not resistant to crowbars or skilled locksmiths. Nobody has told me that's a "security bug"
Here's a short checklist for covering a website against the equivalent of shims and cheap lockpicks without going to the effort of keeping out the crowbars and the NSA...
1) Put the "no robots" tag on webpages that you don't want appearing in Google searches (rule of thumb: if it doesn't have a picture in it, you don't want it appearing when people search for you anyway).
2) Put a robot trap onto any page that leads to anything particularly valuable, or maybe just lay them everwhere that you have the no robot
Re: (Score:3)
1) Put the "no robots" tag on webpages that you don't want appearing in Google searches (rule of thumb: if it doesn't have a picture in it, you don't want it appearing when people search for you anyway).
WTF?
Re: Can someone please explain the law (US)? (Score:1)
Great so another bug fixed but... (Score:2)
Why in the hell is Google indexing credit card numbers to being with? I realize their bots sniff the web but this is information that they should just avoid collecting.
Re: (Score:3)
They index the web, and already censor credit card numbers to some extent, and you want more censoring of them? That seems pretty arbitrary and likley to have false positives.
Yea, well, better to let 10 guilty hashes go free than let one innocent CC number suffer.
Re:Great so another bug fixed but... (Score:5, Insightful)
The better question is this:
Why is this information even stored in plain text and publicly accessible where it can be indexed in the first place?
Re: (Score:2)
while a good question, I don't think it is a better one.
Clearly it shouldn't be. EVERYONE here agrees on that. The point is that due to Google's technical expertise and business product, they are in a position to significantly reduce the ease at which people can come accross these "powerful" numbers.
Re:Great so another bug fixed but... (Score:5, Insightful)
plenty of good reasons to index long strings of numbers. I use google for part numbers, serial numbers, etc.
Re: (Score:2)
Re: (Score:3)
Very true, although I would think a rather small minority would be 16 digits long and pass the Luhn test.
10% of random 15 and 16-digit numbers pass the Luhn test.
Re: (Score:2)
The point was that given a random 12-16 digit number, it's not very likely that it will be a valid credit card number (even if the check digit passes), and even
Re: (Score:2)
no, making 10% of a catalog with 15 to 19 digit numbers is not acceptable solution. the core problem is stupidity of using a credit card number at all for financial transactions, already a long solved crytographic problem. the credit card companies need to stop using a stupid system, just as government needs to stop using social security numbers. fix what's broken, don't put bandaids on a bridge.
Re: (Score:2)
meant to say making 10% of catalog with 15 to 19 digit numbers unavailable is not acceptable solution
Re:Great so another bug fixed but... (Score:4, Interesting)
Why should they avoid collecting fucking numbers? Why is it their problem? What other information they "should just avoid collecting". It's a very slippery slope I'd them rather not take. If it takes Google to get the U.S. credit card industry to wake up and realize that people need to use secure chip cards for physically-present transactions and secure pin generators for card-not present ones, like is done in a lot of more bank-developed places on Earth, then so let it be. The fallout from having those numbers visible for all to see can't be but beneficial for the consumer in the long term.
Re: (Score:1)
Look, numbers are fine but when they're mining it from sites that publish and peddle lists of Card Numbers and CVV2 info, that's another thing. Those sites have no other business than to promote crime. It's the same thing with Child Porn and other things that have been banned from search engines. Nobody likes censorship but there are things that should be filtered based upon good business practice and being a responsible corporate citizen. Google is smart enough to build filters to know that what they're
What bug? (Score:2)
This makes no sense. What bug? You searched for numbers you got the numbers. Sounds like google was working correctly at first and broken, not fixed, as the story went on.
The people who put pages of credit card numbers on the web like this have a problem, but it isnt googles problem, google cant fix it, and it's insane that they are expected to do so.
Re: (Score:2)
"Simple question: Why should Google filter or censor anything? Do we even want that?"
Simple answer. No. Hell no.
This accomplishes nothing (Score:5, Insightful)
The problem is not that google accidentally lets you search for credit card numbers. Not at all.
The problem is that credit card numbers is published on the web so that search engines and anybody else can find them. Google can filter queries perfectly, but the numbers are still out there on some webpage - for some reason. If google won't let me search for numbers, then I can switch to another search engine. Google is far from the only one - it is merely the most popular one. (Google "search engines" to find some others.) Chances are the others are not so restrictive.
And of course I don't really need a search engine - I can make my own web crawler. A search engine like google is a big thing, but a web crawler that collect credit card numbers only is much simpler - it is something you can run from home.
So google: Please don't filter out card numbers from your searches. The fault does not lie with google, but with those who put credit card numbers on the web for all to see. If we can find them, we can warn them or even sue them. Let the searches go through, so they can get busted. Or so those numbers will get abused. That way, people might learn not to publish them.
Also, number searches are useful. I often search for product numbers, which sometimes have the same length as credit card numbers. This is "normal use", not hacking at all.
Re: (Score:2)
Same goes for bank account numbers - in the U.S., they are supposed to be kept private. Why? Because anyone can suck your account dry if they just have your account number! That's why. Sad but true.
Re: (Score:2)
Credit card payments based solely on a number without some additional form of authentication is an obsolete form of payment.
Yet that's precisely how it's done in the U.S. You put in a bunch of numbers that are static and your payment goes through. It's going full retard, but the "industry" just doesn't care.
Re: (Score:2)
Re: (Score:2)
Maybe that's why you're broke. Maybe it isn't Obama's fault.
Re: (Score:2)
Yes, and anyone less than scrupulous could use that to empty your account. If I wanted to transfer money to you, and called your bank and asked for your account number, they wouldn't give it out saying it's private, protected stuff. Basically the only reason you have not been screwed yet is that everyone who handled your check happened not to be a fraudster. Seriously, it's that bad. That's also why corporations don't print their account numbers on stationery in the U.S. They'd get a talking-to from their b
Re: (Score:2)
Your bank account and routing number are printed on every single paper check. There is no way that they were intended to be or can expected to be "secure" or private.
They are indeed meant to be private!!! In SPITE of being on the checks! Checks are supposed to be handled like confidential/sensitive documents! It's a big nod-and-wink scheme, kludged so bad that some localities have laws against disclosure of such numbers - just to work around the holes in the system in hope of discouraging at least local small-time fraudsters.
Elsewhere in the world, businesses put their account numbers on their stationery and websites. In the U.S. you don't do it, because anyone can use
Re: (Score:2)
So google: Please don't filter out card numbers from your searches. The fault does not lie with google, but with those who put credit card numbers on the web for all to see.
I think Google did take that approach for several years, and it was found not to work. Specifically, the pages with all the card numbers didn't get taken down, and Google search made it trivial for people to find lots of potentially-valid CCNs.
Re: (Score:1)
The bigger issue is (Score:4, Insightful)
Re: (Score:3)
wrong. the bigger issue is why we are so silly as to use short 15 or 16 digit numbers for making financial transactions. it's the same as the stupidity shown with using social security numbers.
Re: (Score:3)
wrong. the bigger issue is why we are so silly as to use short 15 or 16 digit numbers for making financial transactions. it's the same as the stupidity shown with using social security numbers.
If your CC number is on a web-facing interface in plaintext, I doubt it matters much whether it's 16 digits or 256.
Re: (Score:2)
you're not getting it. there would be no single unique number, only lasting thing would only be encrypted message summarizing single transaction. you could post it on the web, wouldn't do a thief any good. the transaction would be done by secure cryptographic means, we've mastered that already, solved problem.
Re: (Score:2)
I see - less a dedicated number, and more like an OTP.
Seems like a good idea, but I can't see how it would ever work, considering that such a system would require a lot of big players to learn how to work together for the common good.
Re: (Score:2)
mandate it by law in the the USA and EU and it would be a done deal for the planet.
Re: (Score:2)
wrong. the bigger issue is why we are so silly as to use short 15 or 16 digit numbers for making financial transactions.
It's not the length that's the problem, it's the fact that we use the same value as both identifier and authenticator.
Re: (Score:2)
I thought the identifier was the 15 or 16 digit number on the front of the card, and the authenticator was the three-to-four digit number on the back of the card (except in cases where a keypad is available, and then the identifier is the 15 or 16 digit number encoded on the mag strip and the authenticator is your 4 digit pin).
Re: (Score:2)
I thought the identifier was the 15 or 16 digit number on the front of the card, and the authenticator was the three-to-four digit number on the back of the card (except in cases where a keypad is available, and then the identifier is the 15 or 16 digit number encoded on the mag strip and the authenticator is your 4 digit pin).
Nah, there are ways you can use the card number without the CVV1 or CVV2. And it's not like a three-digit authenticator adds very much security (more length there actually would help).
Re: (Score:1)
(more length there actually would help).
Yeah, I've heard that before.
Re: (Score:2)
still completely insecure. transactions need to be done with 3-way private key cryptography system. it's a solved problem
Re: (Score:2)
you're cluesless. there would be no cc number, there would be a long number that encoded a single transaction as summary. you could post it on the web, would be useless for theft
Re: (Score:1)
Bennett, Please Read... (Score:5, Insightful)
The Elements of Style [amazon.com]. Your ponderous prose is an affront to literacy. Every time I see that you've posted something I wonder if you've finally realized that quantity does not equal quality. You may get paid by the word elsewhere, but not here.
I might even bother to read what you write if you would just, for the sake of all that is good in this world, be concise. ARRRGGGHHH!
Re: (Score:1)
Re: (Score:2)
fwiw, i think the biggest issue is virtually every other article on slashdot is a summary with a link to the article(s) ...(well on a good day in an idealized imagining of how Slashdot works - we're lucky if the summary makes sense, summarizes the acutal article, and provides links to anything remotely agreeing with the summary... but I digress), except your submissions. Which seem to always be a full mufti-page article in place of the usual "summary".
Its off putting; both because it deviates from the norm,
Re: (Score:1)
There are three kinds of longer article on Slashdot:
- Book reviews
- The As from "celebrity" Q+As
- Bennet Haselton opinion pieces
It's a strange mix.
Re: (Score:2)
Re: (Score:2)
I thought there were other original content pieces being run, although I never see them.
So that makes two of who have never seen them.
The only other long form articles I can actually recall seeing are celeb Q&A answers, and book reviews.
But surely it's more convenient for the readers to click through to an article on Slashdot t
Not having a concise 2 paragraph summary makes them unequivocally less convenient for us to decide whether we WANT to read it.
And it also avoids bifurcating the discussion
I'm no
Re: (Score:1)
But surely it's more convenient for the readers to click through to an article on Slashdot t
Not having a concise 2 paragraph summary makes them unequivocally less convenient for us to decide whether we WANT to read it.
There is a short summary that appears on the front page (or wherever the article is linked from) before the link to the article. In this case it was:
"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.
Re: (Score:2)
There is a short summary that appears on the front page (or wherever the article is linked from) before the link to the article.
True. So I guess its not the lack of summary that's the biggest issue, just the apparent arrogance inherent in the appearance of using /. as your personal blog.
Re: (Score:2)
reasons should be in terms of costs and benefits.
I thought it was evident, but apparently you wish me to spell it out for you:
The cost is the goodwill you are losing as your audience perceives you to be arrogantly using /. as your personal blog.
The cost is the audience itself protesting you and your special treatment articles, distracting the conversation away from the article to a conversation about you and your 'special status' with the /. editors. You were worried about bifurcation, and you traded it for
Re: (Score:2)
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."
Re: (Score:2)
I'll bite. FTFA: 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. There's really no reason for the last two sentences to be in a separate paragraph, and this is something that is common in the way you write. From The Elements of Style: "In general, remember that paragraphing calls for a good eye as well as a logical mind. Enormous blocks of print look formidable to readers, who are often reluctant to tackle them. Therefore, breaking long paragraphs in two, even if it is not necessary to do so for sense, meaning, or logical development, is often a visual help. But remember, too, that firing off many short paragraphs in quick succession can be distracting. Paragraph breaks used only for show read like the writing of commerce or of display advertising. Moderation and a sense of order should be the main considerations in paragraphing." (emphasis mine)
Thanks for picking that up NormalVisual. You're absolutely correct. I was just going to ignore Mr. Haselton's ridiculous question about paragraphs because it's not really the paragraphing that annoys me.
What really annoys me is the verbosity and lack of semantic content in his prose. I suggested "The Elements of Style" because he clearly isn't going to go away and thought he might learn something about writing clearly and concisely.
Mr. Haselton's posts (IMHO) appear to be written for a general audience,
Re: (Score:1)
Re: (Score:2)
Do you have an example of what you're referring to?
Yes. All of your posts.
Re: (Score:2)
You're very articulate; now, do you have a specific example of a sentence or paragraph that is evidence of the claims you're making?
I'm not your English tutor. I'm not really interested in getting involved with you or your crappy prose. However, I am an honest and charitable guy so I gave you some constructive criticism. I already made specific comments about what I saw in your current post. If you can't extrapolate from there, I take back what I said about you not being an idiot.
Re: (Score:1)
Re: (Score:2)
Re:Bennett, Please Read... (Score:5, Insightful)
Most of them. This article boils down to:
"Google was returning credit card numbers in their search results. I wasn't happy about that, and wrote a blog entry about it. Google then changed their search results a bit to reduce these kinds of search results. A security researcher wrote to me to say that he found there were still ways to get card numbers in the search results. He wrote to Google to tell them about this and got no meaningful response. Fast forward several months - I posted in a Google forum about this issue, quoting the researcher, and a couple of weeks later Google fixed this issue. I'm not happy that neither he nor I got any credit for it or received a reward from the bug bounty program (even though this wasn't a bug and was a personal issue with the search results that were returned from a valid query), because I'm quite sure I'm the one to which they were responding when they "fixed" the query results. Here are some further ideas I have for improving the way these results are computed, and you should pay attention because I'm Bennett Haselton."
So what does everyone think?
Re: (Score:2)
You're hired.
Now, who are you going to replace? Samzenpus, Timothy, Soulskill, Commander Taco?
Re: (Score:1)
For example, saying it's "not a bug" has no supporting argument. I said in the article that since Google decided to block the original number-range searches, that means they had implicitly declared that one of their design goals was to block searches that match lots of credit card numbers. If that's a design goal, t
Re: (Score:2)
You're totally missing the point. Slashdot "articles" are supposed to be a SHORT SUMMARY of a given newsworthy item, so the detailed arguments that lead to your conclusions are neither necessary nor appropriate there. You can always link to your own blog (or a Slashdot journal) where one can examine your analysis in further detail if readers are interested enough. Slashdot is a tech news aggregation site, not your o
Re: (Score:1)
Well, at that point you're essentially saying I should set up a second domain just for hosting the supporting-argument portion, so that the intro text can link to that off-site domain, and then the content would be exactly
Regex is cool, but you can still do this... (Score:3)
Re: (Score:2)
Re: (Score:2)
You mean, no one thought about automating the 7 proxies trick before?
DiscoverER? (Score:1)
n/t
Not a Security Bug (Score:2)
Sorry, but Google filtering is simply doing everyone a favour by helping mitigate credit card fraud. Users of Google products and services were in no way at risk prior to the filtering change.
Why would they acknowledge this? They don't publically acknowledge people flagging inappropriate images and this falls in the same category.
I don't know if this qualifies as a bug bounty bug (Score:2)
"Should have rewarded him" (Score:2)
He should just count himself lucky that he's not being sued and leave it at that.
Not a bug (Score:2)
This is Google's search working as intended: finding stuff on the internet. It isn't their fault that sensitive information is publicly disclosed for an undiscriminating indexer to find.
Snubs Discover -nobody likes that card! (Score:2)
Discover doesn't get much love
-I'm just sayin'
It is possible Google hasnt changed anything (Score:3)
Google uses automatic systems to try to detect "abusive" queries. When the system is triggered, you get the message "Our systems have detected unusual traffic from your computer network. Please try your request again later.".
Searching for the same random hex string every day for a week that nobody else in the world has searched for would probably make you stand out from the crowd as some kind of bot. (Bots often use google search looking for random keywords to check for updates to their own code, and the bot-owner can then put the software update anywhere on the internet with the right random keywords and it will be found).
When you have triggered the bot-detect code, it will probably get more sensitive ("look mom, I learned to detect a type of malware, and I'm gonna make sure it never gets through again!").
Hence, I have a suspicion that the entire content of this post could have happened without any interaction on the part of Google Engineers. And if thats the case, they really shouldn't get blamed for screwing over a little guy, but instead praise for making such a smart system that it can detect a little guy doing something evil and block him all automatically.
Re: (Score:2)
Google uses automatic systems to try to detect "abusive" queries. When the system is triggered, you get the message "Our systems have detected unusual traffic from your computer network. Please try your request again later.".
...and the fun really starts when that system misfires.
Maybe take fewer drugs? (Score:2)
And you mightn't think that something that is obviously not a bug is a bug.
Updates (Score:1)