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've written a web app that uses an ad banner on the side to support free accounts. Problem is, since the ad is loaded in its own <div>, it's relatively easy to go into developer/debug console in any modern browser and either remove the div or resize the ad to 0px using CSS overrides (the users might do this to gain more real-estate in the app workspace). To prevent this, I was considering checking periodically if the properties of the div with the ad change at all (including CSS style), and if they do, reload the page. Since I'm relying on a canvas element for some drawing, a reload would be relatively annoying to the user since it would clear the canvas, so I don't want to do it unless the advertisement was tampered with.
I've seen some similar questions about tracking DOM changes where people suggest using mutation events. However, based on the answers, it doesn't seem like the support is there in all browsers yet (then again, the threads I've seen are from 2008 and 2009, so things might have changed since then).
Another alternative I was considering is just reading in offsetWidth, offsetHeight, offsetTop, offsetLeft of the div with the ad after the page finishes loading, and keep comparing them periodically against current values (there is not a whole lot you can do to make the div go away if you can't move it).
What do you guys suggest?
You'll never stop someone who is comfortable enough with the DOM inspector from doing that. It's not even worth the cat and mouse game. 99.999% of users would probably call tech support if they accidentally accessed the DOM inspector.
If a visitor is using say Firefox with Adblock, your banner is never going to appear in the page so mutation events won't be dispatched. You can look at the style properties and re-load the page, but it won't make the ad appear. A constantly re-loading page will annoy users so they'll leave.
If you're OK with that, go for it. Otherwise, realise that anyone disabling your ad was never going to respond to it anyway so what's the point?
This is a very urgent problem and I'd be forever indebted to anyone who can lend some insight.
I'm going to be deploying a widget (called the "ISM") to a third-party site. That site uses the document.domain JavaScript property to relax cross-domain restrictions (e.g., setting document.domain in "a.example.com" and "b.example.com" to both "example.com" so they can access each other's DOMs).
This causes problems with my script in Internet Explorer due to the way that I construct an <iframe> that is used to display my widget's HTML content. In Internet Explorer, using document.domain on a page, and then creating an <iframe> with JavaScript, will cause you to be immediately "locked out" of the <iframe> - i.e., you can create it, but it's not created in the correct document.domain, so you're not able to access its DOM due to security restrictions. This isn't a problem in any other browser.
To see what I'm talking about, load this page in IE:
http://troy.onespot.com/static/3263/stage1.html
You should see a JavaScript error: "Access is denied."
To get around this, I'm setting the dynamically created <iframe>'s "src" attribute to load a static HTML file that's hosted in the same domain (different subdomain), and setting its document.domain property to the appropriate value:
http://troy.onespot.com/static/3263/stage2.html
That gets around the security issue, and lets me write the document I originally wanted to write to the <iframe>:
http://troy.onespot.com/static/3263/stage3.html
With that document in place, my widget does some polling to our server to get some HTML content that I want to insert into another <iframe>, which will be visible to visitors of the parent page. I've roughly simulated that here (using static content, not actually contacting our server):
http://troy.onespot.com/static/3263/stage4.html
Here comes the problem. When I get that HTML content and insert it into the second <iframe>, I now face an unusual issue with a broken "Back" button. This happens in Firefox 3.0 and all version of IE (possibly other browsers), though it does not happen in some browsers I've tested (Firefox 3.5, Safari, Chrome). See this page:
http://troy.onespot.com/static/3263/stage5.html
If you click the "Google" link, all seems fine. But, when navigating back to the previous page (that has the latter test script), another JavaScript error is introduced: "Permission denied." This does not terminate the script, and does not appear to have any ill effects, other than the fact that I assume it's connected to the broken "Back" button functionality, which is a very big problem - the one I'm desperately trying to solve. I'm at a loss to debug this error since its call stack starts and stops in the jQuery script.
You can also encounter this error - with more serious symptoms - by going to the last link above (stage5.html - clear your browser cache first). Click the "Stage 5 (Again)" link, then, after that page has loaded, click the "Back" button.
The "Back" button is completely broken! You can't go anywhere except to another URL.
This is the problem that I need to solve as soon as possible. Any insights or help would be extremely appreciated!
I can't deviate from this method too much, so outside-the-box suggestions are definitely welcome, but I may not be able to use them due to the constraints of the widget's specifications. I would prefer to understand why the "Back" button is breaking and how to fix it, along with the "Permission denied" error related to jQuery.
It's really hard to try out fixes for this because of the multiple domains. One thing I've heard is that IE treats a blank src or "about:blank" as a different domain, but it treats 'javascript:""' as the same domain. Have you experimented with changing stage one to set the iframe src to things like:
iframe.src = 'javascript:""'
Or:
iframe.src = 'javascript:parent.getFrameHTML()'
Part of the problem seems to be that IE (at least IE 7) adds two entries to the history named "Domain" when I click on the "Stage 5 Again" link. When you use the little drop-down arrow next to the Back button you'll see the history of pages allowing you to step back more than one step. I see the previous two entries are listed as "Domain" and clicking either of those brings me to the same page. The fourth spot (after Current Page, Domain, Domain) is the correct "ISM Back Button" link to the original stage5.html page.
So the problem isn't exactly that the back button doesn't work, but just that the entries in the history are added and so the back button takes you to the wrong place. I don't have an answer as to why those "Domain" entries are being added to the history, but hopefully this helps point you in a useful direction.
Good luck!