On a faintly related note, I once was calculating partitions, using a relatively inefficient method (memoization: if f(n,k) is the number of distinct ways to express n as the unordered sum of integers no greater than k, then f(n,k) = f(n-k,k) + f(n,k-1)). My computer started to feel the strain in the thousands (this algorithm is O(n^2) in space and time). I then googled for the partition of, say, 1034, which is:
91363785902248291467082481888195
I figured that chances are that no website will have that integer on there by accident. Lo and behold, I found, among other results, a text file containing the partitions up to 10,000, presumably done with a more efficient algorithm (likely Euler's ridiculous pentagonal-number recurrence formula, which, memoized, is roughly O(n^1.5) in time and O(n) in space): http://oeis.org/A000041/b000041.txt
It should be pointed out here for everyone else that in general, if you want terms of a well-known integer sequence, OEIS (and the links section for longer tables like that) is a good place to check.
The double dot indicates that this is a ranged query.
11..22 would be to search for all integers between 11 and 22.
The effect is that the search is too broad. The problem is more likely to be that the range search is a mapreduce that performs a search for each item in the range.
You can imagine why that's a bad idea, and some aggressive timeouts are probably what stop it from going too far.
Plus the numbers in the range of the OP search are likely to fall in the ranges of sensitive numbers, credit cards being the most sensitive... which are likely to be explicitly blocked.
> The effect is that the search is too broad. The problem is more likely to be that the range search is a mapreduce that performs a search for each item in the range.
I'm a bit confused to see this so highly upvoted. I'm not sure you understand what MapReduce is for. MapReduce is not a technology designed for executing a search query in under 100ms, it's for massive data processing jobs. MapReduce is what you would use to do to prepare an index, not to query it.
> You can imagine why that's a bad idea, and some aggressive timeouts are probably what stop it from going too far.
As you yourself noted, this is blocked to prevent people from searching for SSN/credit card/etc. dumps.
The reason for this is that you can google ranges of numbers, and people a couple of years ago were using this feature to find credit card numbers that were posted online, eg searching for 4000000000000000..4999999999999999
You also cannot google some stuff commonly found in phpBB because of so many hacked sites out there.
Also remember how you used to be able to search for anything up to the 1000th item (10 pages of 100 results). Not anymore for a long time now. Google sucks it all in but won't share and play nice with others.
Why not allow such searches unless a bot is detected (too many pages too quickly, etc.)
"With all due respect John, I am the head of IT and I have it on good authority that if you type 'Google' into Google, you can break the Internet." -- The IT Crowd
I think this question is cool to think about and try to answer: What is the lowest integer that doesn't have any hits on google? Is there any reasoning that can help estimating the approximate magnitude it should be?
A problem might be that as soon as you discover that number, you can't tell anyone on the web about it. This for example has no results as of now: http://google.com/search?q=813115181452319
You could look at the hits returned on increasing numbers (eg, 1111 v 11111). A quick glance shows they seem to reduce towards zero by the time you reach 12 digits.
From there, it's probably trial and error - start with 12 1's in a row and fiddle with them. Even try deleting 2 random digits to see what happens (from 12 ->10 as anything with 11 numbers returns a UPS Package Tracking Link / Ad for me). Lowest I had is 111232111222 - perhaps someone should write a Wikipedia page on it?
Can someone please explain me why that happens? Google says - "Our systems have detected unusual traffic from your computer network. Please try your request again later."
I'm guessing there is some kind of grammar parser breaking horribly. There's grammar parsers that have extremely poor performance trying to parse stuff that looks like this. It might do:
search 1 and 111111..11111
search 11 and 11111..11111
...
search 1 and 1 and 11111..111
...
...
...
and google detects that you are DOSing its server.
OK, someone else has pointed out that this is a range search, and google may be protecting CC searches.
Years ago somebody discovered you could Google for credit card numbers that had been left on the web inadvertently, by searching for the right number range. I wonder if that is why it is unavailable.
Reading the comments here gave me an idea....google your own credit card numbers to check if its already in some scammer's index. While no results might not necessarily mean you are safe, a positive match is a clear red flag.
Because what Google is preventing is the discovery of accidental credit cards in it's index.
You searching for credits cards (via that ranged query) is a flag that the search is possibly automated and they display the warning and catchpa as a mitigator.
Probably that string was used as a dork together with some more text to find vulnerabilities on web applications or so.
So it was reported as a honey
This does look like a string that could very much be generated by some poorly coded webbapp. An incorrect usage of a floating point number can easily generate such output. If it occurs on a critical part of an application it could very well been used as a dork. Just an hypothesis though.
Back in 2005 google tricks were at their peak. Many hackers experimented with search phrases in order to retrieve interesting/valuable/uncommon/dangerous?/sensitive info from the web. "index of/ .mp3" "apache server at port" being the absolute classic.
More and more people started to jump in the bandwagon, webmasters gradually became more aware of this, and google too. The natural reaction was google honeypot.
But it wasn't too long until google started to remove such features. These days one can hardly search for symbols on google. They the old tricks, most of them will not work, google simply ignores the details and returns a list of results based on the actual words contained in the query. It's becoming a QA machine. That's one of the reasons I switched to duckduckgo.
[+] [-] waterhouse|14 years ago|reply
[+] [-] Sniffnoy|14 years ago|reply
[+] [-] jwr|14 years ago|reply
[+] [-] wbhart|14 years ago|reply
[+] [-] dimatura|14 years ago|reply
[+] [-] mattdeboard|14 years ago|reply
[+] [-] buro9|14 years ago|reply
11..22 would be to search for all integers between 11 and 22.
The effect is that the search is too broad. The problem is more likely to be that the range search is a mapreduce that performs a search for each item in the range.
You can imagine why that's a bad idea, and some aggressive timeouts are probably what stop it from going too far.
Plus the numbers in the range of the OP search are likely to fall in the ranges of sensitive numbers, credit cards being the most sensitive... which are likely to be explicitly blocked.
[+] [-] hm2k|14 years ago|reply
http://www.google.com/search?q=%229999999..99999999999999999...
[+] [-] threecreepio|14 years ago|reply
[+] [-] adgar|14 years ago|reply
I'm a bit confused to see this so highly upvoted. I'm not sure you understand what MapReduce is for. MapReduce is not a technology designed for executing a search query in under 100ms, it's for massive data processing jobs. MapReduce is what you would use to do to prepare an index, not to query it.
> You can imagine why that's a bad idea, and some aggressive timeouts are probably what stop it from going too far.
As you yourself noted, this is blocked to prevent people from searching for SSN/credit card/etc. dumps.
[+] [-] user24|14 years ago|reply
It was around the time that johnny's google hacking page became popular, iirc. (http://www.hackersforcharity.org/ghdb/)
[+] [-] hm2k|14 years ago|reply
[+] [-] roadnottaken|14 years ago|reply
[+] [-] ck2|14 years ago|reply
Also remember how you used to be able to search for anything up to the 1000th item (10 pages of 100 results). Not anymore for a long time now. Google sucks it all in but won't share and play nice with others.
Why not allow such searches unless a bot is detected (too many pages too quickly, etc.)
[+] [-] david927|14 years ago|reply
[+] [-] martinkallstrom|14 years ago|reply
[+] [-] sovok|14 years ago|reply
[+] [-] JacobAldridge|14 years ago|reply
From there, it's probably trial and error - start with 12 1's in a row and fiddle with them. Even try deleting 2 random digits to see what happens (from 12 ->10 as anything with 11 numbers returns a UPS Package Tracking Link / Ad for me). Lowest I had is 111232111222 - perhaps someone should write a Wikipedia page on it?
http://en.wikipedia.org/wiki/Interesting_number_paradox
[+] [-] Almaviva|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] jergosh|14 years ago|reply
[+] [-] arrowgunz|14 years ago|reply
[+] [-] wisty|14 years ago|reply
111..111 11111..111111
and eventually crashes.
I'm guessing there is some kind of grammar parser breaking horribly. There's grammar parsers that have extremely poor performance trying to parse stuff that looks like this. It might do:
search 1 and 111111..11111
search 11 and 11111..11111
...
search 1 and 1 and 11111..111
...
...
...
and google detects that you are DOSing its server.
OK, someone else has pointed out that this is a range search, and google may be protecting CC searches.
[+] [-] tonyedgecombe|14 years ago|reply
[+] [-] YokoZar|14 years ago|reply
[+] [-] tsycho|14 years ago|reply
[+] [-] andrenotgiant|14 years ago|reply
credit card, or if paranoid, partial credit card # "123456789"
Email address
Home address
Phone number
screen name (e.g.: "andrenotgiant" -site:ycombinator.com)
Bank acct partial
Password, Password partial "p@ssw0r"
[+] [-] iclelland|14 years ago|reply
[+] [-] bgentry|14 years ago|reply
[+] [-] mikkohypponen|14 years ago|reply
[+] [-] iwiznia|14 years ago|reply
[+] [-] mahrain|14 years ago|reply
[+] [-] n0fair|14 years ago|reply
[+] [-] atlbeer|14 years ago|reply
You searching for credits cards (via that ranged query) is a flag that the search is possibly automated and they display the warning and catchpa as a mitigator.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] program|14 years ago|reply
[+] [-] chanux|14 years ago|reply
I know, the point is this happens with 6 digits minimum on each side of ..
[+] [-] yogsototh|14 years ago|reply
[+] [-] mikkohypponen|14 years ago|reply
[+] [-] tete|14 years ago|reply
[+] [-] known|14 years ago|reply
[+] [-] 37prime|14 years ago|reply
[+] [-] drungli|14 years ago|reply
[+] [-] skeptical|14 years ago|reply
This does look like a string that could very much be generated by some poorly coded webbapp. An incorrect usage of a floating point number can easily generate such output. If it occurs on a critical part of an application it could very well been used as a dork. Just an hypothesis though.
Back in 2005 google tricks were at their peak. Many hackers experimented with search phrases in order to retrieve interesting/valuable/uncommon/dangerous?/sensitive info from the web. "index of/ .mp3" "apache server at port" being the absolute classic.
More and more people started to jump in the bandwagon, webmasters gradually became more aware of this, and google too. The natural reaction was google honeypot.
http://ghh.sourceforge.net/
But it wasn't too long until google started to remove such features. These days one can hardly search for symbols on google. They the old tricks, most of them will not work, google simply ignores the details and returns a list of results based on the actual words contained in the query. It's becoming a QA machine. That's one of the reasons I switched to duckduckgo.
For a proper reading on the subject check ou the vast website of the, now deceased, great hacker Fravia: http://www.searchlores.org/indexo.htm