Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the '10.4: View hidden link destinations' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: View hidden link destinations
Authored by: eforiv on Jul 05, '05 09:20:04PM
You shouldn't have to jump through that many hoops to figure out the page is trying to exploit the browser... I registered to this forum just now because this is unacceptable of any browser. A page pulling of this type of exploit should at the least cause some sort of warning to be displayed. Any page linking to any executable file should not be allowed to conceal it's inner working but to the avg person the inner workings mean nothing... so again at the least the browser should display a warning... If you know how to look for it you can get to the javascript by navigating the DOM tree... I find this extremely concerning! A PAGE SHOULD NOT BE ALLOWED TO MAKE UNKNOWN CHANGES TO YOUR CLIPBOARD!!!!!!!!!!!

if(document.all){ _fc='<'+'div style="position:absolute;left:-1000px; top:-1000px; width:60px; height:35px; z-index:1"> '+'<'+'input type="button" name="_xqq" value="" inClick=_ccd() style="visibility:hidden"> <'+'/div> '; 
function _ccd(){ 
[b]clipboardData.clearData() [/b]
} ; 

function _cce(){; 
} ;

and here's what keeps you from control clicking

function _nrcie(){ 
return false 
function _nrcns(e){ 
if(e.which==2||e.which==3)return false 
I don't know how you can allow legit functionality while blocking the exploits... maybe a point system like spam control... x+y+z exploits on one page and warnings are displayed or if X and Y disable XYZ javascript functionality. I used to feel safe being on a mac always being able to see the source always having my control click. Apple MUST address this potential exploit. think about it... that exe it linked to could have been a dashboard widget that waits for you to activate it. or some other yet to be found OS X exploit. As a web developer I would never have reason to convolute a page as much as that one does nor would i expect ANY web developer to need to. Knowing this I would say it's safe for apple to make changes to the browser to control exploits like this. You just need checks and balances that a person isn't trying to overly conceal the inner workings of a page... as in multiple nested frames AND javascript to control viewing source ugh sorry to rant but this is highly frustrating.

[ Reply to This | # ]
10.4: View hidden link destinations
Authored by: aranor on Jul 06, '05 12:26:12AM

I agree that it's annoying, but I think you're blowing it waaay out of proportion. If you can't tell where a link goes, don't click on it. And even if you do, the worst it can do is make you download something you didn't intend to download. And so what? It shows up in your downloads window, you can see it, you can cancel the download or select the file in the Finder and trash it. It's no big deal. And especially not for downloading applications and the like, because Safari will prompt you if you really want to download it.

[ Reply to This | # ]
10.4: View hidden link destinations
Authored by: eforiv on Jul 06, '05 07:19:57AM

as a web developer it just aggravates me since there is no reason to go to those lengths under any normal circumstance to obfuscate your code to that degree.

multiple nested frames, nested divs and spans, javascript to hide code, javascript to eliminate control click, javascript to clear the clipboard . that many twists and turns should cause the browser to pop some sort of warning.

and while apple has made changes to keep from auto loading dashboard widgets like it used to just from a simple link click... you don't know what OS X exploits haven't been found yet or are going to be in the future.

I feel taking steps to keep the browser *in check* ahead of the problem is sane sense.

[ Reply to This | # ]