BUG: Too easy to bypass the blocking redirect

Feature Requests 👀
#1

I’m premium user and I use Opal both on my iPhone and my mac. It works flawlessly on the iPhone but on the mac app there is a major bug that essentially is making the app useless.

It’s too easy to bypass the redirect that Opal makes when you visit blocked websites: You just have to press or swipe to “go back” a couple of times and the redirect to shields.opal.so eventually fails and I’m now on a website that Opal was suppose to not allow me to go to.

This happens on any browser (I tested Chrome, Safari, Brave, Firefox) and has been happening for a lot of versions. I’m currently on version 1.2.3 which is the latest.

And just to be more clear on the bug and what I think the ideal behaviour should be, here is an example:

  1. I’m currently in an Opal Session that blocks several websites (like youtube.com for example);

  2. I open Google Chrome, initially in a new tab (or a website that is not in the blocked websites list like google.com let’s say);

  3. I try to navigate to youtube.com (whether through a link or through the url bar) and chrome naturally takes me there by navigating to that page;

  4. The Opal app quickly detects that it’s a blocked list website and redirects me to a shield screen in shields.opal.so;

  5. I click to go back which takes me to youtube.com which repeats steps 3 and 4. The problem is eventually step 4 is not triggered and I’m now on youtube.com even though a session is active and youtube.com should be blocked.

If only the shields.opal.so shield screens would replace the blocked website in the browser history instead of redirecting and coming after it, then if the user tried to navigate back it would go to the allowed url that came before the attempt to go to a blocked website, so in the example above the step 5 (trying to go back) would take me to step 2 (new tab or google.com) and not a repeat of step 3 and 4.

This would make it impossible to go get to the blocked website by repeatedly going back until the block redirect fails to activate because going back would take you to the url before you attempted to go to a blocked website.

I understand that the ideal behaviour may not be possible to implement. If so, you need to add more safeguards to guarantee that the block redirect is triggered.