Just gave the attacker her number?
How dense do you have to be?
UPDATED The UK's data protection regulator has criticized London's Metropolitan Police Service (MPS) after its officers handed a victim's stalker details about her new phone number and home address, among other failures. The Information Commissioner's Office (ICO) today issued the MPS with an enforcement notice [PDF] and a …
"How dense do you have to be?"
What? a copper?
They call him PC "Mayonnaise" for being thick, oily and smelling faintly of eggs, not "Einstein".
The procedures don't take protection orders into account and nobody very bright is gatekeeping the information. I expect a court has ordered the release of the documents and there's a requirement that it's done within a certain time frame. Since many such requests will happen all of the time, if information has to be manually redacted, it's highly possible that the requirement will be missed. Switch it around to require that any contact information needs a special order for release and bases are covered. Make the release of contact information something that has to be done individually on a separate request so it can't be included with requests for other things.
Nothing new, I was arrested many years ago on a third parties accusation and the interviewing officers ensured I had sight of that persons name, address and other details during the initial, and final, interview under caution. According to a former Chief Superintendent it's often done to try and trigger a response, either during the interview or whilst released on bail, to shore up an unlikely to succeed potential case against you. Several months later I was invited to accept a caution, for something I hadn't done as Police enquiries had found I had no case to answer and the CPS refused to prosecute/persecute...
It's also a great way of driving 'reported' crime down as victims will hear of such things and not report through fear of being further targeted.
It's a comedy show and the computer concerned is computer senile anyway but, if we want to get technical about it, that's not the right calculation either. While you can't just add IQs, you can't just average them either. That would, at best, get you the mean intelligence of a population. If they were working together, a bunch of people who have small abilities in different areas could combine their skills and achieve a higher score, so a group trying to complete an intelligence test might score higher. This is mostly dependent on their ability to recognize when someone's better at something and to let them do that part, not generally part of an IQ test.
Perhaps this is a case of "reading more in to the situation" than actually happened, but that first MPS breach smells like a major issue.
From a read of this article, it would seem [and seem entirely reasonable] that the MPS has a "Witness Statement Form" or similar - a boilerplate document that allows them to capture concerns raised by a potential stalking victim, in their own words. It would also seem plausible - again from this article - that the alleged stalker has the ability to challenge the accusation, through which they are entitled to see a copy of the complaint made against them. So far I don't think we're on dangerous ground... [Caveat below].
But, also from this statement, it seems that *the design of the witness statement template* includes space *in the main body of the template* for the alleged victim to provide their address and contact details.
That's an out-and-out design error, right there. There is NO WAY that a document set - for this explicit purpose - should be set up... in a way that requires the alleged victim to place their details in the same document - let alone on the same page - as the complaint itself.
In fairness to whichever member of the MPS made the mistake... this smacks of "basic human error". As we learn in the IT industry, the way to ensure that technology you develop is not vulnerable to "basic human error", you address that *in the design* by making sure that your technology has been [for want of a better term] "idiot-proofed".
As programmer Rich Cook notes, "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
In this case it looks as though the MPS didn't even hear the starting gun for their "race" - and just went directly to the design of a vulnerable-by-design form. In a sensible world, MOPAC - the Mayor's Office for Policing And Crime - would immediately step up and investigate the process that led to this... and hopefully would also insist on reviewing every single template, web page and other mechanism by which the MPS record data from victims, just to ensure that there are no other design SNAFUs lurking out of sight. Meanwhile, here on planet Earth, one suspects that there will be a collective shrug followed by someone putting the kettle on...
Sigh...
[ The Caveat: there are going to be situations where a witness statement itself may contain identifying information - at least sufficient to enable an offender to identify the individual making a complaint against them. For example, imagine a situation where something happened in front of a small group of witnesses... It's entirely possible that a statement could contain revealing information, "... and then the man to the right of me said..." which would allow a potentially guilty party to identify the individual behind a statement.
Which doesn't mean that a witness statement must be withheld from someone charged with an offense, but it *does* mean that the statement capture template needs to include maybe a "simple summary" section and then an "in your own words" section, with a REQUIREMENT for the MPS to ensure that any materials sent to any alleged or charged offender has been carefully reviewed - at least twice [Maker/Checker control] before being released.
It rather beggars belief that the MPS don't have process controls around this sort of thing. You can easily see them getting shredded in Court if/when revelations about this sort of practice came to light].
The info may have been in the main body of the statement. Stuff like "the accused called this number at this time on this day, then family member on this number 10 minutes later" is part of the detailed case evidence. Numbers and addresses might benefit from corroborating with 3rd party data sources like telephone records so they're taken down as evidence. The accused then has the right to view that evidence in order to prepare their defence, underpinned very seriously by the right to a fair trial. There've been cases of entire data-dumps from victim's phones being handed to defence teams.
Two fundamental rights in opposition with each other, and balancing them properly requires someone deleting the correct words from lengthy documents, and sometimes from oddball data files, and never ever making a mistake. I don't know what the answer is.
"The info may have been in the main body of the statement. Stuff like "the accused called this number at this time on this day, then family member on this number 10 minutes later" is part of the detailed case evidence."
Agreed.
That's why I think, in this case, it would make sense to split a witness/victim statement form in to a combination of fixed fields and free text...
If an alleged party requested the data, then the fixed field information could be safely processed, but any request for the free text fields should be subject to multiple rounds of scrutiny to ensure that exactly this sort of data breach doesn't happen.
At the same time, I rather think we're discussing a point way beyond the much more basic failing that occurred here [which sounds very much like an alleged perpetrator being sent a verbatim copy of a witness statement, complete with the new contact details from the witness. There is just NO set of circumstances where that is OK. I strongly suspect, if we looked, that we'd find the template captured both the witness identity information and their statement *on the same document*, which is why I am so suspicious about this being a failure of design.
What I'm trying to say is that whatever you do sometimes personal information will inevitably end up in the general statement. The scared victim is rambling on, they're anxious and sleep deprived because the stalking has been going on a long time. Now, finally the police are taking it seriously and taking a proper statement. It's the victim's one chance to get any information over that might help the police investigate their case and actually do something. So they're spilling all kinds of information and the poor overworked constable is writing it all down as fast as she can while thinking of as many different sympathetic words as exist in the English language.
I'm sure some things could be done to better isolate the PI at this stage, but we don't want the police blaming the victim for accidentally putting PI in their witness statement when they were told to please put it all in the correct box B.1 at the top, and given a 3 page technical document defining what PI is and why it needs to be put in box B.1 only. Sometimes the PI the witness puts in the statement won't be their own information and they won't care about disclosing it, but the police still have a duty to notice it and protect it, and that's difficult.
I agree with you the failing does sound potentially more basic in this case, but there've been quite a lot of these and I don't think the general pattern has a strong, infallible solution.
"[which sounds very much like an alleged perpetrator being sent a verbatim copy of a witness statement, complete with the new contact details from the witness."
The defendant is due full discovery which includes any witnesses statement. It should be verbatim since any summary/paraphrasing might distort that statement. What they don't need is the PII on the form which is very much necessary if that witness needs to be called to testify or clarify what they have written. The PII could go "on the back" so a scanned copy being provided would only have what's on the front and the name (20260704 Bob1 Wit case 12356b89755). The name would be used to identify the statement and the PII can be pulled up by the judge. If the relationship listed on the back says "victim's brother", that may inform the judge whether releasing that PII is prudent of not. If the judge is concerned about reprisals or tampering, they can not release the information and have the court issue a summons for having the person appear for testimony or another deposition.
It's a balance between upholding a defendant's right to confront their accuser and protecting victims and witnesses from reprisals. In the case of stalking, there should be bias towards protecting the victim and witnesses. Sealed records are common enough. It's a matter of creating a workflow that prevents leaks.
Your comment, "It's a balance between upholding a defendant's right to confront their accuser and protecting victims and witnesses from reprisals", prompted me to dig deeper in to this.
In the UK, this is a matter of applying relevant statutory frameworks rather than any form of subjective balancing act - the Criminal Procedure and Investigations Act [CPIA] (1996) includes provisions in two broad topics which should have addressed what happened in this case.
The first provision is the Redaction of Contact Details. That's pretty cut-and-dried - there is literally no justification for what the MPS failed to do in the first example given in the article. A caveat to this - the Act talks about the decision to redact being "under court direction" ... but a court cannot so direct if it is not given the opportunity to do so.
The second is with regards to what are termed "Sensitive Materials Schedules" ... information that presents a real risk of serious prejudice to an important public interest (such as witness safety) can be placed on a "sensitive material schedule" rather than being handed over unconditionally in raw form.
If we turn to the case in question - one of a person accused of stalking - it seems quite reasonable to suggest that provisions of the CPIA are applicable: the law is clear; there is a legitimate case for redaction that can be taken before a court. Which brings us quite neatly back to the essence of my first post, which suggested that this has the ring of a systemic failure rather than an accident or oversight by a single MPS officer. A diligent police force - *especially* the Met - would be expected to have procedures in place for *exactly* this sort of scenario. In fact, giving them the benefit of the doubt, I'd suggest they are already there. But that's why I think this suggests a deeper failure - because if the Met does/did have procedures in place to ensure that this sort of disclosure didn't happen, then something profound has gone wrong here.
Caveat: I don't have to hand any objective data that shows how many complaints the MPS receive in a year where there is a reasonable basis for applying the CPIA. To give them at least some credit, the article talks about *two* cases. As a subset of actual complaints of this nature raised, we might be discussing something in the range of a tenth or a few hundredths of one percent.
As a technologist with a fair amount of control architecture/design experience, I'm well aware that it is commonplace to have technology controls for sensitive operations: for example we might reasonably configure Access Administration roles so that no single administrator can grant privileged access to a user... or we might programmatically enforce a "maker-checker" control for all outbound email from client-facing teams, to ensure that communications containing client-sensitive information aren't accidentally mis-addressed. This sort of thing is second nature to a mature technology shop with good operational controls. It doesn't follow, however, that this sort of discipline extends beyond technology in to other operational areas.
I take the points that you and others have raised about the difficulty of sifting e.g. the free-text of a witness statement and trying to discern whether or not it contains "identifying information"... but we have to weigh that against the potential for threats against the well-being or life of a witness. If you were asked by an MPS officer to give a witness statement for a crime you observed, how would you feel knowing that there were no robust safeguards to ensure that your details were not released to the accused? But that difficulty is why I think the effort to safeguard the witness has to start "up front", with ensuring that the statement collection process captures relevant data, whilst ensuring that PII is not disclosed.
I don't believe we should tolerate any excuse for the MPS not doing that - and not taking all precautions to ensure that such practices are followed.
Definitely something for MOPAC to be looking at.
"balancing them properly requires someone deleting the correct words from lengthy documents, and sometimes from oddball data files, and never ever making a mistake."
A court should be able to provide a list of names/numbers to be redacted/replaced. If a phone number is replaced with "victim's cell phone", that should suffice rather than the number itself unless there is a motion to show the original records to double check at which time a judge can decide how that will be allowed. There may be a ban on taking photos or copies of the documents in their unredacted form during inspection. If an attorney were to divulge that information, the chance of losing their license and being subject to sanctions is a real threat.
"That's an out-and-out design error, right there. There is NO WAY that a document set - for this explicit purpose - should be set up... in a way that requires the alleged victim to place their details in the same document - let alone on the same page - as the complaint itself."
I can see an issue with having to keep track of separate documents for the same bundle. I expect the document will be scanned and provided digitally rather than photocopied so the form could be ingested in a way that places the contact information in a protected space that takes extra effort or permission to reveal. Some clerk needing to process document requests would not be able to deliver the contact information without doing extra work. Even a tiny wee bit of "extra" work will be avoided by most people. Subpoenaed documents from a court/attorney will have some sort of ID number. If a clerk must enter that number into the computer to unlock the PII separately with no copy/paste allowed, they wont' do it if they don't have to. They could, but that's a different issue. There could also be an additional requirement of the clerk having to enter their ID number when processing documents a court has deemed sensitive. That could be VIPs, stalking cases, organized crime, protected witness info, etc.
No amount of data protection training is going to stop the CC/BCC confusion happening regularly, that's not a solution.
It should be possible to completely disable CC, and multiple To addresses, and any similar footguns, in the email client, at the highest level of authority and in a way that can't be turned back on. I don't know any software that does this currently but if you're an org as big as The Met you are in a position to get someone to make it happen.
Maybe because option, the word and the concept were both absent from the original post, which wanted CC/multiple to addresses turned off at all times and hardened against attempts to re-enable it. While whether to do that or not in the first place is an option, once you've done it, changing it is intentionally difficult. That makes for some problems if you need to include multiple people on an email for any reason.
An easier thing, but a weaker one, is to have limits so you get warned if you try to CC more than five people. You can do that in a mail client, either through settings or with a plugin. I have one of those in Thunderbird, which isn't actually its purpose* but I've left that on just in case. But undoubtedly if we turn that on we'll still hear the stories of someone putting four people in CC who shouldn't have been there.
* The plugin is for basic mail merge. I don't use it that often, as I have written software specifically for larger mail lists, but occasionally I have a reason to do something manually. If I include too many recipients, the plugin warns me that I'm not using it and maybe I wanted to. So far, that warning has never been correct, and I could turn it off, but I don't mind occasionally clicking once more and maybe some day it will save me from a mistake.
A more secure system than email should be used for collaboration. Email is only needed for external untrusted contacts, which should never be shared with each other because they're untrusted.
Even if you're not an org handling sensitive information it's almost impossible to have a list of 18 email addresses that you know are all valid, up-to-date, uncompromised and trusted. And if you have 2 or 3 addresses you need to collaborate with then you can just write 2 or 3 emails and copy/paste the content.
This post has been deleted by its author
Agree. In a new software system this would be considered a design fault, but because email has worled like this for 50 years we’re just supposed to live with it?
Here’s a starter for ten: if more than five people outside your organisation are CC’d in, display a confirm dialog explaining what will happen and did they mean BCC instead?
"No amount of data protection training is going to stop the CC/BCC confusion happening regularly, that's not a solution."
In a matter of a court case, BCC is an issue since matters often need to be in the open. Counsel from either side can't talk to the judge privately, for instance. The problem is more "reply to all". Many documents are required to be sent to all parties and it's easier if that isn't done through a large number of individual mails. It's far less appropriate in many cases to reply to everybody unless that's done affirmatively. It should be something in all email programs that's more than a quick hit of the return key to reply to all. That sort of problem happens all the time.
@Blazde
It is easy to do.
I have a very "Mickey Mouse" email system I threw together (very rough & ready but does the job, though it is tailored to a specific use case - for wider use it would have to include (spit) HTML email - by design it just uses plain text - anything exotic is added as an attachment).
Maintains mailing lists of recipients and no bcc or cc - for a message sent to a mailing list it processes the mailing list and sends one email per member, with that member as the "to" recipient.
The UI has no cc or bcc option, only to (& it behaves sensibly in parsing into separate email addresses if you try to have multiple email addresses in the to field, and sending to each separately)
It's for a couple of community groups I'm involved with and ensures no accidental leakage of data (all very pointless as most people have other group members contact details anyway as they are usually friends to some degree even if on opposing sport teams) just to be super GDPR compliant, emails only go to opted in members etc. Total overkill, but benefit is that I know I will not make a PII screwup (& it was a fun bit of code to write)
Damage limitation:
1) Disallow email addresses in the CC field that have a different domain than the sending address. This could be enforced by the MTA rather than the client.
2) Client shows a warning dialog requiring confirmation whenever attempting to send an email with more than 1 address in the CC field. The default action is cancel.
"1) Disallow email addresses in the CC field that have a different domain than the sending address. This could be enforced by the MTA rather than the client."
That won't work. Many documents need to be sent to all parties. They could all go in the "To:" line, but sometimes it's better to put the addresses in the CC line to signal that it's informational and done as a courtesy or is required for bookkeeping. Being on the To: line means it's important to those people. BCC: is right out for court matters. How and where information is being disclosed is very important.
Used to run workshops on Data Protection now it is all online CBT tick box training to cover themselves with the ICO - still get regular breaches from my Local Council and Car Dealers sending me other peoples insurance details Even the ICO give up on minor breaches and only really target large and potentially public facing one.
“We are aware that these incidents can have real consequences for victims and have apologised to those affected by these two cases."
Maybe real consequences are also needed for those responsible. Sending victim details to suspects or convicted perpetrators should be a sacking offence. Once the word gets out that that has actually happened it will be more effective than any amount of training.
I prefer treating things like this as bugs that need to be fixed at the process level. Unless the victim's contact information was included deliberately, it's likely because a system didn't automatically prevent this and someone didn't manually review it enough to do so. That's an opportunity to understand which failures specifically happened here and improve them more generally. Having automation that can prevent most of this can make it easier to enforce proper attention on the manual bits.
Also, if I got to have my preferences about sacking police officers, the ones who engage in deliberate misconduct, including falsely arresting people based on flawed surveillance, would all be sacked immediately. I expect there are enough of those that they probably would need to keep those who just made mistakes to deal with the shortfall, as long as those can be taught how not to make similar mistakes in the future.
"Maybe real consequences are also needed for those responsible. Sending victim details to suspects or convicted perpetrators should be a sacking offence."
There's so much paper flying in the legal system that many things are sent inappropriately. The victim's details might have been sent to the perp's attorney who then shared those documents with the perp as there was nothing on the document that stated anything that they shouldn't. Discovery rules require that documents are provided to the defendant before they can be used in court. That includes a list of witnesses. I don't see a universal need for victim and witness PII to be provided every time which means that it should take an extra step of permissions to get it. The system must be set up to gate keep things as a default. A witness list from the prosecution/plaintiff needs to be provided to the defense, but the PII shouldn't be included. The former will already have it so it doesn't need to be disclosed to the latter. The same goes for a witness list provided by the defense.
Form 12345-P is filed by the prosecution. The defense gets pages 1-5 with 6-8 redacted and not supplied. Reason: PII of victim/witnesses. Form 12345-D is filed by the defense with the same sort of restrictions going the other way. All of the information is available to the court and they can hear motions to release or inspect that redacted information. I don't think it would be too hard to automate that sort of thing so accidental release would be difficult and FOIA might be turned away if the system seals those records.
In Italy we have Carabinieri, who are the subject of a ton of jokes, many of which actually happened (like a friend that went to the station to report his wallet had been stolen, and being asked to provide his ID, which was in said wallet, and without which they wouldn't accept his complaint), but I'm often seeing that every country has its own police organization that is in a constant race with the others for the biggest failure.
No mention here about the modern replacements for Wayne Couzins (or David Carrick ) having access to the domestic arrangements of stalking victims.
What am I missing here? How many more criminals are carrying warrant cards?
The MET needs a new name: "Wayne Couzins University".................