Google wants to change the way JavaScript popups following multiple instances of abuse from hackers.
The internet giant is planning on engineering JavaScript modals to work on a per-tab basis, rather than the per-window approach used today to make it easier for users to close potentially malicious popups.
Nothing JavaScript's age and it originally containing methods of creating window objects such as alert(), confirm(), and prompt(), Google says their synchronous API is problematic for modern browsers.
“Because the JavaScript engine needs to pause until a user response is obtained, the JavaScript dialogues are app-modal. And because the dialogues are app-modal, they commonly (and unfortunately) are used to harm our users,” says Google.
Because of this, the Chromium team, which develops the Chrome browser, has begun recommending that these JavaScript dialogues are no longer used.
Google says there are many options for dialogue replacement. Among several choices for alert()/confirm()/prompt(), for notifying the user of events (e.g. calendaring sites), the Notifications API should be used.
For obtaining user input, the HTML <dialog> element should be used. For XSS proofs-of-concept, dev tool's console.log(document.origin) can be used.
As for onbeforeunload, it should be noted that it is already unreliable. As Ilya Grigorik points out, “You cannot rely on pagehide, beforeunload, and unload events to fire on mobile platforms.” If you need to save state, you should use the Page Visibility API.
The ability for a page to specify the onbeforeunload string was removed in Chrome 51. (It was also removed by Safari starting with Safari 9.1 and in Firefox 4.)
alert()/confirm()/prompt() dialogues are being changed. Rather than being app-modal, they will be dismissed when their tab is switched from. (Safari 9.1 already does this.) This is fully enabled on the canary and dev channels and partially enabled on the beta and stable channels, and will be enabled more in the future.
The current plan for beforeunload dialogues is to require a user gesture to allow them to show. (This would not change the dispatching of the beforeunload event.) This aligns Chromium with Firefox, which made this change with Firefox 44.
Google says: “Because of these changes, if your site uses dialogues, it is highly recommended that you move to using the earlier-mentioned alternatives so that this will not affect you.”
Fraser Kyne, EMEA CTO, Bromium below explaining whilst this is a step in the right direction, this plan is far from foolproof: “We are seeing increasingly sophisticated methods of scare-tactics being used to trick users into activating malware. Pop-ups like those that Google is seeking to address are often designed to do just that, with clever features such as buttons that look like they will close the pop-up actually being a part of it; redirecting the user to a malware download and giving the attacker everything they want.
“Google has clearly acknowledged that this is a problem, and its actions are certainly a step in the right direction. However, this solution is far from foolproof, and some users will always be panicked into clicking malicious pop-ups. Ideally, there should be a safety net beneath them. For example, micro-virtualisation can ensure that every web page and tab is launched in its own, fully isolated environment. As a result, any malicious pop-ups and the malware they link to are trapped within that virtual machine, posing no risk to the rest of the system. If they find themselves clicking in the wrong place, the user can simply close the page down and the problem goes away.”
