The new Security top-level menu (“page” for short) has a helper function:
function add_security_page( $page_title, $menu_title, $capability, $menu_slug, $function = '' )
In other words, exactly the same as all the other add_xxx_page() helpers.
However, since the security page requires the manage_options capability, is there any point to keeping $capability? Or should we keep it for the sake of similarity but force it to manage_options? Or something else?
Discuss 
Thanks for the consistency.
I’m thinking the $capabilltiy parameter should be preserved in functionality, for cases where a super admim wants to restrict these views from regular admins.
I think it was discussed but, I can’t recall the outcome – is there to be an API for plugins/themes to add sections and/or settings, or is this strictly for internals?
A super user doesn’t control the visibility, the plugin author does, so I’m still not convinced $capability actually does anything in this case.
As for plugins/themes - this is the API to add a page under the main Security menu.
To me, it seems that the top-most-level admin should decide who-gets-to-see-what in terms of security, rather than the plugin author. I’m not convinced that every super admin is going to be fine with having general admins being able to access all the security settings/info (or whatever will be in these pages).
Ah, ok. I was under the impression that there was going to be a security page (singular) – I didn’t realize every plugin could potentially add it’s own page.
What do you envision authors putting in these pages? Information? Settings? Other?
That’s a different problem - this is about solving discovery and auditing (2 sides of the same coin). The idea is for plugins to move their security-related settings to a submenu instead of being buried somewhere under the plugins’ menus.
Security isn’t just for core - if we don’t improve how plugins present security options we’ll leave most of the important problems unsolved.
Any security-related settings - and only security-related settings; for plugins that do something fancy with their pages it might make more sense to have a summary with links to where you change the settings, but the summary needs to be complete.
Plugins get one and only one submenu to play with; they can do whatever makes most sense on the page - tabs, accordions, whatever - but only on that page.
Sorry, I’m missing out something… 
is it a shortcut for add_submenu_page or something more?
Right now, yes, it’s identical to any of the other add_xxx_page() helpers. The question is whether we add some smarts to it or leave it alone.
If we want security to be considered more, the function could also add a link to the registered page in the plugin page, near the “activate” link.
I like when plugin developers link their setting page in that way…
I’m not a fan of forcing this behavior on plugins. A settings (or direct) link is fine if the plugin doesn’t have a top-level menu item, but, anything more than that is just messy and unnecessary. A lot of plugins use this space as a dumping ground for links to settings, docs, upsells, review requests, home-links, bug-report links, and every other thing they can think of. The worst ones add their own logos and custom styles, even though it looks desperate and tacky AF. A security link would just add to the mess.
More importantly – just like all those other links – a security link is not at all needed. After all, the security page will be a top-level item, not an obscure item buried who-knows-where. My feeling is that adding a security link to this space should remain optional (as is the current situation.) so those of us who don’t want it aren’t forced to add supporting code to remove it.
I don’t know… I rather like the idea of the link - I’ve put that together locally and it works nicely.
I’ll think on it a while longer, but right now I’m inclined to go with it. Maybe a poll…
Core allows for plugins to insert themselves into the privacy functionality while not forcing them to display such a link. To me, it’s pretty much the same thing here, and it shouldn’t be forced. I find it to be needless clutter…and to remove it, I’d have to add needless clutter to my plugins. It’s like two wrongs trying to make a right. I’m voting against adding the link. Plugin authors can add this link if they feel it’s necessary and the rest of us shouldn’t be forced to undo it.
But you’re looking at this from the PoV of a plugin author - I’m trying to look at it from the PoV of an end user. I know I’ve found the “Settings” link a lot of plugins add to be a useful shortcut; I imagine end users would feel the same about a “Security” link.
Also, the fact that some plugin authors abuse that area shouldn’t prevent us from adding something useful; if anything, we should curtail that abuse.
As I said, I’ll think on it some more and probably do a poll.
Not true. I’m looking at if from the PoV of an end-user, same as you are. I’m just not interested in adding redundant clutter to an interface (as an end-user), or to my plugin to remove it (as an author).
You don’t find the “Settings” link a lot of plugins add useful at all? I really do - I think it’s a very useful shortcut, and to me a “Security” link would be just as useful. Sure, it’s not something you use every day, but a little redundancy in a system can make it a whole lot easier to use.
In the more monolithic plugins that do not have a top-level menu, yes, the Settings link is helpful. In all other cases, it’s needless. However, it’s already been there for a long time and everyone expects it, so, I deal with it. I’m not saying remove all the existing links, I’m advocating for not cluttering it further.
A little redundancy here, a little redundancy there… is one of the recipes for code-bloat.
Anyway, there’s no sense our going back and forth in disagreement. We’ve made our points. It’s time to get back to work. 
Absolutely - I was just curious about whether you find those links useful; I think we’ll need to agree to disagree on those
I think is just about a personal way of working. I install a plugin and get back to the plugins page. Now is time to setup the plugin, and I like to see a link to the settings right there. If there is no link it takes 2 seconds to find the right menu item. But maybe some people don’t espect to have to configure something about security elsewhere. Security menu is pretty new!
I agree with you @anon71687268 about bloat, but if you don’t want the link you don’t have to remove it and just use register_submenu_item().
My 2 cents:
$capability parameter for this function, it should always be manage_options. A multisite with super-admins who want to limit what “regular” admins can do is a separate, advanced problem that should be solved separately, using e.g. custom capabilities code for the multisite.OK, I’ve decided what to do with the API:
$capability is going as I’ve yet to think of any reasonable scenario where it’s not redundant$menu_slug must match an active plugin slug; you’ll get a “doing it wrong” otherwise, but only if WP_DEBUG is true as there’s a performance hit