Latest revision as of 20:00, 15 June 2011

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
  • owasp.org/index.php** redirects to -> wiki.owasp.org
  • wiki continues to be available as incubator for more mature content
• Main OWASP page
  • www.owasp.org is a CMS controlled page with editor approved content
  • not necessarily a Wiki
  • (professionally) designed to be geared towards public consumption
• Projects Home
  • projects.owasp.org -> 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
  • forums.owasp.org -> message boards
  • supersedes mailing lists
  • must be backwards compatible and transparent with current mailing list infrastructure
• Conferences Page
  • conf.owasp.org -> 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.owasp.org?
  • 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!)

User:Clerkendweller

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)

• owasp.org
  • https://owasp.org/ fully controlled by OWASP
  • https://owasp.org/ 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 owasp.org, 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 owasp.org 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 https://owasp.org/
  • 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)).owasp.org
  • blog.owasp.org
  • forum.owasp.org

User:Elke Roth-Mandutz User's Privacy should be taken into account on the OWASP websites

• Cookies
  • Restriction for any OWASP page to first party 'session" cookies
  • Don't accept third party cookies, any flash cookies or web bugs
  • OWASP cookies should expire with session, long lasting cookies should not be used, if not absoltely required

• Third party content
  • Double-check whose content is put on OWASP sites, and what those third party content puts on on the page
  • Double-check on third party conent privacy policy e.g. completeness, data storage,...

• Privacy Policy
  • Check on OWASP privacy policy completeness
  • Is any data retreived? What kind of data? How long is the data stored?
  • Add information about any client side storage (e.g. cookies)
  • Make it P3P (see W3C) compliant

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?

• Example: http://sourceforge.net/adobe/