Undated photos provided by City staff, with confidential info obscured, at our last meeting of the DAC ad hoc advisory privacy and data retention committee. I serve on that committee, appointed by Council Member Dan Kalb. This room is in the Emergency Operations Center (EOC).
The part of the Domain Awareness Center (DAC) you can see is an app running on the four Windows computers in the front row. The data sources streaming through the apps can be seen by looking over someone’s shoulder and when mirrored to monitors at the front wall of the room.
The operators don’t use the DAC software to record incoming video streams as a default. Per EOC staff, their procedure, when when observing a potential event-in-the-making, to “bookmark” in the software to start recording until a decision is made.
This next photo is a reverse shot, from the front of the room…
Should an event be triggered or this room is needed for another purpose, staff monitoring the DAC streams can continue work in another room equipped with similar computers, software, and connections.
This last photo is an updated closeup of the front of the room, with a new software-defined, multi-screen, large display.
My first thoughts on the DAC’s anatomy:
- Mobile, web, and other clients will come. There is little reason to compel operators to sit at a particular desk for a watch. It’s not too far off when the DAC can not only mirror a live or recorded video feed from the server to the EOC’s big screen but also to a fire chief’s tablet, a police unit’s laptop, or a Port security officer’s phone. This will extend the number of “insiders” with access to the data.
- Access control? Why is the DAC software only on four machines? Is this a per-seat licensing issue from a third-party publisher? A technical limitation? A way to minimize in-house tech support?
- What are the DAC software’s EULA and ToS? The Committee doesn’t know the software’s provenance, who makes it, who updates it, what restrictions may be attached. This is a concern since many systems, like Shotspotter, claim data collected and organized by their systems as proprietary, and may move data to systems not under City control or jurisdiction. The Committee should also know the software’s licensing, warranties, terms of service.
- Include some archives by reference. If the video feeds are from non-City/Port sources, like a BART station, and if that agency archives the video, it’s likely our “bookmark” metadata should suffice for compliance with California data retention laws, so long as we can properly cite/point/link to the archived source material.
- Our sensors, our archives? If the video feeds are from City/Port sources, like Oakland street cameras near the Port, we may be responsible for retention.
- What’s a DAC? We still don’t have crisp definitions for where the organizational, user, hardware, and network parts of the DAC begin and end.
Generally, a DAC policy is moot without an EOC policy. There is no physical wall around the DAC. It is just one EOC role among many; the always-on wake-me-if-something-important-might-be-happening part of the team. Practically speaking, all the information flowing through the DAC system is available to non-DAC personnel in the EOC simply by looking at the computers or talking to a DAC software user a few feet away. The EOC’s mutual aid and similar responsibilities, which including incident data sharing, have been tacitly prioritized over privacy concerns, including any policy we specify for the DAC-proper. This DAC’s very purpose is to share critical information with those responsible for partial or full EOC activation and with those who respond to an incident. How do we balance the City’s need to protect Oaklander’s from privacy intrusions and data-sharing-overreach with the City’s duty to be effective in police, fire, and other matters?