Improve clarity of the reporting security issues warning

Approved for me, I vote for "warning" but not red message.

I think a yellow warning would be an improvement, or even a blue "informational" message (if the current text that's in the blue informational message were moved to something else).

For the wording, maybe one problem is that it's not enough of a call to action, and another is that it's not 100% clear what to do if you think something might be a security issue but aren't sure...

Perhaps something like this?:

Reporting a potential security problem? Do not create an issue here. If there's a chance that your issue is security-related, follow the procedure for reporting security issues instead.

No, it should not be red. Red means that an error has occurred. While I do agree that this is a very important message, and we want everyone to know about it, we shouldn't be using error messages for education. Maybe it will work in the short term, but in the long term it will devaluate error messages to something we have learned to ignore.

I think #2358243: Create automated monitoring for new issues in the public queue is a better approach, ideally checking for keywords like "security" and "sql injection" during form validation.

Another solution but very intrusive... This overlay disappear on click button.

Let's get Bojhan and team's thoughts on this.

In my experience, putting things in bold or red doesn't actually make people more likely to see them. Especially when the 99% case is that it's not a security issue and by the time someone gets to the 1% case we've trained them to be blind to the warnings. If we put something more intrusive into the form it should be context appropriate and disable-able for advanced users.

If there is a good way to detect a security issue, such as a security component or tags used, we could potentially do a warning in JS when relevant. I'm not sure how possible it is to do the detection really well.

@greggles is completely right here. Putting this in red will not change the perception of users, nor will it be more likely that people file them correctly. We should instead do something considerably smarter by detecting certain words and then trigger a "are you sure, because security" step.

I dont even think any of the messages here are usefull, I wonder how much visits they get (and bounce rate/time on page) I assume its very very low

Maybe we should have a “Security” category or component (not sure which one), so it makes sure the user will pay attention since those fields are required anyway.

Of course, once s/he selects this option, we can act on it, e.g. displaying the message in a very intrusive way. Maybe even disabling the submit button altogether. Or, if we really want to be smart, sending the issue to the security team to review before making it public.

I like the idea of putting it somewhere like that, but look at core...that's too big.

How about Category? "Security bug"

IMHO I think there should be a "Priority" of "Security" that when selected displays a popup box stating to report security issues to the proper issue queue. That way if a normal item ever gets changed to a security related issue, the person is reminded to use the right queue. There could also be other functionality that goes along with it maybe (like hiding the queue item, not so sure about that though), but at the very least a message dialog needs to be shown for those that dont actually read everything on the screen (self included). Ideally there would be no separation of issue queues though, but in another thread it was mentioned that there are performance concerns. Personally, I dont believe Performance is > Security, but thats just my opinion.

We know from repeated usability tests with eye tracking that users generally ignore text above a form, and will especially do this after the first use, so IMO the current warning may as well not exist. :\ And it's not really fair to throw this back on people when they don't remember a tiny bit of inconspicuous text that may or may not have even been there (depending on how long they've been a d.o user) the first time they read the issue form.

We also know, both from UX studies in general, and also just from logic and reason :) that adding more than 7 or so things in a list is completely overwhelming and people will just pick the first thing they see that sounds kind of right, or else give up. This is why two of our biggest core components issue count-wise are "base system" (welp, I tried) and "ajax system" (whatever, I'll just pick the first one). ;) We should fix that for core separately, but definitely adding another option to the list will once again become "might as well not exist."

I think we should instead go the opposite direction and make the option to report a security issue extremely visible and clear. Like a checkbox on the node form (possibly for both issues and forums, given how humans work) that's "This is a security issue." What that would do behind the scenes is:

1) Unpublish the issue node.
2) Copy/paste the text of the issue to a new issue on security.drupal.org with the same metadata (which presumably fires off e-mails to the sec. team members)
3) Display a dsm() like "Thanks for reporting a security issue. You can follow along progress at https://security.drupal.org/node/12345." (which they should be able to see since they are the author).

Possible downsides to doing this:

1) The volume of security reports will most likely increase. OTOH, I think that might be a *good* thing. It gives the security team a much better idea of which issues are actively hitting people in the wide vs. theoretical vulnerabilities, and it also gives a known issue a polite *ahem* if it needs it.
2) Um. I'm really blanking here. Surely there are other downsides, but I can't think of one that isn't really not a downside. ;P Or at least not downsides that are worse than another SA-CORE-2014-05.

Thoughts?

Also in #2146839: Database ExpandArguments placeholder naming issues when using array there's a sub-discussion happening about the security team following a security issue tag. However, I don't think this holds water. If you start typing "sec" in the tags box you'll see there's all manner of tags: #security, Security, "needs security review", "Security improvements", etc. I'm sure there's "scurity" and securty" and such too. :P

This is why I prefer the more obvious "make it an actual field on the form" approach.

LOL didn't mean to do that. :)

Similar suggestions to webchick have come up in other queues, but it seems they are always shot down due to "performance issues". Maybe we just need a champion like Webchicks to carry the UI Security flag :) Anything is better than the current which is pretty much nothing at all lol. Whatever is used, I agree it should be on a list of less than 7 items if it's in a dropdown menu. Thus either Category or Priority are good candidates. The checkbox takes up more screen realestate and may get overlooked if it's designed to take up less realestate. I think using current dropdowns that are used on every single use of the queue system may be the right direction since it forces the user to look at it every single time whether its a new person to the queue or not. It should be on the most used Dropdown item which is probably either status, priority, or category. From there, what the selection actually does should be up for debate.

Just to clarify, "performance issues" concerns stem from the idea of including both public and private issues on the Drupal.org tracker. In order to do this, we'd need to deploy some kind of node access module and doing that on a site with 2m+ pieces of content is non-trivial. So the private tracker on security.drupal.org is probably always going to exist.

My proposal is simply to acknowledge that fact, and add automation to ensure that both the reporter and the security team get notified when a security issue is filed on D.o by people who don't know security.drupal.org exists.

Oh, but definitely agreed that this checkbox (or drop down or whatever it is) needs to be in the same place in the issue form as the other settings. The entire point is to force people to read that choice and make a decision about it.

@webchick I agree, but what you are arguing for is basically a redesign of this form. Because adding a subliminal checkbox. Won't make a difference. There are many ways to do this, I guess our stop-gap solutions just don't have the influence we want.

I wonder if it should be a new "category".

Yes, we've had several suggestions to put it in the Category field. I don't see any drawbacks to that as a short-term solution.

I would be very open to the idea of testing out the use of the issue queue on d.o as the means to auto-file issues into s.d.o, but that requires a bit of effort and I'm not sure who would do it.

Sure, category works! Then people would see it all the time and mentally record that it's there.

Does security.druapl.org have the RESTWS module like Drupal.org does, by chance? If so, we could do this with POST requests. OTOH, I could see s.d.o not wanting to install additional modules. ;)

security.drupal.org doesn't have that, but it seems like it could. It's true we try to keep the set of contribs low, but that's one that I think passes the sniff test ;)

Does it need to go as far as filing the issue? How about, when the security component is selected, disable the submit button, show some sort of alert about what to do next for filing an s.d.o issue.

@drumm Or perhaps a message when they selected the security category that explains them what putting in a security issue means - and if they categorised it correctly, that allows them to click a checkbox [ ] This is a security issue, submit it to the security team [disable the button until they click this?] We can offer a disconnected flow, but that seems rather silly.

@#30, this is the same idea that I presented in #17 and in other threads. Seems to me like that is the best option that will cause the least amount of performance considerations or integration (REST etc). I would imagine thats how the feature should look to begin with and then at a later date the functionality can always be modified to actually post items to the security queue if thats something the team wants to do.

bah, double post :/

I don't think we want rest running on s.d.o to submit issues. I like #30. If someone selects a security issue, put a warning message up with the correct the url to the project, and don't allow submission.

#939714: New issue “Security issues …” message should be a warning changed this message to be a warning almost a year ago.

I think the remaining work here is summarized starting in #30. Putting that in the issue summary.