1

I am working with a Domestic Violence support organisation to build a website and have been asked to provide a "Quick Exit" function. The purpose is to enable the user to exit the site quickly without closing the browser. I have seen such buttons on similar sites and the normal scenario is that they simply cause a Google search page to be shown. (easy but doesn't hide history)

I am looking for ideas to improve on this function to hide/disguise the history stored in the browser as this is currently a fairly significant flaw with the Quick Exit buttons I've seen to date.

I had a concept but I am looking for input on either fleshing out my concept, or other alternative directions to consider.

My concept was to have two domains: let's call them dv-site.com and decoy-site.com. The former being the source of domestic violence support information and the latter being some random content, could be anything, lets just say weather information for the sake of the conversation. If a user navigates directly to dv-site.com the server redirects to decoy-site.com but also attaches some session specific, or perhaps single use query string or similar. decoy-site.com validates the query string and, if valid, loads dv-site.com within an iframe or something like that so from the users perspective they are just looking at dv-site.com, though the domain recorded in history is decoy-site.com. Links within the iframe loaded site would similarly be redirected with the same or a new query string. If a user was to click on the browser history and go directly to decoy-site.com it would not be able to validate the query string and would just load the decoy site like a normal site. i.e. just showing weather information that exist on that site.

Domestic violence is a serious systemic issue and I would love some input from anyone who has more technical knowledge than I do on fleshing out this concept.

Other aspects I am unsure of how to tackle;

  • ensuring that dv-site.com can get crawled and ranked by search engines, even though users are all redirected, as it is imperative that it appears in search results so it can be found
  • technical aspects of a redirect that does not appear in history.

I'm unsure if it's possible to do this without all content and engagement being attributed to the decoy-site..

mike_temby
  • 23
  • 5

1 Answers1

1

For the redirect, I believe that HTTP redirects do not get stored in history. You can use a 302 redirect for that. HTTP has a set-cookie header that lets you record a cookie - coupled with the headers here, you can give the decoy site access without recording it in history. Then, delete the cookie.

As far as pagerank goes, you could add a line to robots.txt as described here (the last point) to force the bot to scrape using a query parameter. Then in the backend, return the dv site only if that parameter is passed, otherwise redirect. If the googlebot removes query params when publishing, it will work out. Otherwise, it might fail.

Best of luck.

thshea
  • 1,048
  • 6
  • 18
  • Browser history does store query strings by the way. Using them will not help. – thshea Jun 11 '21 at 03:04
  • It wont matter that the query string is in the history. It wont have anything meaningful, just an alpha-numeric string. The purpose of the query string is to validate that the user came from dv-site.com. It would be a single use string. decoy-site would validate with dv-site that the request string is current/valid and then once done, dv-site would invalidate it. Thus it's single use. If someone clicked on the browser history item, the string would not be valid anymore so decoy-site would just work as decoy-site (not loading dv-site). – mike_temby Jun 11 '21 at 05:25
  • Ah, that works great then. As long as you can make sure a key isn’t reused within a reasonable amount of time. And if you are invalidating keys after the first visit, you should probably set a time limit in case: someone visits the site on slow internet, redirects but loads slowly, if it doesn’t finish then the key may work when visiting history. – thshea Jun 11 '21 at 12:09
  • Is this a private project you are being paid to do or is this open-source or volunteer based? – thshea Jun 11 '21 at 12:09
  • The website build is a paid project, however this idea will be open source. It’s (obviously) just conceptual at this point but I’d like to get something more robust than current “quick exit” buttons documented for others to use. There are quite a few hurdles to get through afore this solution is viable. Content and user engagement attribution by search engines to he decoy site would be an issue that I can’t think if a easy way round. – mike_temby Jun 11 '21 at 12:17
  • If you wouldn't mind, could you send me a link to the repo once you set it up? – thshea Jun 11 '21 at 12:23
  • Sure. Happy to. – mike_temby Jun 11 '21 at 12:27