GNOME Bugzilla – Bug 774384
Javascript exploit locks out interface
Last modified: 2017-04-28 10:38:17 UTC
This website uses Javascript to create infinite popup dialogs. There's no way to close the tab or browser window they appear in except "kill -9 $(pgrep epiphany)". I'm not sure what--if anything--can be done about it, but it would be great to have a solution that covers the exploit rather than just the site itself. Warning: Set "org.gnome.epiphany.restore-session-policy" to "never" before viewing this site! If epiphany restores the page when it reopens, the interface will immediately be locked out again. Since the default setting is "always", this would cause epiphany to appear permanently unusable for a user who is unaware of dconf. The dialogs are in Japanese and the site plays a loud, annoying alarm. Not that it really matters what they say, but the gist of it is "windows security compromised, click here or else!" (security scam; clicking "ok" probably does something even more nasty to internet explorer that doesn't appear work on epiphany). This site appears occasionally as a popup advertisement from video streaming sites and other spam-riddled places of the internet. Do not click lightly: http://jpneat.net/indexie2.html
Firefox has this feature which, after two or three popup dialogs have been shown, they come with a checkbox that reads “Prevent this website from opening more popup dialogs” (or something similar to that). Maybe Epiphany could do something similar.
(In reply to Adrian Perez from comment #1) > Firefox has this feature which, after two or three popup dialogs have been > shown, they come with a checkbox that reads “Prevent this website from > opening > more popup dialogs” (or something similar to that). Maybe Epiphany could do > something similar. Yes, this is exactly what we need to do. All other browsers have had this for years. It needs to be fixed in WebKit, though: Thanks for taking the time to report this. This issue is most likely a bug in WebKit. Please report the bug to https://bugs.webkit.org/ including a link to this bug report and noting the version of WebKitGTK+ that you have installed. When reporting the WebKit bug, be sure to include the prefix '[GTK]' in the bug summary and select the 'WebKit Gtk' component.
(In reply to Michael Catanzaro from comment #2) > (In reply to Adrian Perez from comment #1) > > Firefox has this feature which, after two or three popup dialogs have been > > shown, they come with a checkbox that reads “Prevent this website from > > opening > > more popup dialogs” (or something similar to that). Maybe Epiphany could do > > something similar. > > Yes, this is exactly what we need to do. All other browsers have had this > for years. It needs to be fixed in WebKit, though: > > Thanks for taking the time to report this. > This issue is most likely a bug in WebKit. Please report the bug to > https://bugs.webkit.org/ including a link to this bug report and noting the > version of WebKitGTK+ that you have installed. When reporting the WebKit > bug, be sure to include the prefix '[GTK]' in the bug summary and select the > 'WebKit Gtk' component. Epiphany is already handling the WebKitWebView::script-dialog signal, and it could as well prevent dialogs after the N-th one... a different story is whether it would be more efficient (and/or better architected) to have some support for this in WebKit[GTK+] — that makes sense, and probably is what you meant, right? But even in that case, it may need changes in Epiphany depending on how the WebKit[GTK+] part is done, so it may be a bit premature to close this issue... dunno.
I think we need new API in WebKitGTK+ to indicate that no further dialogs should be created for the page, right? I guess we could try to hack something up at the Epiphany level....
Reported to webkit: https://bugs.webkit.org/show_bug.cgi?id=164853 Just my opinion, but the deeper the fix the better. If that's going to take a while however, an interim fix in epiphany is also a good idea.
>I guess we could try to hack something up at the Epiphany level I suspect that is what apple did for their safari browser after finding this 2008 report of the same issue: https://bugs.webkit.org/show_bug.cgi?id=17560
This cannot be fixed at Ephy level because the javascript alerts need to be dealt with in the web process, otherwise even if they are blocked there would be an endless polling of the UI process which would freeze the UI anyway.