Hacker News Reader

Comment by javery | Hacker News Reader

Why use an iframe? Async javascript would be better all around. Also - when you click you name in the badge it opens the link inside the small iframe.

View on HN

iframes don't block the outer page from loading or expose the page's security context (cookies, etc) to the external domain.

Async JS doesn't block either - and cross-domain scripting rules are strict enough that it is pretty safe. The iframe code has an async Google Analytics script in it - perhaps that is the reason for the iframe (to use google analytics for tracking usage).

Javascript version is on the horizon. We used iframe because it was quick&dirty and "good enough" to start with =)

Curious what you mean about cross-domain scripting rules and safety. Normally, loading a third-party script via a script tag lets that script do anything the page can do, which makes it decidedly unsafe.

Personally, I greatly prefer the iframe.

You're correct - it can do just about anything. Technically it can't make ajax calls back to a domain other than where the page was served from - but you could get around that by just inserting more javascript tags.

iFrames do offer a little more security here - but in this case I would still go for just script since I don't see that the downsides outweigh the added security. (you can still do a whole ton of damage from an iframe)

What damage can you do from an iframe? You don't have any of the permissions of the site containing the frame.

You can deceive the user pretty easily with content that looks like the main page and prompts them to do something you want them to do. (like login to the parent app even though they are logging into your app, anti-phishing stuff won't take effect if you keep it all in the iframe)

You could also just execute whatever JS you want if there is a browser vulnerability you want to take advantage of.

Fixed. Thanks.

Reply on news.ycombinator.com