This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Talk:Summit 2011 Working Sessions/Session023

Revision as of 15:07, 8 February 2011 by Jason Li (talk | contribs)

Jump to: navigation, search

Use this page to capture discussion about the OWASP website leading up to the working session.

My goal is to have a proposal documenting stages of change for OWASP website put together before Summit so we can present and go over it as a group for discussion - User:Jason Li

Subdomain Proposal

Propose subdomain migration:

  • Move away from Wiki
    •** redirects to ->
    • wiki continues to be available as incubator for more mature content
  • Main OWASP page
    • is a CMS controlled page with editor approved content
    • not necessarily a Wiki
    • (professionally) designed to be geared towards public consumption
  • Projects Home
    • -> new home for all OWASP projects
    • ideally leverages Google Project Hosting combined with Google Code Review
    • provides centralized repository for downloading all projects
    • provides consistent look and feel to all projects
  • Forums
    • -> message boards
    • supersedes mailing lists
    • must be backwards compatible and transparent with current mailing list infrastructure
  • Conferences Page
    • -> home for central conferences
    • need the ability to add subdomains or at least root dirs for conferences to allow for easier linking <- User: mark.bristow
  • Community Page
    • community home page to encourage ecosystem
    • can hold chapter home pages
    • base for OPoints?

User:Jason Li

Perhaps we also need to discuss (and not discuss):

  • Search
    • Main site(s)
    • Content elsewhere?
  • Implementation
    • Hosting
    • Security aspects
  • (avoid talking about the logo!)


On Designs, Layout and Standards

User:Clerkendweller To document some of my own thoughts, suggestions, and existing aspects of the current site we don't want to lose track of. These are based on re-reading the 2008 documents, trawling through the leaders' email list for this topic and my own views. All done in pencil, so they can be altered easily.

What URL? SSL? Maintain existing URLs (even if 301 redirects)


New page header for the whole / all site(s)?


Hang a pure CSS menu off the tabs, so that we can highlight many more pages/resources from every page, but without cluttering up the header. The "Resources for..." is aimed at new visitors, and is probably all new content pages (a lot of work to put these together)... the number suggested is too many, but I didn't want to lose any ideas:


Introduce breadcrumb trails:


My thoughts were to keep as much as possible in the wiki, and just significantly re-skin the existing/new "introductory" pages. The number of pages styled in the new way can grow as effort permits:


The home page and other "introductory" pages will be fully multilingual and have no evidence of being wiki pages (even if they are):


and all the other wiki pages get the new header/footer, with most of the wiki management tools moved to a right column, along with cross-links:


Standard footer across the whole site:


We try to make sure the status bar doesn't display any warnings to "normal" or "appsec" users:


We might want to specify some standards/options to include with changes:


And keep a centred design which expands, but doesn't stretch too wide:


Some of the above might ultimately contribute to a specification.

Emphasise "S" of OWASP

User:Achim (following items without any preference, order, ... simply unsorted)

    • fully controlled by OWASP
    • with trustworthy certificates
    • all content needs to be visible without enabling client-side scripting
      this is not only a security but also a requirement for handicapped accessibility
    • selfcontained, means that 3'rd party includes (i.e. YUI) must be local
    • verified usage of 3'rd party sources (i.e. YUI)
    • think about (discuss): "what is a trustworthy root CA"
    • OWASP is de facto the reference for web application security. Why not setup as root CA? Note that some major browser vendors are next door at the summit ...
  • general
    • all processes with private and/or confidential data like registration, billing, etc. need to be done via
    • keep people's privacy; i.e. who controls (personal) data at google, and many more
      (see Jason's mail about ".. need to have gmail account to participate")
  • Subdomains (see #Subdomain Proposal above also)
    • ((chapter))

Content orgnaization

  • would like to re-iterate the proposal for forums over mailing lists
  • Subdomains (see #Subdomain Proposal above also)
    • Need a robust and managable way to add subdomains/root dirs so we can leverage this for conferences

User: mark.bristow

OWASP Website becomes Portal?