[Owasp-leaders] Proposal for changing OWASP Documentation

Kevin W. Wall kevin.w.wall at gmail.com
Sun Feb 21 06:07:28 UTC 2016


Sorry for jumping in way late here. But now that I've finally got a
chance to read over the proposal at
<https://www.owasp.org/index.php/Category:OWASP_Github_Documentation>
I have some comments / questions regarding the proposal:

* Is the intent here for these new GitHub markdown pages to
    eventually _replace_ the OWASP wiki pages?
    If so, how do we intend to:
       -- Not break all the 3rd party inbound links to existing wiki pages.
          I'm not even sure that's possible unless the plan is to do some sort
          of auto-redirect.
       -- Be able to present a decent look & feel for PC browsers vs.
mobile browsers.
       -- Replace the tabbed pages with what? AFAIK, GitHub markdown doesn't
          support that, at least out-of-the-box. If we had to
"flatten" the presentation
          to account for all the tabs, I think that would look awful
in most cases.
    If NO, then what exactly is the intent? To just provide more accountability
    in terms of who can edit what pages, etc.?

* Wikipedia also uses wikimedia markdown and they supposedly have over 5M
   articles just for the English version and have over 10 edits per second. (See
   <https://en.wikipedia.org/wiki/Wikipedia:Statistics> for details.)
Sure, they have
   disputed content, etc., but they have a process for dealing with it
and part of
   that involves an editorial staff. Is there some reason that their
process would
   not work for us on a drastically smaller scale? On the surface at
least, it seems
   that such an approach might be more viable than a "burn it all to the ground"
   approach.

* I'm not quite getting how dumping (say) all the SQLi stuff together
is necessarily
  going to stop the duplication. In theory, we could do similarly with
Category tags,
  but if people are not diligent to first stop and check if something
is a duplicate,
  I think a hierarchical organization will only help slightly. That's
because for
  things like this, there are always multiple ways that we many want
to view things.
  For example, presumably we would want all the cheat sheets organized together,
  all the vulnerabilities organized together, all the defensive
frameworks organized
  together. But all of those would likely have cross-cutting SQLi concerns that
  need to be mentioned. So do we duplicate (say) the SQLi Cheat Sheet
in multiple
  places? If not, then where would its home be, with the cheat sheets
or with the SQLi
  stuff?

Anyhow, just so things to think about. You probably already have, but maybe just
didn't spell them on on the GitHub Documentation wiki page.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.


More information about the OWASP-Leaders mailing list