DRAFT Privacy Documents – Input Welcome

DRAFT Privacy Documents – Input Welcome

Please have a look at these draft privacy documents from the Oakland Ad Hoc Advisory Committee on Privacy & Data Retention.

We welcome your input. Please leave comments with your ideas or concerns.

The people of Oakland need your voice!

Please help us make the best privacy policies possible.

Thank you!


3 thoughts on “DRAFT Privacy Documents – Input Welcome

  1. Greetings from Seattle! You are doing great work.

    I have a comment about data sharing agreements. These are nothing to celebrate. Public officials love these agreements because they appear to limit but actually promote sharing with other agencies. Such agreements have no force in the face of subpoenas, warrants, and willing accomplices. A big lesson gained from federal privacy offenses is that law enforcement and the security establishment play dirty. Judges can be convinced of anything if “national security” is mentioned, and it’s always mentioned, even when the targets are local protesters.

    Data Retention = Data Sharing.

  2. Thanks, David. You’re right about the nature of data sharing agreements. They help with data flow transparency; less so with control.

    We’ve had little push-back on short/no data retention. We were puzzled until we realized that most of those organizations providing the upstream video and non-video data sources (like transit agencies, county law enforcement, etc.) through the Port DAC would make their archives directly available to Oakland’s first responders and EOC participants, bypassing the Port DAC system; and bypassing the City of Oakland’s Port DAC’s policy controls. Other policies apply, like extant data sharing agreements.

    So while we’re working to make the Port DAC’s policy framework complete and robust, I’m skeptical if it will materially affect how much and when upstream information flows into the hands of non-local agencies when they express a need or interest.

  3. I serve on the committee. Thanks for covering it thus far! I wanted to share a list of questions I submitted to the most recent (July 24) meeting which will likely be included in the emails that get sent out for the next meeting. The questions are regarding data abuse, an area I was asked by the chair to cover. Hopefully I’ll have a more fleshed out set of recommendations while everyone reflects on these questions, and maybe adds more 🙂

    Submitted by aestetix (24 July 2014)

    Prevention of Abuse
    i. Data safeguards
    ii. Penalties for Abuse
    iii. Data Security
    iv. Abuse via Public access laws
    v. Checks and Balances

    Some thoughts regarding data abuse:

    How do we handle data ownership? Is it owned by the people of Oakland? If so, then a “data breach” is difficult to define, because I usually define that as “access by someone who does not have authorization to access the data.”
    We need to flesh out what “abuse” means. Is this abuse of access? Abuse of the data itself? For example, can someone insert false data into the system to make it appear that there was a crime, when there wasn’t? And likewise, can someone replace data that shows evidence of a crime with data that removes that evidence? This is why we need to have an audit log, which would be a fantastic safeguard.

    Once we have defined “abuse”, what kinds of penalties will there be? For example, with HIPAA, there are several tiers, including an employee losing access or being fired, the company needing to put out a public announcement, the company needing to pay a fine, etc. The data protection/penalities in the US are fairly lax, and I think Oakland could set a shining star example by showing the world we take this seriously.

    Regarding data security, this depends on the kind of data. In general, we want to make sure data is available for law enforcement to solve crimes, but we don’t want to wind up with terabytes of old data that can be used in the future for bad things. Suggestion one is that we simple delete all data older than X days, provided that law enforcement agrees they will not need it past that time. If, as some have suggested, state laws prevent us from doing so, I’d recommend encrypting the data older than X days such that a court order would be needed to “unlock” it. If we identify encrypted data by “this encrypted data is for a camera at this intersection for this date and time”, I imagine that would be sufficient for a judge to decide whether it’s relevant to an ongoing case.

    More on data security: will the data be limited to computers inside the DAC, or will cleared employees be able to put any data on a portable computer (laptop) and remove it from the facility? It’s probably wise to insist that all computers with DAC related data run full disk encryption, so that in a disaster (someone breaks into the DAC and steals a computer) they need a password or other form of authentication to unlock it.

    For IV I am unclear on what the public access laws are, thus will refrain from comment at this time.

    Checks and balances: as I do not (yet) know much about the workings of the City of Oakland, I will perhaps naively assume they are trustworthy 😉 I will not make that assumption about DHS or the company that has likely been outsourced to create the DAC software. I suggest we get a third party security audit of the software, and do not proceed until we have gotten their stamp of approval. Example scenario: DHS sources the software to a company which has relations with China and builds secret backdoors into it, thus allowing uncleared foreign nationals to learn how the Oakland security system works. I have a slew of requests for the place that creates the software for DAC, including how often they expect to do updates, what security audits they are already doing, and what qualifications their employees must meet before being allowed to write said software.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s