I ran across a related issue working on a project that I think helped me understand the broader issue better. I'll relate it here and see if it helps.
We had user search functionality for an internal business application. We allowed searching by several fields, such as name, and phone number, and allowed partial matches, where the first part of a field matched.
Phone numbers were restricted information for some users, and we didn't display them in the search results. But you could search by those fields, if you already knew the value.
It turned out we left 'partial matching' available in the phone number field.
If you knew the name of a particular person, you could do the following:
Enter their name to confirm a single match shows up.
Then enter the same search, but put a single digit in the phone field, say "0". If no result came back, you knew that their phone number didn't start with that digit. So you try the next, 1, 2, 3... when you hit, say 5, you get a result. Now you know their phone number starts with a 5.
So you start on the next digit. 50-, 51-, 52-... and you get the next digit. Eventually you can reveal their entire phone number, and it was fast enough to do manually.
It wasn't super critical for the internal system, so we changed the phone numbers to exact match only and that was fine. but let's continue.
Let's say we had a REALLY slow system, and it checked each digit one at a time, taking one second per digit, and sent back a failure when it hit a non matching digit. We aren't leaking information DIRECTLY, you get no records back for partial matches. But we ARE leaking information indirectly. The attack now works roughly like this:
Do the same verification search to get a record.
Now do the same digit by digit search, start with 0. Carefully time the delay when you submit the question, and when the error shows up. If it's almost instant, you know the first digit failed. If it takes about a second to give you an error, you know the first digit worked.
You then continue to the second digit. One second fails, two seconds verifies.
Using only the timing you can determine each digit, and reveal the entire number. This is not the main information channel, the timings are what they call a side channel. The service that gives you this information by responding with an error and varying the time is an 'oracle' because it answers your questions.
This seems clear at a one-second time scale and obvious when it's explained, but it turns out that even over public networks with enough tries you can determine very small time differences, on the millisecond or less scale.
It turns out there are a lot of variations on this, some of them are very complex, and secure systems need to work very hard to run in the same amount of time ("constant time") for any query to avoid leaking information this way. The timing exploit described above is a very simplified form of the root of the described vulnerability.
This situation helped me understand 'timing attacks' and 'oracles' in a more mundane coding context, and hopefully it will help others.