(F) SIMULTANEOUS QUERY OF FBI DATABASES.—Except as otherwise provided by law or applicable minimization procedures, the Director of the Federal Bureau of Investigation shall ensure that all available investigative or intelligence databases of the Federal Bureau of Investigation are simultaneously queried when the Bureau properly uses an information system of the Bureau to determine whether information exists in such a database.

(E) SIMULTANEOUS ACCESS OF FBI DATABASES.—The Director of the Federal Bureau of Investigation shall ensure that all available investigative or intelligence databases of the Federal Bureau of Investigation are simultaneously accessed when the Bureau properly uses an information system of the Bureau to determine whether information exists in such a database. Regardless of any positive result that may be returned pursuant to such access, the requirements of this subsection shall apply.

In his commentary on the new language, Charlie Savage suggested the first change pertained to rules in the EO 12333 sharing language prohibiting the search for criminal purposes. I’m as interested by the second change: the language that originally said even if you got a positive hit from one source, you still had to make sure you pulled up the same positive hit via all databases. Requiring that FBI pull up all incidences of a piece of intelligence anytime they do a search would have several functions: ensure they found data that would be easier to parallel construct, because it was collected under Title III or didn’t have notice provisions, make sure an Agent understand the context from which the intelligence was collected, and ensure any associated analysis got seen along with the intelligence.

In my opinion this suggests there is at least once incidence when the FBI did a search and missed something.

My original thought was that the use of ad hoc databases removed certain information from the general search pool such that an important dot was missed. Ad hoc databases were formalized in 2013 to permit FBI to store raw 702 data in separate repositories; one reason among other redacted reasons to do so was to more easily manipulate the data, but the repositories might be as small as a single laptop.

The formalization of a requirement that all queries include all databases in the HJC would seem to require that ad hoc databases (at least those with unique data streams) be included in those searches. And that, it seems, would be formalized because some queries missed data.

But it also might be that an FBI Agent did a search and missed critical context that would have been obvious if he had gotten that hit in a different database.

Someone missed a dot.

Someone missed a dot sufficiently important to codify rules to avoid missing dots into law.

That dot could be on any subject pertaining to 702: terrorism, counterproliferation, hacking, or counterintelligence. That said, we certainly don’t have any counterterrorism dots — in the form of a foreign sponsored attack — that appear to be missed.

Now let’s look at another dot. Among the many Russia-related items the SSCI-passed intelligence authorization mandates for next year is an intelligence posture review — separate from the SSCI investigation going on right now — to examine (in part) whether the IC was collecting the right intelligence to identify and respond to the Russian tampering.

(b) Elements.—The review required by subsection (a) shall include, with respect to the posture and efforts described in paragraph (1) of such subsection, the following:

(1) An assessment of whether the resources of the intelligence community were properly aligned to detect and respond to the efforts described in subsection (a)(1).

(2) An assessment of the information sharing that occurred within elements of the intelligence community.

(3) An assessment of the information sharing that occurred between elements of the intelligence community.

Admittedly, this is what the IC does in the wake of every intelligence failure: figure out why they failed. But I’m interested in the focus on whether information was shared within and between intelligence agencies sufficiently.

That’s because the public reports of the Task Force investigating the operation in real time describe it as very compartmented — the kind of compartment that might require the use of an ad hoc database.

Brennan convened a secret task force at CIA headquarters composed of several dozen analysts and officers from the CIA, the NSA and the FBI.

The unit functioned as a sealed compartment, its work hidden from the rest of the intelligence community. Those brought in signed new non-disclosure agreements to be granted access to intelligence from all three participating agencies.

They worked exclusively for two groups of “customers,” officials said. The first was Obama and fewer than 14 senior officials in government. The second was a team of operations specialists at the CIA, NSA and FBI who took direction from the task force on where to aim their subsequent efforts to collect more intelligence on Russia.

Dot three.

None of this is definitive in any way.

But I raise it all because there is a dot that — dot four is stunning in retrospect — was missed: the June 9, 2016 meeting at Trump Tower. Rayne even noted it at the time it was reported. While I’m less sure than she is that Rinat Akhmetshin — a naturalized American — would be targeted under FISA, it seems likely that Natalia Veselnitskaya would be, or those in the background of those meetings.

A former Trump lawyer working for Aras Agalarov, Scott Balber, went to Moscow to obtain this partial email thread. It’s not a PRISM provider, but Veselnitskaya is a likely target whose emails could be obtained via upstream surveillance. And she was still in Russia — discussing the meeting with another likely target, Agalarov — days before the June 9 meeting.

Veselnitskaya has said she was interested in the Magnitsky Act issue on behalf of a private client. She was working closely in the United States with Akhmetshin, a Russian American lobbyist who has been accused of having ties to Russian intelligence. He has denied ties to the Russian government.

Veselnitskaya told Balber that she met with a series of well-connected Russians in early June 2016 to discuss her upcoming trip to the United States. One person with whom she met was Agalarov, for whom she had previously done legal work.

Veselnitskaya told Balber she did not seek a meeting with the Trump campaign but was “surprised and pleased” when Agalarov explained his business connection to the presidential candidate and offered to make a connection. Veselnitskaya told Agalarov that she had in October 2015 provided information intended to undermine the U.S. law to Yuri Chaika, the Russian prosecutor general, Balber said. Balber said he believes it is possible Veselnitskaya’s statement resulted in a misunderstanding about the prosecutor’s role.

Side note: this entire press blitz based on former Trump lawyer Balber’s months old meeting with Veselnitskaya reeks of an attempt to compare notes in advance of someone’s testimony. CNN reported today that several of the Russians involved in the meeting had been interviewed by SSCI, and Richard Burr all but confirmed Veselnitskaya had been included among those at a press conference earlier this month.

Mind you, it’s not clear either of these likely targets would be in FBI’s databases in real time, in part because they’re less likely 702 targets. But they’d likely be in NSA databases. Which means as things heated up, particularly around meeting attendee Paul Manafort — who, as an individualized FISA target, could automatically be backdoor searched at NSA, against far more extensive NSA collection — this might have come up (though it’s not clear Manafort got mentioned until and except for the Rob Goldstone-Don Jr email thread).

All of which is to say when this meeting came out in July, Robert Mueller reportedly had just learned of it. That’s true, in spite of the fact that one reported FISA target (Manafort) and at least one likely NSA target (Veselnitskaya) attended the meeting.

As we learn more and more about that meeting, it seems more remarkable that it got missed for over a year after it happened (and only disclosed in response to subpoenas, not back door searches).

If we’re going to codify back door searches, even of Americans, can we first learn how it was this meeting never came up in a back door search?

I noticed the change from “access” to “query” as well. My thoughts were:

The original wording can be taken to mean that all available databases (including investigative records) must be accessed, even after a positive hit is found. This is prudent.

The new wording sounds (to me) like the exact same query (identical set of terms and term relationships) are to be used against all available databases, which, while not a bad idea in itself, implies (even, requires) that all of the databases accept identical terms and term relationships. Which could mean that all of the databases in question are similarly constructed, at least for querying purpose; otherwise a query built for a specific schema might not work on a different one.

Query conformity sounds like a good thing from the perspective of the querying agency, but makes database maintenance and modification/extension more complex, and that in turn increases risks of error/failure, for one database or even across entire system. And for complex/multiple databases, higher integration can create more complex constraints for effective queries, even simple ones. It’s the kind of thing contractors don’t particularly emphasize when pitching a job; simpler in one way doesn’t mean simpler (or safer) in every way.

This could also explain why investigative databases are no longer included: investigative databases may be developed ad hoc within the scope of a specific investigations needs, they may not conform to this more restrictive constraint. For example, a field “felonies” might contain a number value of felonies in one table, and a true/false (Y/N or 1/0) value in another table, so and expression like (felonies>2) could fail (absolutely, or by returning inappropriate result) on the second table.

But excluding investigative databases, that were previously required to be included, could come with a price of lost opportunities, and overlooked/uncorrelated information.

In a Database, there is stuff. But it is organized stuff. Think of your ‘contacts’ on your smart phone.

You have a PRIMARY KEY (Contact Name).
And you have other stuff associated to that PRIMARY KEY, like the contact phone number, email address, etc.

The PRIMARY KEY defines a ROW. A ROW in a database is a set of COLUMNS tied to PRIMARY KEY.

The COLUMNS (AKA as fields pre database terminology, ex: comma seperated values), are part of the SCHEMA.

A TABLE is a defined set of COLUMNS with a given TABLENAME.

So your Contacts TABLE would have many COLUMNS, ex: Contact name, phone, etc.

Some COLUMNS can be NULL which means you do not have to have data in them.

The PRIMARY KEY can never be NULL.

The PRIMARY KEY in your CONTACTS TABLE would be CONTACTNAME.

Think of TABLE as a file, and COLUMN as a field. But very structured and organized with rules.

The layouts of the TABLEs and all of the rules can be collectively called the SCHEMA.

The SCHEMA is defined by the data architect or DBA (DataBase Administrator).

The SCHEMA is a Map of the Database. The SCHEMA defines the TABLES, VIEWS, STORED PROCEDURES, etc in the Database.
And more, but skipping to try to keep to the point.

Part of the SCHEMA is access rights and privileges.

For example, a given USER may be able to read data but not modify.

One of the objects in a SCHEMA can be a VIEW.

The VIEW is database object that the USER can query/access. Typically, READONLY.

A VIEW (simplying greatly here), is a way to view (query/access) a bunch of data in the database.

Potentially using some ‘SELECTORS’ !!!

Now, the VIEW is actually defined via SQL, and is normally defined by the data architect or DBA.

One of the primary purposes of a VIEW is to hide the actual TABLES! (Too tech, don’t ask)

But another function of a VIEW is to filter!

So the DA/DBA can set up the database so that a given user can NOT VIEW everything in the database!

Which now gets back to the access/query wording issue.

I would interpret access to mean the USER can read all of the data. Can read any TABLE.

And I would interpret query to mean the USER would have to read a filtered set of data via a VIEW.

But, and this is important, besides being able to read the data (SQL SELECT), access also implies that the USER has write privilege (SQL UPDATE, SQL DELETE, SQL INSERT), whereas query implies READONLY access.

So, an entirely different angle of the wording change, is that maybe IC folk where/are deleting/changing intel data.

I actually think the access w/o notwithstanding could be achieved by access tied to authorization, as NSA’s databases are all supposed to be and FBI’s 702 database is. That is, I think it said enough to address Savage’s concern: that the rules on 12333 use for crimes is more restrictive.

Then query w/notwithstanding would exclude both ad hoc databases and 12333 day. But if the point of this is to connect dots, then it might be counterproductive.

And by that I mean, who was the one who leaked Jr’s emails to the press and let the world know this happened. If it was the Russians, that’s a very big deal. If it was a Trump employee, then Mueller and co. probably know more than we do about the whole thing than anyone knows.

Kushner initially omitted the interaction with Veselnitskaya on his application for a security clearance, but included the meeting on a supplemental form.

The emails with Donald Trump Jr. about the Russian meeting were discovered as Kushner and his legal team prepared for his testimony before Congress as they were doing a document review, a source familiar with the process told CNN.

As soon as the document was discovered, Kushner’s disclosure form was amended to include the meeting, the source said.

The emails, which Donald Trump Jr. released Tuesday ahead of a story by The New York Times set to detail the exchanges, show him willing to take information from someone described to him as a “Russian government attorney” whose information was “part of Russia and its government’s support for Mr. Trump.”

“Two weeks after Donald J. Trump clinched the Republican presidential nomination last year, his eldest son arranged a meeting at Trump Tower in Manhattan with a Russian lawyer who has connections to the Kremlin, according to confidential government records described to The New York Times.”

It’s possible that the “records” described here are an admission of the meeting by the Trumps, but I’m skeptical

A tangent. If IC folk can not trust the data, then why should anyone trust any IC assessment?

Scenario: An IC Analyst is investigating a relationship between player Fred and player Gail based upon some ‘intel’. And the intel says that the two players (Fred and Gail) normally communicate between two switches or routers.

And the Analyst has queried data for a previous investigation for the two switches or routers, and everything matched up and made sense.

But in this case investigating Fred and Gail, the data does not match up. Data is missing on one end.

The Analyst shakes head. WTF?

The Analyst has probably heard numerous times, “well this SIGINT comes from older hardware, and there are glitches’.

But, was it really a glitch? Or did someone with ‘Access’ delete or modify some of the raw SIGINT data?

Another reason to pull up all the relevant reports about a subject query: To see who else was read into the program, who else was on the distribution list, who generated work product, who you can safely talk to.