Can't post question on freelance. Says 'this looks like spam.'

Question

The title pretty much tells you my problem, there is no other error message. It is a lengthy question, that's the only thing I can think of.

*I just posted the original since it doesn't seem to matter. This is the title:

How do freelance web developers approach web security and liability?

The question is:

Sooo many questions, where to begin? With governments and huge corporations spending god knows what on cyber security just to get hacked I think it's safe to say that there is no such thing as a 100% secure system. So that begs the question as to what level of proficiency is adequate before you can release your product into the wild? A question that is made even more difficult to answer due to the fact that there is no industry-wide standard. You have PCI-DSS when dealing with credit cards, regulations you have to follow when building for the health sector, and OWASP would be great if they weren't waiting to replace their developer guide from 2005. As it stands there just isn't anything that neatly covers the current scope of web development.

I'm sure you get actors across the spectrum who deal with this in different ways. I'm sure some throw caution to the wind and release every bug-filled app the minute it's done while others, like me, disect every potential liability before even attempting to step into the industry. Really someone even as neurotic as myself wouldn't have given this a second thought had I not read that people would expect me to be liable in the event of a breach. I mean all I want to do is make a website for my client's collection of cat memes (I said my client's, not mine.... okay maybe mine) and now you're telling me I have to buy something called cyber insurance because I might get sued?

I read somewhere something like 70% of websites have serious vulnerabilities, which to me makes sense. Realistically how can you expect every two-bit blogger to have the same level of security as a multi-million dollar corporation? That sort of thing has to come at a premium. The crazy thing is actually hearing people call for the heads of small or even single-man developer teams. Expecting perfect security when even the big boys are getting whacked, I mean hacked. I'm assuming the road to becoming a security guru is a long one and it seems unreasonable to expect web developers to be there before they're allowed to provide services.

The End

..........

......

.

Okay here's my question. Like I said I'm sure people approach this in many different ways and what I want to get is a sense of common industry practices and hopefully some advice to go along with it. I'm sure a lot of this will come down to the wording in the contract so here we go: Will something like "We are not a security company and cannot be held liable for any losses incurred in the event of a breach. We do our best to yada yada," have any impact? What if this isn't a one-man operation and you're outsourcing the front-end, or vice-versa. Does 'who's responsible' rely on the contract also or is it more important where the breach occured (front or back)? What if you're outsourcing the actual security (not sure how you would do that, maybe testing)? Who's liable? Is insurance a serious consideration in the event of a lawsuit?

I need to know what happens if you have an agreement to maintain the site after it's launched - this is actually the topic that got me interested in the first place. When I first searched the issue of liability on stack the consensus was if you were contracted to maintain the site after the build then yes you would be held liable. Now at first glance that might seem logical but I think you have to look at where breach occured. It seems reasonable to expect software updates and security patches to be included under maintenance and if an attack was possible because you failed to do so in a timely matter than yes you should be held liable. A breach under any other circumstance I would say no because again as a lone developer or small team you can't be expected to code for every possible exploit, I mean just think about all the Wordpress developers and the fact that they might be subject to a lawsuit. How can you expect developers to contain, remove, and repair after an attack correctly when they're not even equipped to do so? These aren't web security experts and they're going to be navigating uncharted waters. Given the nature of the situation they also won't have the time to learn on the go.

What I'm looking for is ways to mitigate all of these potentials both in the contract and outside (because apparently even legal wording may fail to protect you). How do some of you write security before and after a breach into your agreement, including disclaimers and how to handle the issue? If using third-party security what's the legalese in regards to responsibility for payment? Do things like scope of maintenance and complexities brought on by subcontracting the project require consideration? As you can see this is a wide-ranging topic (probably beyond what I've included) and I'd like to get as complete of opinions as possible. These of course will not be taken as legal advice so feel free to chip in and bring anyone who might have valuable insight or authority.

The End

Answer 1

There is a spam-detection system that blocks posts which have a very high similarity to posts previously detected as spam.

It's pretty conservative. But we made it a bit less so recently, due to a flood of spam from scammy tech-support companies. In spite of this, the false-positive rate on detection has been extremely low - but your post managed to use enough keywords to get bit.

I've tweaked the settings a bit - that said, I would join the others here in encouraging you to edit your post before submitting it. In addition to avoiding filters intended to catch verbose spammers, getting to the point in your question will also avoid the ire of those you may wish to see answering it.

Answer 2

Sooo many questions, where to begin?

Oh dear. You need to ask only one at a time.

With governments and huge corporations spending god knows what on cyber security just to get hacked I think it's safe to say that there is no such thing as a 100% secure system. So that begs the question as to what level of proficiency is adequate before you can release your product into the wild? A question that is made even more difficult to answer due to the fact that there is no industry-wide standard. You have PCI-DSS when dealing with credit cards, regulations you have to follow when building for the health sector, and OWASP would be great if they weren't waiting to replace their developer guide from 2005. As it stands there just isn't anything that neatly covers the current scope of web development.

This is just stuff to read through that anyone likely to be able to answer the question already knows. Those folks are already starting to wonder where the question is and whether to bother reading on. I'm going to skip some of it now.

... now you're telling me I have to buy something called cyber insurance because I might get sued?

Thought that might be the question finally, but it seems rhetorical. Experienced answerers are close to giving up now. There are many shorter easier questions to answer.

Finally a few paragraphs on there's something about how to word a contract. That's a legal question that only lawyer can answer. So you can't post that on freelance. You could try the legal beta site but only if you massively edit the question into this single point and write out the exact phrases in the contract you intend to put in so they can comment on them. They won't work with

yada yada

After that you seem to continue with additional stuff to wade through and then another question

How can you expect developers to contain, remove, and repair after an attack correctly when they're not even equipped to do so?

That's not a legal question so it can't go on the aforementioned legal site. It is way too broad as a single question. What kind of attack? What was the effect? What infrastructure do you have? I.e. is it yours or hosted? etc, etc, etc. You need to provide exact details and ask a much more specific question.

And then we're back on the long long question road again.

As you can see this is a wide-ranging topic (probably beyond what I've included) and I'd like to get as complete of opinions as possible.

Oh dear, now we're off topic as no Stack Exchange site allows questions about opinions. They all want something where an expert can supply an answer based on the facts presented in the question.

And you've cut it down already? From what? Your unpublished series of novels?

Oh and by the way the statement above seems to be missing a word or two, as written it doesn't actually make sense.

So if you've got this far, stop the stream of consiousness rambling and ask a simple direct question, otherwise even if you do get past the spam filters, you won't get an answer and you'll just waste everyone else's time reading as much of it as they can be bothered with before closing it.

Answer 3

Same thing happened to me today. There was nothing in my post that looked [to me] like spam and in the end it didn't appear that it was but I couldn't get past the red label telling me post couldn't be accepted.

I was also unable to find out any information about what spam looks like so I could adjust the post. Maybe I was looking in the wrong area - am new to this site so thats quite possible, but with pretty much everything else on this well organised site when there is a question or cause for finding out further information there is generally a well positioned link to adequate information allowing resolution of the problem.

Would be helpful if there was an easily recognisable link to a page that helps resolve the problem in the red box that points to the post saying 'this looks like spam'.

What I ended up doing was post in several increments, my logic was that I would then be able to identify the paragraph of the post that was causing problems for the system. None did, the post was eventually accepted without any adjustment in content.