Suppose that a multilevel database relation with element level labeling is constructed to summarize potentially sensitive flight mission information, as depicted in Figure 1.1. This relation's schema specifies a primary key of Flight ID and three attributes that describe the Origin, Destination, and Cargo of each flight. Associated with each element is a security label.

Flight personnel on the ground, who are cleared to Secret, may need to be privy to Flight ID and Origin/Destination information. However, it may be desired that the nature of the flight manifest be at times hidden to all but Top Secret users. For example, Flight 007's cargo of alien spacecraft debris may be considered Top Secret. However, ground personnel may learn weight and size specifics, and may even be witness to the real-world loading process. The absence of data in the Cargo field would increase the likelihood of low users correctly inferring the presence of a Top Secret cargo with resulting natural curiosity as to its nature. It is possible that such an inference would threaten the success of the mission.

Instead, a "cover story" could intentionally be created so that low users are placated by the plausible, but erroneous statement that the cargo consists of weather balloon debris.

The question then becomes how to store and manage this conflicting information in the database.

Flight ID

Origin

Destination

Cargo

. . .

007 S

Roswell S

Area 51 S

Weather Balloon Debris S

007 S

Roswell S

Area 51 S

Alien Spacecraft Debris TS

Originally posted by Hal9000
I'm not able to see it, my FF browser just sits there and nothing comes up. Any one else able to see it with FF?

I'm sure it was somebody's idea of a joke, and probably not meant to be seen by the public. Nice find.

What else is there on how to cover something up besides this flight database?

Why would they need a manual on how to cover something up anyway? The government always tells us the truth, don't they?