Forum OpenACS Q&A: Re: Thanks for ETP 2

5: Re: Thanks for ETP 2 (response to 1)
Posted by Ben Koot on
Playing devils advocate...

From an end user perspective this discussion doesn't make much sense. We allow all kind's of html manipulation trhoughout the system, but on essential pages like the personal workspace, effectively "welcome to OACS", an environment that should allow maxium user friendliness, html formatting is regarded a security risk. I fail to see the rationale.

Why can't we have a simple default setting for all text fields thoughout the toolkit, allowing text, fixed width, html. If it's safe for a weblog posting it should be safe for a bio in the public user profile also.

It looks like we overlooked making the personal workpace a pleasant and easy to use environement (most users are not intersted in technological environments), that each user can configure as he/she likes. This looks a serious flaw in userability. Adding additional links to essential parts of site should also be a default option.

A personal workspace should be an area that is created by users of the system, not the way the developers would like people to use the system!. Simple restrictions like formatting the personal profile don't make sence.

If I use ETP I can create whatever I like, so why not give us the same freedom trhoughout the toolkit. It would also reduce postings in the bugtracker. Please correct me if I am wrong.


6: Re: Thanks for ETP 2 (response to 5)
Posted by Jeff Davis on
Ben, you are talking about something entirely different. The issue with the bio being html vs. not is unrelated to this; for the bio it's simply that no one has taken the time to make the bio allow mixed formatting (richtext, html, plain). The technical consideration here is that for every field you want to change to allow mixed formatting like that you need to carry around the "format" field as well.

I think it's important to fix but it's really pretty unrelated to the issue of what html is safe to allow through versus not.

I think good security is not something we should sacrifice for ease of use (at least not by default); look at the reputation phpNuke et al have for security laxness. Much of it springs from a history of these sorts of exploits. Ultimately it's something that, if we want OpenACS to be acceptable for anything other than personal sites, we need to take care not to permit.