I recently had an issue whereby a user was complaining that they couldn't access a certain page because the link wasn't where it was supposed to be.
After some head-scratching, I had them disable all browser extensions and sure enough the problem went away. Re-enable extensions one by one...
AdBlock.
For some reason, it was blocking the links to the pages the user wanted to access.
Now, I don't run ads and never plan to, so usually I just tell people with this problem to whitelist the site and all is well. But if someone never knew there was a problem to begin with, I would actually lose traffic because of this. So how can I avoid this?
The only thing I can really think of is to detect AdBlock and pop up a small notice explaining that AdBlock is known to corrupt the website and that, since we don't run ads, they may want to disable it for the site. I mean, the site is a game, and this isn't the first time a browser extension has broken it, but I don't think first-time visitors would be too happy to see a popup asking to disable their blocker, you know?
So any solution that would actually prevent AdBlock from corrupting the site in the first place would be great.
You cannot prevent Chrome extensions from running. They operate in their own separate thread, with a privileged API, and hidden from page scripts.
Detecting adblockers is awkward. The easiest way is to create a 'sacrificial element' - a div with a class like 'ad_unit', for example - add it to the DOM and then wait a frame to see if it has been hidden (with display: none, for example, or a getBoundingClientRect check).
Element checking is tricky, though, because strictly speaking there's no guarantee an adblocker will run synchronously or before your checking code.
Because adblockers run in a privileged mode, their operation does not trigger events in the nonprivileged script space. To put it more simply: you can't use DOMMutationEvents to spy when a foreign extension messes with your page.
The other option is to try and load a 'sacrificial file' - an image with a URI that looks like an advert, say - and then attach an onError handler to the element. If it throws an error that looks suspicious (I think it's ERR_BLOCKED_BY_CLIENT on Chrome), then you show your warning message.
Your final choice is to try and avoid incurring Adblock's wrath in the first place. Adblockers generally use open blacklists of URIs and CSS selectors, like EasyList (https://easylist.to/easylist/easylist.txt) - this is what AdblockPlus uses and a fair few others. You could just try and make sure your DOM elements never have IDs or classes that collide with any of those selectors. It's a big list, though, and it can change at any time.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am doing a website for a Women's Abuse Resource Center. A lot of centers like this have what is referred to by the centers as a "Panic Button". An example of a basic one is found here at the top of every page in the green bar.
The idea of the link or button is for if a women was looking at this website for help, and their abuser or someone they didn't want to know walked in the room, it allows for a fast escape. Sometimes a link is much faster then closing a browser window and that can be suspicious.
The problem I see is that most buttons I see doing this just send you to google or something like that. I am going to do something like this:
LEAVE WEBSITE NOW!
or
</html>'>LEAVE WEBSITE NOW!
A link like that will scroll you to some actual content. Its not a blank Google search but is also not a very specific thing that could be seen as suspicious.
I know that blocking the referrer is good but even with that solution you can hit the back button on your browser and your caught. For this problem I thought I could do something this:
HTML
LEAVE WEBSITE NOW!
JavaScript
function goNewWin() {
window.open("backbuttonnewpage.html",'TheNewpop','toolbar=1,location=1,directories=1,status=1,menubar=1,scrollbars=1,resizable=1');
self.close()
}
I am posting because there are lives at risk with this and I need something that is as close to a total solution as can be. How would you do this?
UPDATE- 3-26-14:
I ran some of the educational ideas posted here by the resource center I am working with and here was their answer. "It takes extreme courage for our users to even come on our website. When they come they are looking for a fast easy resource to get out of a possibly life threatening situation. They would not have the time or the mental capacity in most cases to educate themselves on a safe way to browse our website. When presented with the idea of a "panic button", when done properly, has seemed to be a resource that is always asked for by most victims that we treat."
After reading a lot of the ideas here it seems like a total solution would be a large button that floats in a constant position on left hand side. When the page loads it loads another site in the background (maybe an ajax call) so that clicking the button just removes the overlaying frame. This will mean no load time when clicked. To avoid a back button press of the browser it seems like telling the browser not to cache is necessary as well as possibly using replaceState on every page change to disable a back button that reveals this site.
This is still very much a technical question. The debate helps very much but I still need a working technical solution. Anyone think they are able to get all these ideas together into something functional? Ill be working on it right away myself and will post anything I come up with. Thanks all.
(ALMOST) FINAL EDIT
OK, I've read all the comments and this is what I think is the best solution but I've also thought of an ALL-LOCAL ALTERNATIVE. I'm open to further improvement/discussion
var panic= function(){
document.body.innerHTML = '';
//this clears the current html in the body
//making it look like the page is loading
if(...){ //check if replaceState is supported so no error is thrown
var title="Decoy Article Title",
url="/decoypage"; //another endpoint on your server that gives the decoy website
window.history.replaceState("", title , url); //replace current history entry
}
//should be pretty fast up to this point
window.location.replace("http://www.google.com"); //load the google page or my alternative.
}
I put an example on my AWS instance at 54.186.79.95 Go to that page, click the button, visit another page, then hit back, you're now on 54.186.79.95/decoywebsite and there's no record of you being on 54.186.79.95/, if cache is disabled, your server will see the "../decoywebsite" request and send a decoy page. Unfortunately, you can't modify the entire domain so you would need the domain to be not suspicious.
If you want to get rid of the page content, I believe the best way is to use document.body.innerHTML='';. You are still technically on the page but all the content is gone.
Next step is to modify your browser history. window.history.replaceState (link to docs) is an HTML5 feature that can modify your history without doing a page reload or a request to your server. It's pretty fast but only works on modern browsers. When the user clicks the panic button, we will replace the current page in his history with a fake url.
If the abusive user clicks back, your server (Php, python, whatever) will receive a request with your fake url. So you need to have another endpoint in your server (Let me know if you don't understand endpoints). Make a benign article, recipe, or weather report with a similar look and feel to your original website in order to avoid suspicion if the abuser got a quick glance at the website. Also make sure the browser's doesn't cache by using the <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">tag.
Additional Remarks
Ideally your entire website (except your decoy article of course) should be an SPA (Single Page Application) so that it only ever produces one browser history record and you only have to modify that one.
At the end of the day, I don't think you can't make a panic button that's 100% foolproof, there's gonna be ways around it. You just have to find one with an acceptable level of security and convenience.
ANOTHER ALTERNATIVE: LOCALLY CHANGE THE INCRIMINATING INFO AND MODIFY BROWSER HISTORY
I was also thinking if instead of loading google, if it's not best to actually transform your site locally with innocent info. This looks less suspicious than loading google (everyone does that) and you can do it all locally without reloading the page.
When they click the panic button, you do some fast (and cross-browser compliant) DOM manipulation to change the incriminating info on your website and make it look innocent (maybe just change the text, it has to be fast). This way, it's all done locally which in the vast majority of browsers today is almost instant. You don't have to worry about reload/servers because the scripts should already be loaded and ready to go. If you keep the same look and feel it looks like the user was just navigating to a different page of the website. Don't make it too obvious from the look of your website that it's a crisis website. Of course, you make it impossible to navigate back to the original content. I would also make it clear on the panic button what the strategy is so that the user doesn't freak out.
I would still try to change the browser history and buy another domain that hosts a copy of the decoy page, as in the previous example. Not only if the domain name is suspicious, but in case the abusive user hits refresh or goes back in his history. You should make your entire website an SPA because you can only modify your current entry, not your past history. Of course, this would still only work in HTML5 browsers, just make sure no error is thrown and the other part of the scripts still runs in old browsers.
What do people think? any weaknesses to this? What would be good content to replace with?
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
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
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
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
Open a tab that wouldn't threaten their own lives (e.g. google.com, msn.com, yahoo.com)
Open another tab with your site
Navigate normally on your site
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.
This answer assumes that History and Address Bar aren't an Issue. At least, not immediately.
Scenario
Julie is a victim of spousal abuse. She is on the internet searching for help, and she comes to your website: http://www.crisisprevention.com (fictional for this answer)
As she is perusing your site, she hears her spouse approaching the room rapidly. She panics. Fortunately, you have a nice, large button, fixed to the page as she scrolls.
She clicks this button and ...
It takes her to Google.com
I dislike this approach for the following reason: no one is going to believe that you are simply sitting in front of your computer staring at the Google search prompt. Believe me. I've tried it before.
I used to keep a tab open with the Google prompt, and if I was browsing off-topic at work stuff, I'd switch to the Google tab so that no one was the wiser. It worked...sort of. Until people started to question why I was staring at the Google search screen all day.
I've since started opening a tab with various work projects in different states. Usually, stuff I'm working on anyways in between browsing. So, now I'm actually getting some work done! It doesn't take a tech genius to figure out this approach, which is why #LeeGary's answer may be the best.
It takes her ... it's still taking her ... oh Internet connection problems
Here's a reality you need to be prepared for. Perhaps the Internet Connection gets interrupted at the moment she is panicking. The current content stays displayed on the page while she waits for the HTTP GET request to get content it can start rendering...only, no content is being retrieved. The Internet connection is disconnected. This could happen for any number of reasons:
Spouse disconnected it.
Server being contacted is under extreme load.
Browser is running shy on memory.
ISP is having issues.
Dial-up connection/disconnect (yes these still exist).
Computer is just slow.
DNS server is down.
The reasons go on and on why the browser might choke when she hits the panic button, and it tries to move her to a new site.
Serve an Alternative Website Instantly
My solution suggests that you preload a website in the background of your site. Load it into a <div> and hide it behind your normal site. If it's a large bit of content, then you might consider hiding it with z-index instead of display: none. This way it will be pre-rendered (I believe, could be wrong here).
Now, it doesn't matter if her Internet connection is down. She already has the content. There is no latency involved with an HTTP GET request. It simply displays immediately.
If address bar is a concern, you might still be able to mitigate that by serving an alternative website that correlates to your domain.
For example, take the fictitious (for this answer) domain: http://www.crisisprevention.com
You could serve up some alternative article that relates to say, solving the world hunger crisis.
The idea here is that it's the initial first glance that is the most damning. When the spouse walks in and he sees her navigating away to Google.com, with that panicked look about her, he's going to suspect something is up and be more inclined to investigate. Likewise, it could be even worse if she's caught in the act of trying to hide her actions because the HTTP GET request was slow or fails.
There are some big problems with panic button:
it is hard to click on it (you have to be accurate)
it takes time to select it (and a huge amount of time if you are on laptop without a mouse)
it saves you in history
it is accessible via back button / backspace.
And how about the panicking random moves of a woman who is trying to quickly click on that button, when she was reading this. What if she will miss the button from the first attempt?
So if there are really human lives that could be saved, this is kind of bad idea.
The better way is to show them normal way of doing this (via some sort of help before you can possibly enter this site). It can be something like this:
Depending on the browser of a user you give them a list of steps to do which use only keyboard (no mouse at all). For example if she is on chrome.
open a website you like (FB, twitter, funny bunnies and pretend like you are doing something).
Press CRTL+SHIFT+N (opens incognito window) which will not allow backspace / history tricks
enter our site there (no copypasting to prevent checking what is inside of your buffer)
Read the stuff and always keep your hands on the keyboard close to CRTL and W
In case of emergency press CRTL+W
Continue starring at your FB, twitter, funny bunny
Surely you have to modify your explanation in appropriate language. But this way it is really hard to get caught. Also tell about sitting next to mirrors and other reflection surfaces like windows, glasses and other things. Ask them to try using these combination for some time to be familiar.
If human lives are involved, you have to be professional and do not use these panic buttons. Especially if it is so easy to teach people how to do it quicker and more secure.
Answer to Nobius
I got you point, thank you. But I disagree with your point.
After a lot of campaign for it to be put on FB, have you actually seen it on FB? I have not. Nontechnical people are notorious for coming up with ridiculously bad ideas, some of which you might have experienced (preventing right click on banks' pages to improve security, 4 digit passwords to be easier to type from mobile phones). Pressing a button sounds easier, but look at my list of steps - the only thing you need to do in a stressful situation is pressing CTRL+W. You do not need to think in terms of tabs, modes and other things. This comes up to basic pattern - see someone, press CTRL+W. In my opinion this is not difficult at all and easy to remember. It is by far not harder than to remember to click on the button. Everything else you have to read in a normal atmosphere.
Pressing 2 buttons is MUCH faster than moving mouse, and it is really hard to miss them when your fingers are on them (do an experiment and put yourself in stress full situation and try to quickly click on that button). Also as I mentioned - I see at least four reasons how something can go wrong in panic button situation, whereas I see much less in reasons in CRTL+W. If humans lives are involve - you need to be professional.
Answer to NicolasMoise. Why people keep saying that you need to be tech savvy for pressing CTRL+W? I am not trying to show people how to use TOR, VPN, setting up encryption channel. This is just CTRL+W. People learned how to play angry birds to waist their time (which is much harder than to remember 2 buttons), so people can learn CRTL+W to save their lives. Tutorial can be shown in such a way that observer can not understand why you are reading this (when you see my list of steps, I do not believe that the first guess would be - ah this is for women abuse site).
But most probably giving people perception of false safety is much better. The answer is not off-topic. The person is asking how to implement panic button - and I am explaining why is the current way flawed and what can he do to do it better. It is on the same level as 'I want to make communication secure and I am using substitution cypher', yes you can improve the speed of his cypher and pretend that everything is OK, or you can show another way.
One last attempt to explain my additional point: you have to properly explain people the risks behind your approach. A good example when people suffered from not explaining problems properly was the issue with Belorussian bloggers, who thought that posting anonymously on the internet will make them untraceable from governmental repressions. The resource gave them false belief that they are save if they do not provide their real identity. They learned that this is not true in the hard way (when they were jailed for few years).
If someone would explain them the risk I think some of them would be happy to learn how to use any tool to save their next five years.
So why not to give women few options:
you can use approach A right away, and here are the list of problems you can encounter.
you can use approach B, which requires X minutes during the first time to read and to understand something. And then your list of possible problems decreases to a smaller list.
And let them decide what they want to do. This way they know the risks.
I think you still have a long journey ahead of you.
The reason for sending people to the Google page is that
it loads very fast
it's likely to be cached anyway
it renders very fast
it's really well optimized
did I mention it's fast?
The link you provided is slow.
If you want to provide a fast way of changing the screen then open your site in a frameset - with the cloak in a frame of height 0, and your site in a frame of full height. Then when the user clicks on the link swap around the frame heights and redirect to the top level window to the page already loaded.
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.
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.
You might take a look at the "Boss" panic buttons on some old games and sites. The idea is that you could switch quickly to something innocent looking if your boss came by (of course, you have to see them approaching first!).
Almost any hurried/frenzied action when the abuser comes in is going to arouse their suspicion. Consider designing the screens so that they look like general news or the like (from a distance), with no large titles or pictures giving away their purpose. This could often allow time for a "leisurely" exit from the site, without panic. If the panic button link takes the user to, say, a bona fide news site, so much the better (if it comes up fast enough).
As others have mentioned, if the abuser becomes suspicious (and many control freaks are), there's still a history trail on the browser that they can quickly find out where the user has been. Frankly, there's not much you can do, especially if the user goes into a frenzied panic mode trying to cover their tracks, and the abuser sees this. Even if the screen itself can be refreshed to something innocent after some timeout, the browser history will have the URL.
Consider advising users to position the computer so the abuser can't sneak up on them from behind, or to go to a library or other non-private place to use this site. If the screen content is dull looking from a distance (see above), it shouldn't attract interest from others.
Good luck with this!
You could show an error page instead of an actual site, which is already loaded in the background. Maybe a fake youtube or google 404 page? I think this would keep the size of the extra content to a minimum.
As others have suggested, I would also use the escape key. Reduces the change of missing it, would be a lot easier for someone with a mousepad and the user can keep his/her finger on it when he/she is just browsing through the site.
You can also use other options; a button on the page itself or let them know about other methods of escape (ctrl + w, as mentioned before).
Maybe also a gesture for the tablet users? There are probably some libraries for that.
And of course, you could change the url in the taskbar. (See other posts for code on how to do that).
Encourage them to try the escape options out. So they know what they do and how they can react to it.
I think we can do this differently. My Idea is as follow:
Show the website with only fake content (similar style and layout with the real one).
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.).
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.
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.
I have a set of ads that are written out by document.write because that is the only thing that the adserver will do.
I have seen other sites reload ads on the page if the user sits there for a while (something I may want to do in the future). So I was playing with loading the ads in an iFrame, then moving them out into the main window afterwards. This seemed to work quite well, until it served up a google ad which is itself in an iframe within the iframe. Is it possible to pull them out properly / move google ads around the page at all?
This is what I have currently, and it works for everything but iframed ads within the iframe.
$().ready(function(){
$('#iframe').load(function(){
var middle_ad_contents = $('#iframe').contents().find('#middle_ad').html();
$('#ad_middle').html(middle_ad_contents);
});
});
[edit]
Upon further investigation... it looks like reloading google ads may be against the terms of service, perhaps I shouldn't do this?
[edit 2]
Reloading the whole page is not really an option (and kind of a dick move).
The point was to perhaps rotate the ads, but more to stop them from blocking the pageload because adserver X, which is being served through adserver Y which is being served through adserver Z is slow/not responding. The iframe seemed like the best solution because then I can delay the document.writes which are 2 or three levels deep until the end of the page without them wiping out the whole page as document.write after pageload === document.replaceTheWholeDOM. There is also the perhaps the option of monetizing ajaxy/other iframed (shudder) content with this method.
The best way to go about this is probably using a document.write replacement. There are several to choose from, but here's one: https://github.com/eligrey/async-document-write
This will replace the global document.write function with one that can be used even after the page has loaded.
Not only may it be against the terms of service, but it is also lowering the value of the ads to the advertiser and creating a clunky element in UI.
Think about it from a UI standpoint...you're on the site, concentrating on something, then everything flashes. Your attention goes from what you were concentrating to to figuring out what just happened. Never mind, just a banner flip. Next.....now, where was I?
For the advertiser, what if you notice the ad and are about to click on it and BOOM, it changes. Now what, can you go back? If not, you just lost revenue. Users spend seconds on many pages, so unless you've got an incredibly "sticky" website, how much exposure is the advertiser really going to get? Remember, Google rewards AdWord sites for clickthroughs, not based on volume shown, which can actually hurt your CTR.
If you're determined to make this happen, I think I would consider attacking it by having the ad server post directly as it's intended into the dom, then use a javascript-based timer to asynchronously ping the adserver and again tell it to redraw the desired div. I would avoid iFrames like the plague because they're just not friendly in this age of simple Dom manipulation.
Or, you could just take the MSNBC approach and reload the entire page every X minutes. It's a horrible UI pattern, but it would achieve your goal and likely bend (but not break) TOS.