jonathanwestmoreland.com

Tag: vendor access

  • What Reasonable Safeguards Would Look Like in Bend

    What Reasonable Safeguards Would Look Like in Bend

    Part 9 of the Bend Surveillance Oversight series.

    This does not have to be a yes-or-no fight over police technology.

    Bend can support legitimate public safety tools while still requiring strong public oversight.

    The real question is not whether technology should ever be used.

    The real question is whether powerful systems are governed by clear public rules before they expand.

    Body cameras, fleet cameras, ALPRs, drones, traffic enforcement cameras, digital evidence systems, AI tools, and real-time information platforms all raise different questions.

    But they also share a common issue:

    They collect, store, search, analyze, or share public data.

    That means Bend should have a citywide surveillance technology policy.

    Not a vague promise.

    Not vendor assurances.

    Not scattered contract language.

    Not internal rules that residents cannot easily find.

    A clear public framework.

    1. Public inventory of surveillance technologies

    Bend should publish a plain-language inventory of all police surveillance technologies.

    That inventory should identify:

    • the technology name,
    • the vendor,
    • the department using it,
    • the purpose of the system,
    • what data it collects,
    • where the data is stored,
    • how long the data is retained,
    • who can access it,
    • whether outside agencies can access it,
    • whether vendors or subcontractors can access it, and
    • whether any AI, biometric, analytics, or automated decision features are enabled or available.

    Residents should not need to search scattered agendas, contracts, staff reports, and vendor documents to understand what systems exist.

    2. Council approval before acquisition or expansion

    Bend should require Council approval before any department acquires, renews, expands, or materially changes surveillance technology.

    That should include new tools, new vendors, major software modules, AI features, biometric capabilities, data-sharing expansions, and contract amendments that materially change what a system can do.

    Public approval should happen before deployment, not after the system is already operating.

    3. Public use policy before deployment

    Every surveillance technology should have a public use policy before it is deployed.

    That policy should explain:

    • the approved purpose,
    • allowed uses,
    • prohibited uses,
    • data collection rules,
    • retention rules,
    • access rules,
    • sharing rules,
    • audit procedures,
    • disciplinary consequences for misuse, and
    • how residents can find annual reports.

    The public should be able to read the rules before the technology is used.

    4. Short retention for non-evidence data

    Data retention should be limited.

    For non-evidence data, the default should be deletion after a short period unless the data is tied to a specific, documented case.

    For ALPR data, I would support a default rule like this:

    Non-hit ALPR data should automatically delete within 72 hours unless it is tied to a documented case, warrant, stolen vehicle, active investigation, or legally valid evidentiary need.

    Short retention allows legitimate use while reducing the risk that ordinary residents’ movements become long-term searchable records.

    5. Logged searches with case numbers

    If a system can be searched, every search should be logged.

    The log should identify:

    • who searched,
    • when they searched,
    • what they searched,
    • why they searched,
    • the case number or incident number,
    • whether the search produced a result, and
    • whether the result was shared.

    Search logs protect the public from misuse.

    They also protect officers who use the system properly.

    6. Limits on federal, out-of-state, private, and vendor access

    Local surveillance data should not become outside-agency data by default.

    Bend should limit access by federal agencies, out-of-state agencies, private companies, vendors, subcontractors, fusion centers, and other third parties.

    Access should require a documented purpose, legal authority, written authorization, and an auditable record.

    Broad sharing, informal access, and bulk access should be prohibited unless explicitly approved through a public process and consistent with law.

    7. No facial recognition or biometric identification without explicit approval

    Bend should prohibit facial recognition, biometric identification, biometric analytics, or similar identity-matching tools unless Council explicitly approves them after public notice, public debate, legal review, and technical assessment.

    If a system is technically capable of biometric analysis but the City says the feature is disabled, that should be independently verified.

    Disabled features should not become active through a quiet software update or vendor configuration change.

    8. AI report-writing rules

    If Bend ever uses AI to help draft police reports, the City should require strict auditability.

    The basic rule is simple:

    No AI-generated police report without an audit trail.

    That means preserving original AI drafts, officer edits, source transcripts, timestamps, final reports, supervisor edits, and disclosure that AI was used.

    Prosecutors and defense attorneys should be able to obtain relevant records through normal legal processes.

    9. Independent technical audits

    Bend should not rely only on vendor assurances.

    The City should require independent technical audits of surveillance systems.

    Audits should verify:

    • enabled features,
    • disabled features,
    • retention settings,
    • sharing settings,
    • access controls,
    • security controls,
    • vendor access,
    • subprocessor access, and
    • compliance with City policy.

    Trust is strongest when systems can be independently checked.

    10. Annual public transparency reports

    Bend should publish annual surveillance transparency reports.

    Those reports should include:

    • what systems were used,
    • what new systems were acquired,
    • how many searches occurred,
    • how many outside requests were received,
    • how many requests were approved or denied,
    • how many audits were performed,
    • whether misuse was found,
    • whether any new features were activated,
    • whether policies changed, and
    • what the total annual costs were.

    Transparency reports do not need to reveal sensitive case details.

    They should provide enough aggregate information for residents and elected officials to know whether the rules are working.

    11. Contract terms that match public policy

    Contracts should not undermine policy.

    If Bend adopts public rules, vendor contracts should match those rules.

    Contracts should prohibit vendors from changing settings, enabling features, expanding sharing, using data for product development, or using local public safety data for AI training unless the City explicitly approves it through the required public process.

    Good policy should be backed by enforceable contract language.

    12. Public review before renewal

    Surveillance technology should not renew automatically without public review.

    Before renewal, the City should publish a report explaining how the system was used, whether it met its stated purpose, what it cost, whether misuse occurred, whether audits were completed, and whether stronger safeguards are needed.

    Renewal should be a public decision, not an automatic default.

    The basic framework

    A reasonable Bend surveillance policy could be summarized like this:

    • Tell the public what systems exist.
    • Require approval before expansion.
    • Limit retention.
    • Log searches.
    • Restrict sharing.
    • Control vendor access.
    • Ban biometric use without explicit approval.
    • Audit AI tools.
    • Verify systems independently.
    • Report to the public every year.

    That is not anti-police.

    That is responsible governance.

    Powerful public safety tools should answer to public rules.

    Further reading

    Series links

  • Why Federal and Third-Party Sharing Matters

    Why Federal and Third-Party Sharing Matters

    Part 7 of the Bend Surveillance Oversight series.

    In the last post, I wrote about why ALPR scans are location records.

    A license plate reader does not just capture a plate number.

    It creates a record that a specific vehicle was seen at a specific place at a specific time.

    But there is a second question that matters just as much:

    Once a city collects surveillance data, does that data stay local?

    That question applies to ALPRs, body cameras, fleet cameras, drone video, real-time information platforms, traffic cameras, evidence systems, and other police technology.

    The concern is not only what Bend collects.

    The concern is who else can access it.

    Local data can become outside-agency data

    A resident may feel differently about local police using a tool for a specific local purpose than they do about that same data becoming available to state agencies, federal agencies, out-of-state agencies, fusion centers, private vendors, or other third parties.

    Public consent for one local use should not be treated as consent for every future use.

    That is why data-sharing rules should be explicit before technology expands.

    Local data should not become outside-agency data by default.

    The policy should be explicit

    Data-sharing rules should not be vague.

    A policy that says information may be shared “for law enforcement purposes” may sound reasonable, but it can be extremely broad.

    A stronger policy should say exactly:

    • who may access the data,
    • for what purpose,
    • under what legal authority,
    • with whose approval,
    • with what documentation,
    • for how long,
    • whether access is logged,
    • whether the public will receive aggregate reporting, and
    • whether the request can be denied.

    If the policy does not clearly prohibit broad sharing, residents cannot know where local surveillance data may eventually go.

    That uncertainty is the problem.

    Federal access requires special caution

    Federal access deserves special attention because federal priorities can change quickly.

    Local residents may support local public safety uses while objecting to unrelated federal uses, especially if those uses involve immigration enforcement, political activity, protests, reproductive health travel, religious activity, or other sensitive areas.

    A strong policy would say:

    Bend surveillance data may not be shared with federal agencies unless there is case-specific legal process, written City authorization, a documented local purpose, and an auditable record.

    That rule would not prevent lawful cooperation in a serious case.

    It would prevent broad, informal, or routine access.

    Vendor access is also third-party access

    Third-party sharing is not only about government agencies.

    Vendors are third parties too.

    If a private company hosts police data, maintains the software, provides analytics, troubleshoots systems, stores video, processes license plate reads, or manages user access, that company may have some level of technical access to the system.

    That access should be limited, logged, and auditable.

    Vendor access should never be a black box.

    Contracts should clearly define when a vendor can access data, what the vendor can do with it, whether subcontractors are involved, whether data can be used for product development or AI training, and how the City verifies compliance.

    Outside sharing can create long-term consequences

    Once data leaves a local system, it may be harder to control.

    It may be copied, retained, searched again, combined with other databases, or used for purposes residents never debated locally.

    That is why sharing limits need to be set before sharing occurs.

    The point is not to block legitimate, case-specific cooperation.

    The point is to prevent broad access, informal access, bulk sharing, or secondary uses that bypass local democratic oversight.

    What a stronger local rule could require

    A stronger Bend policy would require:

    • case-specific legal process for outside-agency access,
    • written City authorization before sharing,
    • a documented purpose for every request,
    • a case number or incident number when applicable,
    • logs showing what was shared and with whom,
    • limits on vendor access and subcontractor access,
    • prohibitions on bulk or informal sharing,
    • clear retention limits after data is shared, and
    • annual public reporting in aggregate form.

    These safeguards would not prevent legitimate public safety work.

    They would make sure powerful data-sharing systems answer to public rules.

    The basic principle

    Local surveillance data should not become outside-agency data by default.

    If Bend collects police technology data, the City should clearly define who can access it, when it can be shared, how sharing is approved, how access is logged, and how the public can verify that the rules are being followed.

    The solution is not complicated:

    No broad sharing. No informal access. No vendor black boxes. No federal access without case-specific process. Public reporting every year.

    That is how local control becomes real.

    Further reading

    Series links

  • What Happens to the Data?

    What Happens to the Data?

    Part 4 of the Bend Surveillance Oversight series.

    When people talk about police cameras, the conversation often focuses on the camera itself.

    But the camera is only the beginning.

    The more important question is what happens after data is collected.

    • Where does the video go?
    • Who stores it?
    • How long is it kept?
    • Who can search it?
    • Can it be shared?
    • Can vendors access it?
    • Can outside agencies access it?
    • Are searches logged?
    • Can the data be used later for a different purpose?

    These are the questions that turn a camera discussion into a public oversight discussion.

    Collection is only step one

    A body camera, vehicle camera, drone, traffic camera, or license plate reader may collect video, audio, images, license plate data, metadata, location information, timestamps, or other records.

    But collection is only the first step.

    After that, data may be uploaded to cloud storage, attached to case files, searched by officers, shared with prosecutors, retained for years, reviewed by supervisors, exported for court, or combined with other systems.

    A technology policy that says “we use cameras” is not enough.

    The real policy should explain what data is collected, where it is stored, how long it is retained, who can access it, when it can be searched, whether searches require a case number, whether searches are audited, whether vendors can access it, whether outside agencies can access it, whether data can be used for AI training or analytics, and whether new uses require public approval.

    Cloud storage changes the oversight question

    Many modern police technology systems rely on cloud storage and vendor-managed software.

    That can be useful.

    Cloud systems can make evidence easier to organize, share, redact, and preserve.

    But cloud storage also changes the oversight question.

    If public safety data is stored in a vendor-controlled system, residents should know what contractual rules apply.

    They should know whether the City owns the data, whether the vendor can access it, whether subcontractors are involved, whether data is encrypted, and whether the City can independently verify how the system is configured.

    This is why public policy should not rely only on verbal assurances.

    The City should publish the actual rules.

    Retention matters

    Retention is one of the most important privacy questions.

    A camera that records something and deletes it quickly is very different from a system that keeps searchable records for months or years.

    The longer data is kept, the more it can be searched later, shared later, misused later, breached later, or repurposed later.

    For Bend, a reasonable policy would be:

    Delete non-evidence data by default after a short period unless it is flagged for a specific, documented case.

    For ALPR data, I would support a default deletion period as short as 72 hours unless the scan is tied to a legitimate case, hit, warrant, stolen vehicle, or documented investigation.

    Search logs should be mandatory

    If a police technology system can be searched, the search should leave a record.

    That record should show who searched, when they searched, what they searched, why they searched, the case number or incident number, whether the search produced a result, and whether the result was shared.

    Without search logs, the public has to trust that the system is only being used properly.

    With search logs, the City can verify whether the system is being used properly.

    This protects the public.

    It also protects officers who are using the system appropriately.

    Sharing rules should be explicit

    Data-sharing rules should not be vague.

    A policy that says data may be shared “for law enforcement purposes” may sound reasonable, but it can be very broad.

    A stronger policy would say that surveillance data may not be shared with federal agencies, out-of-state agencies, private companies, or other third parties unless there is a specific legal basis, a documented case number, written authorization, and an auditable record.

    The point is not to prevent legitimate case-specific cooperation.

    The point is to prevent broad, informal, or automatic access to local surveillance data without clear public rules.

    Vendor access should not be a black box

    Vendor access is also a form of third-party access.

    If a private company hosts police data, manages software, provides analytics, troubleshoots systems, stores video, or controls user permissions, the public should know what limits apply.

    Vendor access should be limited, logged, and auditable.

    Contracts should make clear that vendors cannot use local public safety data for unrelated purposes, product development, AI training, or secondary analysis without explicit public approval.

    Public reports build trust

    The City should publish annual transparency reports for police surveillance systems.

    Those reports should include:

    • what systems were used,
    • how many searches were conducted,
    • how many times data was shared,
    • how many outside-agency requests were received,
    • how many requests were approved or denied,
    • how many audits were conducted,
    • whether any misuse was found,
    • whether any new features were activated, and
    • whether any policies changed.

    These reports do not need to expose sensitive case details.

    They should provide enough aggregate information for residents and elected officials to understand whether the rules are working.

    The basic principle

    The goal is not to prevent every use of technology.

    The goal is to make sure powerful tools answer to public rules.

    A camera policy should not stop at collection.

    It should follow the data.

    Where it goes, how long it stays, who can search it, who can share it, and how the public can verify the rules are being followed.

    Further reading

    Series links