Top 10 Ways to Improve Your Handling of Email

Email now apparently takes more than 2 hours of a typical person’s job, in any given day, a figure which I figure is likely exceeded for a typical attorney. With that kind of time invested in it, you’d think we’ve collectively gotten better, over time, at handling it -not so, if you ask me.

I happened this morning on a post entitled 40 One-Sentence Email Tips which inspired me to distill my own experience (of 20 years reading/writing emails), for your benefit and my own. Here it is, in the hope it may help us be more productive:

  1. Send less emails, receive less emails;
  2. Limit your consents to receiving mass emails (like newsletters);
  3. Use your email app intelligently – don’t spend time manually saving emails into folders, etc.;
  4. Don’t generally answer emails instantly or at all times of the day or night, or risk involuntarily training recipients of your emails to expect that level of responsiveness;
  5. For any new email, start by asking yourself whether this communication channel is appropriate for this particular discussion (would a text or a call be better?);
  6. If email is the way to go, don’t C.C. any person that doesn’t really need to see that email (as you’ll be wasting their precious time with your thoughtless inclusion of their address);
  7. Give your email a Subject that does describe adequately what it’s about (dhu);
  8. Start your emails with a sentence or two that provides context and what specifically you hope to get back from this recipient (information, action, etc.);
  9. In the body of your email, be brief and concise: keep sentences and paragraphs short, and limit the length of your email to about a page -max;
  10. Be kind to recipients of your emails and use plenty of spaces and bullet points, to make scanning your message easy and quick (typically, that person will want to spend about 30 seconds reading it).

We’re collectively spending A LOT of time on electronic communications, which doesn’t mean the average person (or lawyer, for that matter) knows how to handle it adequately. Remember, your email app should work for you, not the other way around.

Québec’s Own French Language Open Source Licenses

While doing some work as to open source, I recently came across a section of the list of officially accredited open source license and that includes 3 licenses Made in Québec. These were apparently created by Québec authorities for its own purposes. Not too surprisingly, the original version of these 3 open source licenses is in French, contrary to most others of this kind.

The official site www.opensource.org now lists these 3 licenses, which I’m linking below to a micro-site created by the Centre de services partagés du Québec called Forge gouvernementale”. The presentation of the documents on this site is much easier to read than the version posted on opensource.org (that presents the text of each license in a single block of text):

The OSS licenses at issue were created with the government’s software development efforts in mind and (initially) presented in French, though an English translation is available. As with other open source licenses, the goal here is to free source code in the manner that maximizes the users’ rights and the ease with which it may be used and redistributed down the line. If you’re curious (I was), the Québec government published the following FAQ about these licenses.

The first license (LiLiQ-P) is akin to the Apache open source license and, thus fairly permissive. The code released under this license may be included in other software that is then distributed without having to make it available with the source code and without being required to distribute it through an open source license.

The other 2 licenses (LiLiQ-R and LiLiQ-R+) are relatively similar to somewhat more restrictive licenses such as the MPL license and the LGPL license, requiring that resulting software be made available, including as source code, through a LiLiQ-type license. Another feature of the licenses at issue resides in their reciprocity provisions, generally allowing the combination of LiLiQ code with code made available pursuant to most other open source licenses.

Is anyone really surprised that Québec would want to express how different it is from the rest of Canada (and the world) by creating its own version of an open source license? Eh, why not?

Alleged Flaws in Cellebrite UFED May Allow Throwing Out of Locked Smartphones Evidence

It is inevitable in today’s world that law enforcement is sometimes faced with mobile devices that a suspect locked prior to their seizure by authorities. Locking your devices is good common sense security: This goes for you and I, and, yes, for criminals. As a result, the police will sometimes need to break the encryption on such mobile devices in order to get to the data within, either for investigative or evidentiary purposes. That’s when tools such as Cellebrite UFED come into play. By using UFED, law enforcement can break into otherwise secure devices, such as iPhone smartphones, and get to the data within.

Unfortunately for the prosecution side, someone recently obtained access to UFED and analyzed its security features. These were found to be, shall we say, lacking. Indeed, according to Moxie Marlinspike (creator of the Signal app), ironically, cybersecurity isn’t exactly UFED’s strong suit. In fact, according to his report, after looking at the product, he believes this tool’s security is so weak that even scanning a booby-trapped device may result in an alteration of the data that was or is later extracted using UFED.

In short, in their efforts to secure some evidence, it seems that some police forces are using a tool whose reliability may be called into question. Indeed, if the tool at issue cannot be counted on to provide data that is a reliable record of what really was found in a particular device, should such evidence not be thrown out?

Legally, the fact that a tool used to extract information is prone to tampering may not bode well for convictions obtained on the basis of the resulting evidence, at least if the vulnerabilities reported by Moxie Marlinspike can be substantiated. Some American defense attorneys intend to argue against convictions secured by the authorities based on evidence extracted from locked smartphones. This could lead to the need for new trials in some cases.

UFED is apparently used by many law-enforcement agencies throughout the world. We don’t yet know how many convictions this inconvenient revelation may eventually allow defence attorneys to call into question.

This is yet another example of the perpetually problematic relationship between cybersecurity and the law.