# Trying to create safe website where security is handled by the website and not the user

I work with civil rights for children and youth and am trying to create a website for LGBT youth and children and their families. The website needs to be safe as it is still very dangerous in many countries to admit to being gay (or LGBTQ).

I have a series of short children's films that I would like to make accessible for free on a website but the youth, families and teachers who access the site need to be untraceable.

Can I make a website where the security lies within the website?
People and kids coming to the site will not be setting up their own security measures to not be traced.

• The website itself wouldn't be able to do this, you would need to have them all using VPNs, or you could create a Tor site, but these both require software/configuration on the user's end, and a certain level of technical know-how. An HTTPS site would encrypt the web traffic, but where the web traffic is flowing to and from would be easily traceable. To be honest, I don't know if this is possible. Hopefully another user's answer can enlighten us both to a possible solution. Maybe some sort of authentication process to allow only the children and their families to access the site? – INV3NT3D Oct 6 '16 at 15:19
• Can you host the contents on another "innocent-looking" website like Facebook/Youtube/Google sites/Google Drive shared folders? These sites can be accessed using HTTPS throughout and does not stand out from typical usage. – billc.cn Oct 6 '16 at 16:36
• @FDoherty May I ask how you intend to promote the website to your target audience? – tmh Oct 6 '16 at 19:49
• Use https, and detect + enforce incognito mode. security.stackexchange.com/questions/9037/… – Kyslik Oct 6 '16 at 22:31
• To whom do they have to be untraceable? Do they have their own computers or do they have to use public computers? – v7d8dpo4 Oct 7 '16 at 9:04

Don't do it

If you are targeting unsafe regimes, the consequences can be severe. For example, in Iran, condemned homosexuals are usually sentenced to death by hanging.

It would only take the slightest lapse on the part of your site, or one of your users for this to be incriminating evidence. Can you imagine the guilt you would feel that your well-intentioned site ended up being evidence that led to an execution?

To operate online subversively in a repressive regime takes extreme skill and caution. Simply using Tor would be a red flag in itself. While hacker groups like anonymous may be able to get away with this, normal users cannot.

There have been comments on other answers saying (roughly) "use HTTPS, it's fine". I cannot stress strongly enough how that is dangerous advice. HTTPS reveals the domain name the user is accessing, it leaves trace on the client computer, and it's likely that nation-states (including Iran) can produce fake certificates and intercept all HTTPS traffic.

• I agree with you that OP should not be doing this (if he has to ask random strangers over the open web for security advice), this is not an answer. He did not ask about the ethics or the dangers of doing it, just how he could do it and how to secure it. So i have to regretfully downvote. – Mindwin Oct 6 '16 at 20:21
• @Mindwin - In answering questions it is important to understand the context and consider the underlying issue the asker is facing. I am somewhat surprised that you agree with me and express that by downvoting. Are you going to tell me next you've upvoted other answers you disagree with, because they answer the precise question? However, thank-you for at least leaving an explanation, bizarre as it is. – paj28 Oct 6 '16 at 20:40
• @KevinWells - The other answers don't mention leaving trace on the client, which is a critical issue. And the fake certificate issue is not theoretical. I stand by my claim they are giving dangerous advice. – paj28 Oct 6 '16 at 21:51
• +1 Client side history will give them away and OP can do nothing about that. His idea is simply not possible. – Agent_L Oct 7 '16 at 12:36
• @Mindwin I disagree with your philosophy on answering. What is asked is not always what needs to be answered. One famous category of questions demonstrating this is the XY problem questions. Also, this answer seems to fall under example 8 or 9 from this answer explaining what are good answers. – David Starkey Oct 7 '16 at 21:02

This is not an easy thing to do. There are a few different ways to get something like what you want.

First, use HTTPS. This stops anyone from seeing the data being transferred other than the server and user (which I am assuming are both clean). This does not stop external people from seeing that the user has visited the site, only the exact data that is being transferred.

If you have things hidden behind a login screen, then anyone without a login visiting the site will not be able to see what the site is about. This is not very good as you need to trust the users who do have login details and you need to devise a way of recruiting trusted people to view the site.

A better way is to have 'normal' content to hide the other content and no way of working out what type of content is being requested. The best way of doing this is by, each time you serve a link, you serve a url that will only work once (or less secure, one that will only work in conjunction with a cookie that is unique to that user) this will give the user plausible deniability of what they were looking at. Nobody can prove that they didn't visit the 'normal' content as anyone watching the data transfers, visiting the same pages would either get an error message or 'normal' content (depending on how you set it up)

I hope the sugestions above help, the reason there is nothing like 'change setting xxx on the server' is that you want any user to be able to visit the site, this has to include those who will persecute those also visiting.

• Offering plenty of "normal" content, and providing single-use "tokens" (URL, cookie, etc) to the "dangerous" content is about the only way to do it. For best obscurity/deniability, once used, a single-use token should serve a specific piece of normal content (possibly selected at random upon generation of the token)... so anyone who attempts to replicate the vulnerable user's connection will only ever see normal content and all subsequent attempts to use it will see the same content, so it behaves as the token would if a user were legitimately trying to view the normal content. – Doktor J Oct 6 '16 at 20:10
• This advice is not appropriate for countries where it is "very dangerous" as the question asks. I've included some details in my answer. I think your answer is well written, so we shouldn't delete it, but you need to include a prominent disclaimer that this is not suitable for "very dangerous" countries. Until you do that, it's -1 from me. – paj28 Oct 7 '16 at 6:57
• Even the plausible deniability of being unable to prove the content that was served for a given URL plucked from the browsing history of a user or via other means won't remove the fact that the browser may retain cached copies of the dangerous content (which would need to be purged) or that the user may simply be caught in the act. The end user must take precautions, this isn't something that can be dealt with by the website alone. – pwdst Oct 7 '16 at 17:02
• Note that TLS leaks the size of the accessed page, which may be used to what content is accessed. – user2428118 Oct 7 '16 at 19:38
• @pwdst Your comment inspired me to write this answer. – Dennis Jaheruddin Oct 8 '16 at 11:03

Your requirements as stated are physically impossible.

Think of it like this. If you were posting a letter to someone in another country and wanted to be sure a powerful dangerous group was both

1. unaware of the content of the letter

and

1. unaware the recipient got a letter from you

how would you do it ?

The security on your side could be fantastic but that doesn't matter once the letter leaves your country.

If the letter is intercepted at any place from your desk to the recipient's desk then your recipient is at risk.

Thus security is the shared responsability of

• you (the webserver)

• the international postal system (the public international internet - crawling with goverment spying!)

• your recipients postal system (their ISP)

• your recipient (their PC, web browser etc)

In cases where the recipient has the training and tools to establish secure connections then it can be practical to communciate securely by just securing the 2 end points.

This requirement that both end-points must actively participate in a secure communication link is an inherent technical limitation of the global internet including any technology "built" on it. The "default" network has no "built-in" anonymity security and thus is very easy to spy on by those in control of the physical infrastructure.

There are better technical ways to build global networks such a F2F radio meshnets, but only limited small examples exsist as yet.

You may need to look at alternate distribution methods and talk to your users and other organisations to see what they think is practical.

• -1 It is not an inherent limitation. You can transfer data to recipients without anyone knowing about the recipients nor the content. (for example, Tor onion routing and HTTPS). With HTTPS, only the domain name is known. This analogy is completely wrong in this case with regards to HTTPS. – Ramchandra Apte Oct 6 '16 at 17:26
• @RamchandraApte I was referring to the fact that both ends must participate in the security procedure as a limitation (which is true for Tor etc). This is the focus of the question. Answer updated. – John McNamara Oct 6 '16 at 18:15
• @RamchandraApte My understanding is that it is not accetable for an attacker to even know the name of the domain as it might be listed as "illegal" regardless of what communication occured with that domain. – John McNamara Oct 6 '16 at 18:32
• @RamchandraApte That's great, but https is not at all helpful in this instance. Even if the name is not descriptive of the site's purpose, and transferred content is encrypted, the threat actors in this scenario would only have to visit the site to determine that it's a resource for LGBT people, which would be sufficient for them to persecute or otherwise harm visitors to the site. – HopelessN00b Oct 6 '16 at 19:34
• @RamchandraApte - By default an HTTPS site appears in the user's history - which would be visible to other users of the computer, and to police searches. There are solutions to this - but they rely on the end user taking basic precautions. You should revoke your downvote, it is unfounded. – paj28 Oct 6 '16 at 19:42

This is an addition to @TopherBrink's answer, with which I agree greatly. First of all yes, use HTTPS and HSTS, and do have things behind a login screen. Second, we need to see some ethics:

### Ethical discussion

This is the internet, all content is there, if someone wants it he will get it. It may be blocked by firewalls, and someone will find a hole puncher or use a proxy/VPN, it may be DNS filtered and someone will make a website of IPs to use.

If the content is dangerous there are humongous risks in several countries: prison, torture, death penalty. But against those risks you have pretty much two options:

1. Don't do it and allow someone else to serve the content to these people. There will be someone else, this is the internet.

2. Do a best effort on deniability. I disregard deniability as poor security, but you do not really have options.

And I did see teenagers being able to use a VPN based on tutorials found on the internet. The problem is that, although their configuration worked, it was leaking a good deal of info. In general if you do not serve the content someone else will, even if the content needs proxies/VPNs to access.

The ethical cause is more complex than don't serve it and don't be indirectly responsible for someones death. If you give up on serving the content you are still responsible for someones death if he was caught by accessing content from a place that was worse secured than what you could do.

Escaping responsibility is not an ethical point. Therefore I'll defend the least popular option and argue to do it. But make the best effort you can on deniability.

Final ethical note

Always remember that some users are just stupid, and therefore there is no way of protecting them. If you cannot deal with the fact that at some point or another you will need to sacrifice one for the good of many, then don't do it. But don't do it for that reason. Not simply because it is dangerous.

### Deniability proposal (i.e. one way to do it)

The biggest issue is that you need to find a way to give logins to trusted users and not give them to not trusted ones. One way to go around that it to have two websites, let's say: safewebsite.com and secretwebsite.com.

(Both domains running only over HTTPS, and implementing HSTS)

safewbsite.com will contain safe content, will be accessible without a login by default but users will be able to register.

secretwebsite.com will always return the same "safe" page for anyone. The only way to get the rest of the content is to be authorized, i.e. be a registers user of secretwebsite.com. Now, there is no way to register on secretwebsite.com (it returns only a single page). The only way for secretwebsite.com to give you the correct token (let's say a httpsonly cookie for simplicity) is by issuing a GET to the correct URL. Say https://secretwebsite.com/logon/6733abf78..77bab99 (or base64 encoded, whatever). That URL is your session token.

(using GET for authentication is bad, but since we are on HTTPS and the URL is a proper, difficult to guess, token it is acceptable).

The token must be difficult to brute-force. And the only way to get a correct token (a correct link to secretwebsite.com) is from safewebsite.com.

Now, you can choose (literally cherrypick) users from safewebsite.com who can access secretwebsite.com.

The merit of this approach is that you create a triage area (the safe website) from which you can choose users that will be responsible enough to access the secret website. If you construct the session mechanism correctly, you can give and take the ability to access the secret website from your users.

The problem is that this will work only for a small number of users, and is susceptible to social engineering against you. Making and algorithm to evaluate truthfulness of a user is no trivial matter (if at all possible), therefore there is no way of automating the user selection. Another issue is that you need to prevent safewebsite.com from becoming a discussion ground about how to access sectretwebsite.com, since then you completely lose control about who is trusted and who isn't.

### Security summary

Good points:

• secretwebsite.com does not exist, OK? No, it does not, it is always "under construction". The fact that someone saw something in there is a creation of his own mind.
• You can take out logins of problematic users. Or better, you need to take them out. If a user openly talks about secretwebsite.com on safewebsite.com he is doing more harm to both websites than good.
• You give deniability to yourself and your users. To make it a little more plausible you can randomize the size of the (fake) page sent from secretwebsite.com (so arguing that someone gets a page of different size is not viable).
• There is also a point of confusion. Since no one knows how to actually access secretwebsite.com (the URL appears to certain users and doesn't to others based on your whim, which cannot be quantized), you can shutdown secretwebsite.com temporarily in dangerous times.

• Deniability does not work against an attacker that wants to do something to you just because he needs to do something to someone (namely, he needs a scapegoat). Deniability will never prevent anyone from being a scapegoat, but neither will any other security measure if the attacker has physical and judicial power over you.
• You will need to deal with urban legends about secretwebsite.com. It is important that you do not allow them to roam free on safewebsite.com, otherwise you will have a visible correlation.
• Deniability works because in modern society suspicion is never the same as proof (i.e. suspicion != proof). The moment an attacker can rely on his suspicion to sentence someone, he can do it at his own whim. The good side, is that such an attacker may be suspicious of anyone, and going through website loops is a lot of work compared to catching someone random on the street.
• It is a lot of work. If the community of your users grow you will need very ethical moderation, which is difficult to find.

Extra notes:

• Is it dangerous? Yes, people may get caught. But they would be scapegoats anyway. An authoritarian regime needs scapegoats, you need to make sure your users are harder to make into scapegoats than others.
• You said a lot, but would such a website work in the real world? Yes, it works. Once upon a time I helped setting up one such website. It was 5 years ago, and the website is still alive. Both the safe and secret sides.
• Can you tell us which website it is? No, read above for the reasons why.
• -1 as this is simply asking for problems. Only 1 user needs to leak an url with description (on purpose or by accident) and all users who ever accessed it are encriminated. – Dennis Jaheruddin Oct 8 '16 at 10:54
• @paj28 - Not exactly what you wanted but there it is. I added an ethical discussion instead of a disclaimer. Doing nothing just because it is dangerous does not make thing safer. – grochmal Oct 8 '16 at 13:01
• @DennisJaheruddin - Full ethical discussion added. But also, that's not how it works. This is a real world case of smoke and mirrors, it works in practice because authoritarian regimes are concerned about amounts of scapegoats. You cannot execute a million people, but you always need to execute 3 or 4, does not matter what they did. Kick the 1 user out and leave the death of one to protect the many. No I'm not doing PC ethics, but PC and ethics are two different things. – grochmal Oct 8 '16 at 13:04
• @DennisJaheruddin - But what will the authority check? Everyone knows that secretwebsite.com may be (and probably is) illegal, but where is the proof? We know of several things that are illegal, but there is not way to prove it. If our governments (the ones not authoritarian) would destroy anything that an authoritarian goverment suspects of being illegal we would be in real trouble. – grochmal Oct 8 '16 at 14:28
• If any trusted user can see the content of secretsite (which is presumably exactly what the asker would want), then with this setup they would just need 1 collaborator to prove which content is there. – Dennis Jaheruddin Oct 8 '16 at 14:39

I mostly agree with what Topher Brink wrote. Just some more points.

It's probably not enough to only have safe content, you calso need to have considerable traffic accessing said content. Search engine hits, the likes. Otherwise any visit to your site may get associated with the sensitive content even if there is other content lying around.

If fake certificates can be an issue in the country in question, you could ask people to verify certificate checksums. But since the most plausible way to introduce fake certificates would be tampered browser installers, I wouldn't trust those checksums either. So don't use this targeting countries where you can't expect users to have clean browsers. The same goes for state-sanctioned keyloggers and the likes. The technology-provided privacy ends at their machine, and if that machine is not private, the connection can't be.

You should remember that the single-use links should be generated by the site and should be available to every visitor. Perhaps optically hidden as a black link on some insignificant period at the end of a sentence, with the mouse cursor kept as the one used for text selection. But people should never have to write down these links, to use them for later return visits or to give them to friends. They should be able to tell their friends “just click there and you'll see stuff you need to see” without passing on any incriminating URL. And they should only ever say this verbally, face to face, not in electronic communications since the fact that you know the way in is itself incriminating.

You should make sure that safe and sensitive pages are as similar as possible, with respect to the traces they could leave on a machine. Same HTML title, same favicon, same cookies. Preferrably even the same image files. If that's not possible, you'll have to tell your users to purge their cache after the visit, and explain to them how to do it. Best also explain to them how to use the anonymous surfing facility of most common browsers. At least after having checked that these don't leave any detectable traces of being used, which might be hoped but I'm not certain.

And you should include all relevant guidelines for user behavior (clean cache, watch who's watching, ensure your computer is uncompromised, no written instructions to others, never accept insecure certificates, relay these instructions to others, …) are shown to visitors prominently and frequently. But in the end you can only hope they'll follow this guidance, you can't control these aspects remotely.

• I like this answer, unfortunately having the user purge their cache would mean that the security does not really lie within capable hands in all cases so it is not yet 'complete'. – Dennis Jaheruddin Oct 8 '16 at 10:58
• @Dennis: Yes, you can't have complete guarantees with neither control over visitor's harware nor cooperation from visitors. But clearing a cache after reading instructions on this is probably far less problematic than setting up something like tor before even looking at the sites that might describe how to do that properly. – MvG Oct 9 '16 at 19:12

Without describing the 'how' in detail, I believe this description of 'what' you should do may help in developing something that works as well as possible.

## Situation

It seems like there are a few key steps in the process from a users point of view.

1. Connect to the server
2. Browse content on the server
3. Leave the server

## Challenge

It should not be possible to prove that they viewed something related to topic X. Their internet may be monitored permanently, and their computer may be confiscated after they are done.

## Solution

I believe that with these solution parts together, you will have an reasonable situation.

1. Make sure it cannot be proven that one connects to content on topic X. It seems like the most practical way to do this would be to have someone connect to a general site, which also contains topic X. Something to consider here, is that even if governments cannot technically prove that people connected to your site to view topic X, this may still be inferred if your site gets only known for that, and not for its normal content.
2. Make sure that once connected, it cannot be proven that topic X was visited. Of course the connection should be encrypted (https?!) and the site should not keep logs that may encriminate people, the site should also definitely be hosted in a safe country.
3. Make sure that no traces are left behind client side. This has not been touched much by the other answers, but is crucial if the PC of the visitor may be inspected the next day. Unless I am mistaken, this automatically disqualifies making the content available in a regular browser. Perhaps it is not needed, but a solution for this could be that visitors of the site (not only those that visit topic X) do not view the content normally, but via a dedicated client. This client would need to be designed in such a way that it does not keep history, cache, downloaded videos, and so on.

## Is it worth the risk?

As mentoned before, offering this kind of content to people who may go to prison if they get caught is not a decision to be taken lightly. My recommendation here would be to only do this if you would expect them to find similar content anyways (in a less secure way).

• For point 3, the dedicated client could be built entirely on javascript, so from user viewpoint they're just using a regular browser in a regular tab. Developers of Single Page Applications had to manually add history & deeplink support, so in this case the site could just skip them. If every resource is retrieved, decoded and displayed painfully through the javascript client api calls instead of standard resource download, there would be no content file to cache. However ... – Martheen Oct 10 '16 at 4:53
• The resulting site will be slow (no caching, inefficient calls), annoying to use with point 2 implementation (with no log, you need to trudge back to whatever you read yesterday), so it's hard to pass point 1, why would anyone use this site for normal content with it's slow speed and inconvenience? Tor's change of branding was criticized for this point. So I suppose you need to sell the site as corruption whistleblower (or whatever cause prefered by the gov) with additional content – Martheen Oct 10 '16 at 5:00
• There are still methods to see what content someone viewed. Each Site/Article/Video will have a different size and analysis of the encrypted transmission leaks information about that, for example. – Josef Sep 10 '18 at 15:01
• @Josef Probably leaked information can be statistically analyzed, but given the question (some video's) and assuming these videos would not have unusual sizes, I would not expect anything statistically significant to come from this (unless someone were to visit the site for a very long time on a regular basis) – Dennis Jaheruddin Sep 20 '18 at 8:19
• @DennisJaheruddin I think the probability that a decoy website will differ statistically significant from the real website is not that low. E.g. do you assume for each video produced for the real website there is a decoy video with the same characteristics (like bitrate over time) produced as a decoy? Bitrate over time is not that hard to analyze from an encrypted bitstream when using common HTML video players in browsers... And this is just one example. – Josef Sep 20 '18 at 8:58

We can't. The client must participate. We cannot use a safe/secret pair of websites if the userbase grows. A single leaked link can be used to prove the contents of the secret website, simply for how HTTPS works. The content provided by your website is signed by your website, with a publicly accessible certificate. (Otherwise we can't know we're getting the right website, you see.) If someone can prove the certificate is yours, and has a copy of the signature you sent to their browser (which they can get just by clicking through a few menus in Firefox, by the way) they can prove the content they say you served is authentic.

It is also worth noting that we cannot simply eschew the signature on the website content, lest we lost our content's integrity as well.

So no deniability, if anyone leaks. (This is in reference to grochmal's answer.)

Tor is our best answer, but it is incomplete. There is no good answer to the question you are asking. Still, Tor bridges / pluggable transports may be of use.