I just hit this link today (DO NOT CLICK) from within a Google search I made;http://ldr.zeobit.com/paramss=sbbY37...yMK4r5g=&trt=2
Without the link, zeobit.com doesn't do anything --
traceroute to http://ldr.zeobit.com/
(220.127.116.11), 64 hops max, 52 byte packets
3 18.104.22.168 (22.214.171.124) 104.961 ms 89.322 ms 95.287 ms
4 126.96.36.199 (188.8.131.52) 100.462 ms 89.785 ms 89.764 ms
5 dal2-pr2-xe-1-2-0-0.us.twtelecom.net (184.108.40.206) 119.649 ms
dal2-pr2-xe-2-2-0-0.us.twtelecom.net (220.127.116.11) 119.476 ms 125.630 ms
6 ae-23-70.car3.dallas1.level3.net (18.104.22.168) 125.117 ms 129.539 ms
ae-33-80.car3.dallas1.level3.net (22.214.171.124) 129.900 ms
7 splice-comm.car3.dallas1.level3.net (126.96.36.199) 134.553 ms 130.320 ms 134.405 ms
(at this point, it just sits and waits -- I suppose for the coded command string from the poisoned link)
The annoying thing is, that it puts up a dialog that you CANNOT escape out of, so the "user OK" is fairly mandatory. I could not get to preferences, or another Safari window. I basically had to "force quit" the application.
I don't think it requires a STUPID user in this case -- it's more of someone not paying attention. There is nothing visually to show what is going on. And the "workaround" is not obvious. Forcing the "OK" button click coerces the "user interaction."
>> The big question is; how can something be ON the internet, and yet, invisible? Some intermediary has to blindly take the code and pass it to a server. URL-shortening services or using the basic switching codes of the hubs. Ultimately, this seems like a problem with the backbone and routers, because the "link" is made almost entirely of router commands.
I would suppose that an EASY fix for this, would be to have links that RESOLVE to an IP address before loading the page. These "poisoned pages" are passed to the browser by router commands.
>> Hopefully, I won't be hitting another link like this.