I have also written a paper detailing many ways that can be used to set trace either for the current session or for another session running in the database. It also shows how to set extended trace either for binds or waits or both.
OK, so what has this got to do with Oracle security? Quite a bit actually. I often highlight to customers the dangers of allowing users access to set trace for their own session or others. Worse still is allowing these users access to trace files or even via autotrace in SQL*Plus. Actually being able to see the trace will reveal a lot of information about the structure of an application and even in some cases critical information about security settings or passwords in some versions or password hash values in others that could be cracked using one of the tools listed on my tools page. So we know the dangers of allowing users to set trace or to access trace data but these tools simply summarise details from the trace files without revealing structure. In some cases this sort of information could be used by a malicious person still to plan a Denial Of Service attack. Some of the tools mentioned above, such as Niall's and the Miracle AS tool allows trace files to be accessed remotely via a web interface. This implies that trace files are one step closer to a remote user or even an in-house user who does not have access to tools such as SQL*Plus.
There have been many posts to newsgroups about simple PL/SQL code that can be used to load trace files into the database so that they can be viewed remotely. This is a great practice for admin staff and for tuning and monitoring but you should consider the security aspects of allowing internals data and structure to be exposed externally.