This information is hypothetically semi-sensitive, but I can't really conjure up any scenario where it reveals anything especially useful or meaningful, especially with default options.

The best attack I can come up with is that this essentially allows you to execute an enhanced timing attack: when viewing a list of query results, you can estimate how many results are filtered out by how long the page takes to generate. By executing a bunch of queries, you could potentially learn information about objects you can't see.

For example, suppose you want to know about T123, but don't have permission to see it. You can execute a bunch of queries with "id=123" and other qualifiers (assigned to X, has project Y). The queries which don't match will get 0 results back (filtering the row in MySQL), while the queries which match will get 1 result back and then filter it out in the application. The latter does more work, so it will always be slightly slower: you'll see the same page, but one page will take, say, an average of 350ms, and the other will take an average of 351ms. By executing thousands of queries, you could guess whether a task you could not see was assigned to a specific user or not.

With access to the profiler, you could get this information directly by seeing how many calls we made to policy filtering code.

Making the profiler results public doesn't really impact this one way or the other, though.