First off, realize that each community on Stack Exchange is different. You can ask the same question on two different sites and have it closed on one and open on the other. That said, ***please don't crosspost questions***. Really, pick the best one and post there first. Posting the essentially same question unless it is specifically tailored to the community of the site fragments the information and questions across the network making it harder to find *the* answer. Getting more attention to the question by cross posting is not a good thing. Now, lets look at the question posted to Programmers.SE: > Is it fundamentally possible to validate that an unmodified version of your client connects to your server? And compare it to the one posted to Security.SE (without the leading meta bit): > This seems like a programming question but it's really a fundamental security question. > Is it fundamentally possible to validate that an unmodified version of your client connects to your server? > I was just thinking about the idea of having my client-side app hash it's own source code and send that as a key to the server with any requests as proof that it's unmodified, but that's silly because anyone could just have the client send a hash of the unmodified version via a modified version. > I was wondering if there might be a secure way to do this though, via some sort of proof that the client was unmodified. If you think that this was a security problem, you should have asked it there. Additionally, there is quite a bit more material on the Security.SE one than the P.SE one. You are complaining that the one here got closed for too broad? I will also note there is *absolutely* no effort at tailoring the question you asked for Programmers.SE community. I will remind you of the post on Meta.SE: [Is a question that specifically asks for a summary of a broad topic valuable to Stack Exchange?](http://meta.stackexchange.com/questions/234642/is-a-question-that-specifically-asks-for-a-summary-of-a-broad-topic-valuable-to) and the points that I made there: > Programers.SE generally has the approach that you should at least have done a search on google and possibly read the corresponding Wikipedia page. This is especially true of questions that are likely to be broad. The scrum Wikipedia page is 43k and waterfall is 18k. > The biggest issue with asking such broad questions that are 'condense this other text that I don't want to read into a few paragraphs' is that, for the most part its lazy. Its asking someone else to try to fit a huge body of knowledge into a text box where there are pages of material out there that covers this. The post here shows no effort at all. It shows no level of comprehension of the nature of the problem. It asks a very broad question to a relatively well known problem. That of the [trusted client](http://en.wikipedia.org/wiki/Trusted_client). The answer you got here is a summary of that wikipedia page (no offense to Justin, it is in his own words and he likely didn't reference the wikipedia page, but it is covering much of the same information). > While I acknowledge it that's my own work, I'd strongly suggest reading the guidance in meta.programmers.SE: https://softwareengineering.meta.stackexchange.com/questions/6559/why-is-research-important/6560#6560 - we don't want to repeat what you already know, nor answer at the wrong level for the reader... and if you really don't know, explain what is confusing you. I again point you to https://softwareengineering.meta.stackexchange.com/questions/6559/why-is-research-important/6560#6560 and urge you to read it and consider the lessons contained within it. Setting aside all of that, Programmers.SE really doesn't like yes/no questions. The appropriate guidance from Meta.SE can be found at: [Question closed because yes/no answer](http://meta.stackexchange.com/questions/183177/question-closed-because-yes-no-answer). The question asked in this format is exactly the too broad nature. There are *far* too many possible answers and good answers are far too long. Go search Google a bit. Show us that you have thought about the problem and what it means rather than tossing whatever you think about into a text box and hitting 'Post Your Question'. Ideally, the person asking the question has spent *at least* as much effort in thinking of the question, the problem, and how to ask a good question as the person answering it. This is how we get good answers.