Fastest exit strategy for a Panic Button in Crisis/Abuse Websites? [closed]

Answer 1

Reliable Escape

EDIT: Another thing that comes to mind is that if the user has lost Internet connectivity, which happens for all kinds of reasons including somebody disconnecting the cable, then there is no way you could navigate them to another site. They could be stuck there like a deer in headlights on the "incriminating" page. I think this adds credibility to the idea of actually navigating to a benign partner/affiliate site that in turn loads your site in an iframe directly on their page. All you have to do to make your site disappear is delete your iframe from the DOM using JavaScript that is already loaded into the iframe. It would work even if the Internet connection went dead.

I would enable the Escape key for a quick exit. That's a physical, well-known key on the keyboard that the user can lunge for if they need to, rather than moving a finicky mouse pointer to a virtual button and clicking.

EDIT: I just realized that an earlier poster did mention the Escape key, referring to it as "ESC." I searched the page for "Escape key" before writing my response, but missed that.

EDIT: I'd leave the Panic Button on the page, too, with the text "Click Here or PRESS ESCAPE to Exit Quickly." But I'd put one at the top and one at the bottom of the page. Maybe I'd put a strip all the way around the page. If the visitor clicks anywhere in that border zone your content disappears.

Also consider; to make the Panic Button reasonably easy to click in a panic situation, you'd probably need to make it a little bit oversized and make sure it's always on the screen by moving it as the page scrolls, or by putting multiple Panic Buttons on the page, which could be kind of suspicious-looking in and of itself. It seems as if these probably want to be pretty discrete-looking pages that you're talking about.

If you're using jQuery, you could do something like the following to respond to the Escape key:

jQuery( function ( $ ) {
    $( document ).keyup( function ( e ) {
        if ( e.which === 27 ) // escape
         {
         // clean up... 
         }
    } );
} ); 

Single-Page AJAX App

It looks like all of the suggested solutions are about figuring out some way to quickly navigate to some other site, either by having it pre-loaded and quickly displaying it over the top of your site, or by clearing the DOM then navigating away, or whatever.

If I were going to take that approach, I'd have a laundry list of universally benign sites and search engine searches that I would cycle through so that it isn't the same "search for black women's shoes" showing up every time.

But what about turning the whole concept on its head? Use one or more benign decoy sites, or even solicit unrelated benign commercial sites to host a benign-looking link, and load your site as a single-page AJAX app in an iframe on top of the host page(s)?

EDIT: You could even do this by having your home page briefly state that it is going to redirect the visitor to a cooperative partner site for their own safety and show a big friendly "Go" button. If you have multiple partner sites you can push them to, so much the better. When they click, erase the browser history for your page, redirect to the affiliated site with a URL query parameter that tells your bootstrap JavaScript at the affiliate to immediately load your iframe. From that point forward, there is no additional load on the affiliate's web server. This way, you have an official Home page, but you immediately get the visitor completely off of your page.

Pressing the Escape key or clicking the Panic Button would just delete your iframe from the DOM, leaving the benign host page and no browser history. (Poof)

You could mitigate browser history issues that way since your link would run a bit of bootstrap JavaScript code and you would never actually navigate the browser to your site at all.

When the bootstrap link in the host page is clicked, it would insert an iframe into the DOM, float it (absolute positioning and z-order) to position it on top of the host page, then make an AJAX call to your web service to retrieve HTML content that it would load into the frame. All additional links and/or buttons in the frame would also make AJAX calls to your service, whether posting data to the server or retrieving data for display. You would never load an actual "page" in the user's browser at all.

Another nice aspect of this approach is that if the browser crashes or becomes unstable and has to be shut down from Task Manager, which would prevent the cleanup code from running, well that won't matter because you don't (necessarily) have anything to clean up.

Houston...?

A few serious problems I see with any of these solutions off the top of my head, particularly given the context that lives may be on the line:

• cached objects (images, primarily) in the browser cache

• the router/firewall might be logging HTTP/HTTPS requests, and the victim may not know this, and nothing you do to clean up the browser will mitigate that

• there could be keylogging/screencap spyware installed on the user's machine and nothing you can do from a browser app will mitigate that

• computers crash, web browsers get flakey and crash and traces get left behind because cleanup code can't run.

As suggested by at least one other poster (honestly, I've only briefly skimmed the other posts), using browsers in secure mode should mitigate many of these scenarios. But that is a user training issue and user training can be a little crazy under the best conditions. It could be real tough to get right if the victims aren't very tech-savvy, especially if they really are in a panic-mode situation where calm thinking might be difficult.

Answer 2

I think we can do this differently. My Idea is as follow:

1. Show the website with only fake content (similar style and layout with the real one).
2. User needs to do certain interaction with the content to trigger step3(e.g. put XYZ in a textbox or have clicked a combination of Checkbox or RadioButton, etc.).
3. With step 2 satisfied, when user hangover certain tiny point on the page (right hand side), the page will display its real content. And the content will remain if the mouse is over it.
4. In an emergency/Panic, user can just move the mouse away from the real content, and the content will be changed back to the fake one.

Answer 3

I am extending the scope of the question a bit, as clicking panic button does guarantee the user will not be caught.

There are multiple concerns in this problem that needs to be issued depending on the risk and how compute literate is the user.

As such, it might be a good idea to give the user some basic security knowledge in the friendliest way possible. Even though the user is under high stress, it is better for them to know what traces they can leave behind.

Traces

Browsing History

At any time the user uses your website without private browsing, it will leave very obvious traces. There is no proper way of detecting if the browser in running in private mode, but you can have a warning in the entrance that they should be switching to the private mode, as well as deleting the current history of entry. You can prepare some screenshots to for the user to follow to delete the history, (or if available, deleting only the entry to the site)

Cookies

If you make use of cookies, the next person can get those cookies (even though they are expired), and can understand that this site has been used. If you can, make use of custom headers for authorization, which will leave no trace in the computer.
This can force you to change the structure of the application which might not be a good idea. Only setting cookies in the browser after you make sure the user is using a private browsing session.

Caching

A tech-savy person can detect if the site has been visited if you make use of caching by opening the page and inspecting network. Make sure you explicitly instruct browser not to cache by using those headers in your responses:

'Cache-Control: no-cache, no-store, must-revalidate'
'Pragma: no-cache'
'Expires: 0'

Back button

Upon changing pages, every page will be put in the current history (even in the private browsing session), allowing back button be used. If you can, make use of replaceState on every page change so that back button will be broken.

Encryption

Use HTTPS to prevent eavesdropping. Note that DNS queries will still go unencrypted, but I don't think this will be a problem unless the user are leaking governmental stuff. If that's the case, a website wouldn't be safe enough anyway.

In general, those should be sufficient to remove the traces, also make sure you are not using other persistence layers like localStorage.

Panic Button

This is a totally different problem and we need to include multiple things into our calculation.
First off, if this is a life threatening scenario, we must understand that the user will be under utter stress when they need to launch the panic exit. We don't know how the computer screen is positioned, and we cannot guess what is the user doing in the time of the panic.

Screen Positioning Issues

The worst case would be that the screen would be positioned in a way that threat can see (from a distance) the screen and the site. If that is the case, the site should be designed in a way that it will look very similar to the exit site in order to remove any suspicion. Moving away from a different design to white Google will be noticeable even the screen is not directly visible by just comparing the colors that the screen was emitting between two sites (in a reasonably dark room).

Exit Speed

If you just make a redirect, it might not be fast enough to make the change in time. You must preload the exit side in an iframe, and in the time of panic, you should put that in full screen, then make the redirection. This will both help on caching the exit sites static contents, and make the things look faster. Make sure you use replaceState instead of natural navigation to disable back button.

Exit Routes

You must make sure that the exit routes will be available immediately and easily for the user to hit. I think the most possible two states are either the user is typing, or the user is navigating. Which means you should have both keyboard shortcut for exit and a big button in your HTML.

Keyboard Exit

I think using either hitting the ESC key twice should trigger it, or holding one of the big keys should (like space or enter). Either way, you should let the user know about this, and possibly, let them train themselves by trying. Trying panic exits will both help them in anticipating behaviour on panic to make a good reasoning (Having the behaviour expected could be relieving), and they will be trained to do so, such that they will be more likely to do it properly in the panic time.

Mouse Exit

This is going to be pretty straightforward, have a big, different colored button that will trigger the panic.

Where to Exit?

That depends on the case, by design it might be sensible to make a redirect to a commonly used, similarly designed site by default. It might also be sensible to allow the user to choose the exit site by themselves (after making a sane default).

Notes

• If the user is using private browsing and panics, the browser will still be on private browsing state, which might arouse suspicion. There is no easy way around it. You can try to instruct user to clear the history afterwards, but they might not have enough time for it.
• Most of the answer focuses on desktop browsers, the experience on a mobile device will be different, but not very much.

Answer 4

Since you said that lives are at risks in your implementation, i strongly suggests educating the users to use multiple tabs instead of clicking on some panic buttons.

My reasons being

1. In times of 'emergency', how long does it take for the user to move their hands to the mouse (assuming they lifted their hands to type or touch their hair or whatever they wanted to do), let's assume it took them -> 0.5 seconds
2. In your example site, the green bar is actually very small, to be frank, not everyone is very accurate with their hand, eyes coordination (moreover mouse cursor acceleration might differ between OS'es and User Profiles), the user has to move the mouse to the "Panic" button and click, unless they are professional FPS gamers, it's likely to take them another -> 1-2 seconds
3. My last variable assumption is, if your script involves loading remote resources, for e.g. www.google.com, you can put lives at risk by assuming that the browser is
   • Modern
   • Has scripts enabled
   • Network speed & latency is optimal
   • Caches are primed.

If you are going to load remote resources, i suggests you to insert a div with z-index: -1 and some dummy web contents. On click, move their z-index higher to overlap everything on screen.

So if we assume you load a remote resource and with all the unknown variables, we can assume the time taken to be -> 0.5 - 10 seconds

If you are going to write a program that might kill someone, i strongly suggests you not to take the risk of doing something that might take 2 - 12 seconds to save them.

Educate your users by putting a banner with instructions

1. Open a tab that wouldn't threaten their own lives (e.g. google.com, msn.com, yahoo.com)
2. Open another tab with your site
3. Navigate normally on your site
4. In times of emergency, press Ctrl+W for Google Chrome, IE, Firefox, Opera (please confirm for other major browsers)

If you get the whole idea, press ctrl + w vs your planned solution, i can certainly guarantee that Ctrl+W is going to be faster.