Slashdot Mirror

Could it be that Chrome prefetching is actually generating enough traffic to skew the result?

Facebook is actually losing customers in North America and Europe.

Yea, there is a deeper meaning you are missing. You see, the majority of the population doesn't think as you do on at least a couple of things. In fact, in those things, it disturbs them to a point they want to say or do something about it. These shows give that avenue in which they either say or hear what they believe echoed and know they aren't alone.

It's sort of like the libertarians siding with republicans in most elections, they don't like the majority of what is done/put out/planned to be done, but it's the closest match for a couple important things to they want. People like Beck and Limbaugh are good at bringing all these ideas and forces together which is why their ratings are better then anything the left has put out. In all that stuff you think is crazy, most of it is a mirror of something most of the population is thinking at various times.

and those bizarre conspiracy theories aren't really that bizarre when you think about it. Take this Google situation, it's no secret that Google employees contributed quite a bit to obama's campaign. It's no secret that Eric Schmidt campaigned for Obama. And this isn't the first time someone has accused Google of politically biasing search results.

Now if someone is getting different results while using different search engines, I don't see how it's much different then people getting different results when getting their news from sources outside the US mass media markets. And pointing out the results being different isn't ad bizarre or crazy and you might think.

And anyway, IPv6 addresses are ugg-ly.

Learn DNS. You should only be looking at a IPv6 address if you are a network engineer.

Saying "only," you and many others sound pretty sure that real users NEVER see ip address in the clear, though Vista and Ubuntu show you both v4 and v6 on wireless connection status and ifconfig lines --forum users asked to post theirs for troubleshooting are not all network engineers, either. Was DNS was created not for IPv4's sake, but for some not-yet-foreseen future IPv6 tech? DNS is perfect for the disaster that is writing out an IPv6 location... It isn't as dependable as some think even in our mature, saturated, well understood IPv4 world, and thus your argument falls apart. Look closer:

Remember that less than a 10 months ago in our supposedly mature year 2010 in IPv4, we all still saw IP addresses in the browser address bar for google cache pages. Of all organizations, geeks have the most respect for them, but if Google were fueled by cash from geeks alone, it would not be #2 in Netcraft's survey of most visited sites*

That alone means that a lot of people have been seeing naked IP's in their web searches. From hundreds of millions of yearly searches, even a tiny made up number like 1% is millions of individuals using a cache and finding this weird thing in their location bar called a naked IP address. In 2010. Oh, sorry, that must mean they are all certified network engineers, no? The dns domain they are using is only 2 years old, yet google caches with this "network-engineer" IP glitch in our address-bars is probably as old as google, a domain registered 12 years ago.

Now your focus will shift to "ooh, an honest 12 year mistake", or "only network engineers ever bookmark/e-mail/tweet/link address bar links with google's highlighted search keyworks," but a nobody and a never proven wrong once show dubiousness to the reliability of your thinking. Right, you said IPv6. I'm not a network engineer, but like thousands of sixx.net's tunnel users, I need to enter long, annoying sequences of IPv4 and IPv6 naked gateway and DNS server addresses into my router or tunnel. Without being an engineer, there are websites built for me and others to enter that world with sites on "free IPv6 only pr0n." Oh, so they must have meant this pr0n to network admins only... : )

Anyway, if IPv4 blunders can last for 12 years, rest assured that our fear is that IPv6 and bad *real* network admins will be lazy, like Google's were --or much, MUCH worse because IPv6 is annoying to deal with and retraining courses are few and far between. The problem will be a pest for the next decade or more. The naked IP problems of today worseing for tomorrow will bring you lots of IPv6 links when sc/pammers start targetting the IPv6-only users thanks to the relative inconvenience of hiding somewhere in IPv6 space. Proof of concept later later becomes a reality exploited by few, then more, and then all.

* Bested only by facebook, with 500 million active users.

I'm also surprised at how low the wages are at this Turk thing. ... I thought spammers had to at least sweat through that manual task by themselves.

It's like $0.25 per human-generated spam. Automation seems to be coming. I'm seeing mentions on black hat SEO forums that an automated tool for doing this in bulk will be released early next month.

Marketing fake numerical addresses in between legit ones ensures that Google Pagerank rates your "unique" business as #1...

Sometimes. That technique is mostly used to give real businesses extra bogus locations. Check out "New York City locksmith", for example. Other heavily spammed terms are "carpet cleaning" and "divorce lawyer".

This week's new technique is described at "How To Spam Google Maps For Top Google Place Listings". This is like SQL injection for mailing addresses. The trick depends on Google's parsing of mailing addresses from the top, while USPS standards say they should be parsed from the bottom line upward. So a mailing address with two street addresses is parsed differently by the USPS and Google, allowing the spammer to redirect Google's confirmation postcard to some mail drop.

Google seems to be out to lunch in this area. The same exploits have been working for months. Yet Google doesn't list any such issues under "Known Issues. Over on Matt Cutts' blog, where you'd expect to see some discussion of this, he reports that he's writing a novel.

It's even worse at Bing. Bing emulated Google's October 27th merger of Places into web search within a few days. But they weren't ready. Look up "New York City locksmith" in Bing, and the five "Places" entries are all the same business.

Some thoughts about the domain name itself. Google probably wanted to use 10e100, since that character string means 10 to the 100 power - in other words, a googol. Not sure why they settled for 1e100, because that only comes out to a measly 1.

Source

http://www.seroundtable.com/archives/013645.html

This kit, which includes a mouse, was sent out as a christmas gift to some AdSense affiliates:

http://www.seroundtable.com/archives/googlechristm aspresents2005600.jpg

Sorry for not writing this in the article - it's pretty long already and you just have to cut somewhere, but here goes:

Yahoo was exactly as vulnerable as the rest of the search engines. In fact this problem was pretty bad with Yahoo at one point. What Yahoo did was simply to fix it by implementing some internal rules about how to interpret redirects.

I believe it was fixed around June 2004 - at that time the problem had already been known (and aboused) for a long time, but use was not widespread yet. The details of the fix can be seen on this one-page PDF

It's simple (and identical to the solution i suggest in my article): When "Yahoobot" (actually it's called "Slurp") sees a 302 redirect, it checks if the domains of the redirect and the target are the same. If the redirect is from one domain to another, Yahoo keeps the URI from the target domain. If the redirect is from one page to another on the same domain, Yahoo keeps the "source" (ie. the redirect script URI).

In Other News: http://biz.yahoo.com/ap/040819/google_ipo_29.html reports that "Still, in true dot-com fashion, a scheduled summer picnic planned for Friday in a park near Google's Mountain View headquarters is expected to turn into an IPO party

I sure hope they have enough beer this time!
http://www.seroundtable.com/archives/000738.html