Webpositive hijacked by casino

While using webpositive I ended on a website that created some indestructible pop-ups. The only way to close them is by shutting down Haiku. Restarting Haiku and webpositive doesn’t solve the issue because the moment I start webpositive, the popup windows appear in the left upper corner. These windows can not be resized, dragged, starting a new window does not give a new window but only a new pop-under window that has more commercials for online casino’s.

In other words: webpositive is hijacked. The only way to get webpositive running again is by deleting all settings but there should be a better way to solve this. So which is it?


WebPositive, among other things, desperately needs addon support, most importantly an adblocker like uBlock Origin.

1 Like

At first, it was hard to believe that this would occur on Haiku with an “obscure” browser such as WebPositive.

However, ransomwares coded in javascript are starting to be common: http://www.bbc.com/news/technology-36575687 . They appear to be more potent than regular attack vectors as javascript files have so far tended not to be examined for malicious payloads.

So, it can no longer be taken as granted that web browsing with a Haiku system would render one immune to malware infections.

From the description of the issue, it appears that the annoying popup inserted itself into the startup script of WebPositive. Maybe not all settings need to be deleted, only those which relate to initialization/start-up may need to be restored to their “clean” default states.

I recommend setting up Pi-Hole on your network, if you have a spare Raspberry Pi lying around.

Works well as an ad-block solution for Haiku.


1 Like

Thanks for the response. I can also imagine that Webpositive on startup jumps to the last known open page, which would have been the casino site. I have never been a fan of giving javascript control over the browsers function (enable/disable buttons etc). Very cute that a site developer can make a popup window without controls, but who should actually be in control?

I have never seen a browser that simply ignores these events. Cool would be a sidebar that shows: this page has performed the following actions, we blocked them. Press the allow button if you would like these actions to proceed.

You can delete just the Session file in Web+. This is where it stores the last open page to restore it on restart. There are plans for making this behavior optional too, I never got to actually implement it in the settings window (patches welcome!) and we should probably add some kind of “safe mode” too (like press shift + start web+ to run without the previous session).

I find it strange that the windows are unclosable, however. What I’ve seen happen is windows fitting the full desktop so that the tab bar and border are out of reach. But even in that situation, you can get out in several ways:

  • Use control+alt+drag to resize (right click) or move (left click) the window, so you can reach the window tab and the close button.
  • Use the alt+W shortcut to close the focused window.
  • Get to the deskbar using the “menu” key, then close the problematic window from there.

If it is the last window, however, closing it will also quit Web+ and save the session. In that case, first press alt+N to open a new window. And only then, close the annoying one.

On the code side, we should maybe always keep an address bar or menu visible, but I wouldn’t want this to interfere with legitimate full screen windows (say when watching a youtube movie full screen). So we shouldn’t be too restrictive, either.

As an interim solution, to get rid of the “open Previous Session” behaviour until a settings option arrives, my ‘WebPositive’ icon is a tiny xicon script:

rm -f /boot/home/config/settings/WebPositive/Session
open /boot/system/apps/WebPositive "$1"

Saves me a lot of annoyance!

1 Like

There is actually a hack to prevent the session thing to work:

rm -f /boot/home/config/settings/WebPositive/Session
mkdir /boot/home/config/settings/WebPositive/Session

When the session file is a directory, Web+ will fail to write to it.

But really, someone should add the checkbox to disable this. Or, if it is so unpopular, the feature should just be disabled permanently.

I need to set this up too. By this I mean PiHole