It only tells the user if content matching the query is available.
This is only a problem if you have a case where very untrusted users
can query against a higher security search index or a search index
with multiple security levels.

It would be very hard to build up a picture of the content of a single
document using this technique. You don’t have an identifier to work
off of. You cannot be sure that you are accessing the same document.

Examples where this would be useful anyway:
You suspect the government of developing mind reading dachshunds.
If you searched for mind-reading-dachshunds and it took longer than
a garbage query, then you had a good case that they exist.

This timing attack would be quite interesting to try out. The search
engine can skew results by actually padding out low result searches by
doing another dummy search for something more common.

To maintain a higher level of security; if you have low security
users, they should not be allowed to query higher security search
index.

However….

If you have mixed security level content and are using a single index
for it, then you are already saying it’s okay for the user to know
that content exists. But a low security level user isn’t allowed to
see the whole thing. Content-for-pay would be a good example of this;
you have links describing pay-content, but you can’t view it unless
you pay.

An interesting version of this would be where each result is actually
an AJAX call to fill in the details. By using the actual content
management system’s ability to check the user’s credentials (AJAX is
client side) you prevent the search engine from having to have extra
logic to manage credentials (and yet thing to audit). You reveal that
a document exists, and even reveal it’s location. Ideal for a
content-for-pay system. You advertise without giving away the
information.

2/ My post is a response to Google’s post claiming that “early binding” is not secure (because of latencies in the ACL indexing). My point is that in general it’s more secure than “late binding”. I gather from your first point that we actually somewhat agree here that “caching the ACL” is often not a big deal.

I disagree with you with regard to the performance of “late binding” (which, again, is not really an ACL check). It can be (and often is) very expensive. In the case of Sharepoint & Email search for example, it often requires doing hundreds of network requests per query (see Mark Bennett’s explanation in the original post).

3/ Re-entering user credential is not a strict requirement if you have implemented SSO across all your collections, but it’s very common for many security infrastructures (for example for people using Windows Integrated Authentication, see this post on the search appliance user group).

1) The answer to performance issues for late binding is ACL caching - and no, it’s different from early binding. With early binding I have no choice as to the validity period of the ACL info - with ACL caching I have ultimate control and can determine on a per-content-set basis how sensitive the ACL’s should be. For HR info I may well require a per-query check, on my published white papers I may be happy with the ACL’s sticking around for days at a time.

2) Highly insecure??? Like anything, I suppose late binding could be implemented in a way that leaks information, but come on - most companies struggle with getting the ACL’s right on their most sensitive content, never mind this. Besides, the ACL check overhead for most systems is very low - I cannot imagine a user (with a stopwatch no less!) gaining any meaningful information this way. There are way too many variables here - this point is just scaremongering.

3) I’m not sure where you get the “need to re-enter user credentials” from. Any reasonable implementation will rely on existing user credentials, be it from the portal or from SSO framework - since you must have a shared authorisation credentials system to make sense of the ACL’s in the first place why would you not use it??

For unknown or poorly documented repositories (likely to be crawled rather than connected to through an API), “late binding” might be the only practical solution but “early binding” should be used without difficulties with all others (often containing the majority of the enterprise content).