Safe way to access DOM of 3rd-party web pages

[markusha]

From what I've found out so far right now to access DOM of 3rd-party web page you need to load this page into an iframe. To isolate this iframe there are two attributes nwdisable and nwfaketop which should ideally block all access to Node.js functionality from inside this iframe and make it look for the iframe's DOM like it is a top-level window for the iframe itself and all its window-descendants. However in this #534 issue there's a mention of iframe breaking out from nwdisable-sandbox. So the question is: how can someone completely isolate iframe from accessing what it must not access? Maybe there's some other way to safely access web pages' DOM besides iframe?

[rogerwang]

Could you please refer to the way of breaking out iframe? I didn't find in #534

[twrodriguez]

@rogerwang my final comment on that thread from 6 months ago:

• A Ctrl+Click (Cmd+Click on OSX), or middle-mouse-button-click on a link will bypass the nwfaketop and nwdisable attributes, replacing the top-most window with the contents of the link, and also exposing nodejs to the linked site. I'm working around this right now by running a master Window that monitors the main window's location object, and closes it if it notices a protocol other than file:. But, this still exposes nodejs until the loaded event is fired.

In light of these, I'd like to propose a new event: blankwindow. The default action, of course, would be opening a new window (with a frame? without node?). Attaching an event listener would then allow the developer to call event.preventDefault() and handle the request as they see fit.

I'm sure I haven't thought enough about this, so please weigh in with your comments.

armoret in issue #1290 also references my comment.

To everyone:

node-webkit is NOT designed to provide full browser experience; you have a very hard road ahead if you want to do that. Javascript isolation of the site exists in an nwdisable & nwfaketop iframe, but user actions can still cause problems, such as Ctrl+Click, Command+Click, Middle Clicks, Shift+Click, and Alt+Click because node-webkit honors all the default actions that chromium honors. And you'll get many more incorrect behaviors if sites have HTML5 History manipulation, or if users use keyboard shortcuts. You will also have to manage the user experience if there are window.open() calls in the 3rd party javascript, or if the HTML contains target=_blank links since they will open up brand new windows. And let's not forget that 3rd party sites can ALSO have their own iframes with isolated contexts.

These problems can be worked around, but you have to inject javascript on iframe load events that handle "mouseup", "mousedown", "click", "keyup", "keydown", and "keypress", cancelling events as necessary, and provide correct behaviors for each platform. I still haven't sealed all the possible holes in Cycle (http://getcycle.com) after 6 months, so godspeed to anyone who tries without some additional help from node-webkit/CEF APIs. (If that sounds like fun to you though, I'd love to chat!)

@rogerwang - If you do decide to expose some more APIs regarding this, or just lock down chromium-default user-initiated actions, I can't complain. 👍 Making each developer try to cover all possible cases is extremely error-prone, and if people continue to use nwdisable & nwfaketop to display 3rd party sites, it will become a major problem.

[rogerwang]

Please see the doc for the new new-win-policy event for this, and make comment if you feel anything need to be changed.

https://github.com/rogerwang/node-webkit/wiki/Window#new-win-policy
It will be available in the upcoming 0.9.0 release.