Tom, I don't really see where you find that lists of objects be shown without proper permissioning checking.
The redirecting page introduces one new security threat: it may be redirect to a page to which you don't have permission. The URL might be descriptive enough to give you a hint. Think of getting redirected from /o/123456 to /your_division/file-storage/layoffs_q3_2003.doc. A program could just try counting up from 1 to xxx and capture the target URL. That is why - as already stated at least once in this thread - we need exactly the same permissioning code on /o/ as on the target page. If it yields a false, we need to show: this object doesn't exist, otherwise we already tell the user that the object exists.
Otherwise security threats remain the same and if the respective target page is insecure, then the redirecting page is insecure.
Currently, if the source page lists links to which you don't have permissions, then it leaks information. If it does proper permissioning checking, then it'll remain secure with /o7. As I said: the only thing being changed is the target link text.
The "stable URLs" proposal is not about listing objects - it is about supplying stable URLs based on the (hopefully) never-changing object_id. A very very welcome side effect is that it is a very very lightweight replacement for get_urls PL/SQL functions.
