[Owasp-leaders] jowasp.org

Jim Manico jim.manico at owasp.org
Fri Sep 5 00:27:19 UTC 2014


The reputation of OWASP is something that is covered in our brand usage 

The security of OWASP.org is not an issue if we use a separate domain 
that is flat-file HTML/CSS/JS only, which is my intention.

The admin resource should be minor since my vision was a flat file 
website that points to owasp.org resources.

The impact on other volunteers is something that I hope will be positive.

You also stated...

 > Focusing on just say the language idea, if there is java. but not 
php., what does that indicate to outsiders?

Eh, that we have better resources in one area but no others? I don't 
understand your concern here. We need to experiment otherwise OWASP will 
go nowhere. As a meritocracy, effort should be encouraged if it's in a 
positive direction supported by our bylaws and mission.

Donald Knuth, someone who I think is he father of modern programming, 
was quoted as saying "We should forget about small efficiencies, say 
about 97% of the time: premature optimization is the root of all evil. 
Yet we should not pass up our opportunities in that critical 3%."

I feel the same about OWASP. Let's not try to optimize this up front. 
Let's get at least a piece of this working, see what sticks, and we can 
optimize later.


> Jim etc
> A great idea. But it can't be a free-for-all, as decisions here impact on:
> 1. other volunteers
> 2. administrative resources
> 3. the security of www.owasp.org
> 4. the reputation of OWASP Foundation
> Names
> ----------
> Firstly, it sounds like these microsites might relate to:
> - language (e.g. Java)
> - framework (e.g. dotnet)
> - project (e.g. proactive)
> - role (e.g. defenders)
> - initiative (e.g. government)
> - chapter (e.g. nyc)
> - region (e.g. asia)
> - topic (e.g. risk/vulnerability)
> Focusing on just say the language idea, if there is java. but not
> php., what does that indicate to outsiders?
> Focusing on  projects. If a project has a microsite, does that
> undermine all the projects that don’t? It appears from other posts to
> this list that many projects are either empty shells or not
> maintained. There needs to be some threshold for volunteers to apply
> for the right to have a subdomain, and their other
> project(s)/contributions must already meet a certain high standard
> (quality, freshness, support).
> Focusing on a risk/vulnerability, why should xss.owasp.org exist but
> not csrf.owasp.org for example, or should the latter be
> xsrf.owasp.org? Who decides what will be okay?
> Is there a danger that only "rich" leaders/chapters will be able to
> create these microsites, if “pro design” and “SSL certificate” have to
> be acquired?
> There will be a lot more new OWASP support overhead for these
> microsites such as approving them ,setting up the DNS records,
> managing access, maintaining assets, and periodic review.
> A final question on subdomains, how does the wiki deal with other
> languages? I believe Spanish exists. Are there any subdomains already
> allocated?
> Not a free-for-all
> -----------------------
> So, some initial discussion ideas for ground rules:
> a) All sub-domain DNS will be managed by OWASP (of course)
> b) No new domain names must be registered (to prevent sprawl, lack of
> control and brand damage)
> c) All sites must be hosted within OWASP’s infrastructure (so OWASP
> has all the assets, and backups)
> d) All root/admin access credentials must be held and controlled by
> OWASP, not any project leader or other person (so that OWASP can
> transfer ownership to another lerader, or take thje site down if not
> maintained, or is contrary to any principle)
> e) Must conform to OWASP’s domain-level policies (e.g. RIA, HSTS?).
> What content/includes will be allowed or not. Some might well
> undermine the security of the main website.
> f ) Must be SSL-only
> g) No sponsorship/advertising at all (because that is occurring on a
> tab of the project page).
> h) Must not contravene OWASP’s principles and ethics, or any governance rules
> i) Must not have any? vulnerabilities!
> j) Must use 2FA for administrative access for all non-public access
> k) Must support multilingual capabilities
> l) Microsites will be culled if not updated within any rolling period
> of (say) 180days.
> m) Content must be relevant, accurate, timely and be well written
> n) Vendor neutral
> o) (your suggestions)
> Colin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140904/b51b5f02/attachment.html>

More information about the OWASP-Leaders mailing list