Distracted Driving

So, we (Community Policing) are doing a distracted driving check.  We're at a light-controlled intersection.  The light's red, and the passenger is chatting with us (so that's a positive), and it's a nice, sunny day, and it's a nice chat.

And his Significant Other (who is in the driver's seat), pulls a Big Mac out of nowhere, and takes a huge bite.

I mean, you have to use two hands on a Big Mac, even if you are at a table!

So she's got both hands on the burger, and doesn't have a spare one for the wheel, and isn't looking at the road, because she's making sure the shredded lettuce and goop isn't falling into her lap.  And the light goes green, and they move off.

And I'm thinking, who's driving the car? ...

VM - G - 2.03 - governance - policy breaking policy

Having made the point that you should never create a policy that your volunteers are going to be forced to break, I should immediately note that sometimes policy has to be broken.  You cannot think of all possible situations, and all possible conflicts, when creating a policy.  Your policy is never going to be perfect.  Therefore, there are always going to be situations where the policy has to be broken.

Therefore, one of the things that you should always do is to have a policy breaking policy.  What is it that your people are to do when the policy, for whatever reason, cannot be followed?  As far as possible, this policy should give guidance as to what kinds of occurrences or situations would justify not following a policy.  However, since you cannot foresee all possible situations (and if you can foresee them, you can probably craft your policy in such a way as to avoid those situations), this probably isn't going to be terribly effective.  Possibly the best that you are able to achieve in this regard is to address, or list, principles which might justify the fact that a policy cannot be followed.

More importantly, your policy should, particularly, address who is allowed to make the call that a policy is not to be followed.  Are all the volunteers allowed to make this call?  Are only shift leaders allowed to make this call?  *Are* shift leaders allowed to make this call?  How far up the organizational food chain do we have to go before we reach someone who is allowed to make the call that, in this particular situation, the policy is not to be followed?

In pretty much all cases where a policy cannot be followed, or must be broken, a written report, with justification, should be provided.  Your policy might contain a form, giving details of the situation, the policy that could not be followed, the person making the call, and additional details of date, time, location, and those involved in the situation, both within and outside the volunteer organization.  You may create a form for this purpose, or simply write into the policy the details to be included in any such report, and to whom the report is to be submitted, and copied.

These reports should be reviewed, and as a priority.  The first point to note is whether this situation is likely to recur, and whether your policy has created a situation where the policy must, frequently, be broken.  If so, the policy needs to be amended as quickly as possible.  Once again, ensure that you do not have an active policy which requires that your volunteers are regularly in a situation where a policy cannot be followed.

In some cases the situation might be rare enough that an amendment to the policy is not necessary or justified.  This is possible, but be careful, and deciding this, that you are not simply taking the easy way out.  As noted, no policy is never going to be absolutely perfect, and there are going to be some situations that you simply can't address.  However, ensure that this is truly a rare situation, and that it cannot be addressed by some amendment of the policy.

Volunteer management - VM - 0.00 - introduction and table of contents

https://fibrecookery.blogspot.com/2025/05/volunteer-management-vm-000.html

Persistence of Learned Behaviour Following Extinction of Reinforcement Cues

So, on 10th Avenue, just south of the dip (or the mound, if you are a true original Port Albernian) Dunbar crosses 10th.  Dunbar crosses 10th at a slight angle, but there really isn't anything impairing anyone's vision as they approach the intersection.  Up until about a month ago, there were two left turn lanes for those at the intersection, for those who were turning left, either east or west, on to Dunbar.

The intersection of 10th and Dunbar is one of the proofs that Port Alberni drivers are the worst drivers in the entire world, and possibly an explanation of why.  Yes, the intersection is on a bit of a hill.  Yes, the intersection of the streets is not exactly perpendicular.  But, as noted, there is pretty much nothing to distract you, and no obstructions of the sight lines around the intersection.  And yet drivers keep killing people at 10th and Dunbar.

So, about a month ago, they took out the left turn lanes, and built a median barricade down the middle of the street, in order to prevent people from turning left onto Dunbar from 10th, in either direction.

As I mentioned, previously there were left turn Lanes at the intersection.  So, if you weren't turning at the intersection, but continuing straight on 10th Avenue, in either direction, you had to swing to the right as you drove through the intersection.  But, as mentioned, now they have taken away the left turn lanes, and so you no longer need to swing to the right as you go through the intersection.

But, of course, the reason that Port Alberni drivers are the worst drivers in the entire world is that they pay absolutely no attention to the situation around them.  Including the road, and any huge changes in traffic patterns that may have been built, and signposted.  So, as I was driving up 10th a few days ago, I noticed that a car, ahead of me, as it drove through the intersection at 10th and Dunbar, swung out to the right.  Even though the road was completely clear, and there is no longer any reason to.

I suppose it's no wonder that Port Alberni drivers don't pay any attention to the road, or the cars, or to people on the road, or to any other aspect of the situation around them when they are driving.  Port Alberni drivers don't seem to drive by visual cues, but by muscle memory.

GriefGrads

I am a grieving widower, of three and a half years standing.  I have been through both individual and group grief counseling.  I am looking for some type of, if not exactly peer support, at least sharing of shared misery.

Having been something of a researcher all my life, when my wife died I started researching grief.  I have researched, and developed some resources, on topics such as men's grief, grief scams (I am also, by profession, an information security specialist), grief bots, and a variety of other topics.  I am currently working with a hospice society producing a podcast which we call "A Good Death."  Various articles on different topics of grief can be found at https://fibrecookery.blogspot.com/2025/06/grief-table-of-contents-and-resources.html.

Grief (peer) support groups are composed of people who, by definition, understand bereavement.   Unfortunately, most grief support groups seem to end when the formal group curriculum ends.  One of the hospice societies with which I had some connection had a Saturday tea, which anyone who had taken either individual counseling, or group grief support, through that hospice society was allowed to attend.  (I referred to it as the Grief Alumni Tea.)  There were people from different grief support groups, and some who had just had individual counseling, but all were bereaved, and all were able to provide support, and insight, to each other.  (Unfortunately, I moved away from that area, and into an area where the population doesn't seem to support group meetings that don't involve beer.)

I figured that there must be a lot of places where the population won't really support a face-to-face drop-in situation for informal grief support.  So, I have been attempting to find such, online, so far without success.  Such groups seem to be extremely rare.  So, being not exactly an expert in grief, but having researched it a bit, and being professionally an expert in computer communications, I'm trying to get something started, under the title of GriefGrads.

I would appreciate help from anyone who feels that they would like to participate.  But I would like to make it clear that I am not interested in starting yet another business in the grief industry.  For those in the grief industry, if you find this might be interesting or useful to some of those with whom you have contact, I would appreciate any kind of publicity that you feel able to offer.  If you run something similar and charge for it, I completely understand if you do not wish to publicize this type of free activity.  Those in the grief industry who are looking to advertise their own services or shill for clients are cordially invited not to attend.  If you are, in fact, bereaved, and are willing to talk about your own grief, and help those who participate, I welcome your feedback and participation.

As one of the Internet dinosaurs (I was on the Internet before it was *called* the Internet), I am initially interested in running a group over email.  I realize that many people see this as a kind of a privacy concern.  I have two responses to this concern, first that the identification of those participating in GriefGrads with an email address is a realistic privacy concern, but that the identification of scamming participants with particular email addresses seems to me to outweigh the concerns about participant privacy.  In addition, I know that social media platforms are far less anonymous that many people seem to think.  However, I am willing to consider social media platforms, as well.  Since the girls require me to be on WhatsApp, I would consider this as a kind of a second step in providing a GriefGrads platform.  It provides for easy chat functions (once somebody is on the system), and can also provide for small video conferencing meetings.  I am willing to consider additional social media platforms, with the proviso that I want to make this as accessible to people as possible.  I would consider virtual meetings with video conferencing, such as Google Meet, although I do want to keep the GriefGrads available as a free offering, and the free offerings on the various virtual meeting platforms are generally limited to short meeting times.

For those wishing to participate, you can contact me at rslade@gmail.com

For those who might be concerned that this is a scam, or simply want to check me out, you can start at 

http://en.wikipedia.org/wiki/Robert_Slade

or 

http://shouldersofinfosec.pbworks.com/w/page/146046189/Rob%20Slade%20-%20%28Slade%2C%20Robert%29

or 

http://fibrecookery.blogspot.com 

If you want to check me out even *further* on social media, you can start with the accounts listed at https://www.blogger.com/profile/00652675651093388424

Multi-factor authentication

A friend was asking me about multi-factor authentication apps or just authentication apps.  So, he, unfortunately, got an earful.

We are not doing well with regard to authentication.  We never really have.  Oh yes, I know all the theory.  I have taught it for decades.  Authentication is based on something you have, or something you know, or something you are.  But actually implementing that seems to be really, really difficult.  And it's getting much *more* important, rather than less, that we have reliable and usable authentication.

First of all we went with something you know.  Passwords.  And, of course, everybody chose really stupid passwords.  1 2 3 4 5 6.  I actually got a letter, just this past week, setting up a session, and using that exact password.  When I got into this field, apparently you could get into 75% of all computer systems using the passwords love, or sex, or secret.  Then there was everybody who used their birthday, or their pet's name.  So, for years we have been trying to convince people first to pick reasonably strong passwords, and then, eventually, trying to move away from passwords all together and to some other kind of authentication.

Lots of companies have tried to sell something that you have as a form of authentication.  I have carried various one-time password devices.  Yes, I suppose it uses a password, but it might do a challenge and response type hashing of the password, or a password generation based on the time, or some other means of verifying a non-replayable password, and one that the person can't choose, themselves, in order to avoid all the problems with stupid password choice.  Then there were the various USB keys that you could stick into your computer and use as authentication.  Once again, something that you had.  But, of course, everybody had to agree on which of these systems would be used universally.  And, of course, no vendor would agree to use somebody else's system.  Which is probably a good thing, because that would have meant that we had a monoculture in terms of authentication, and therefore a single point of failure in terms of authentication for absolutely everything.

What people seem to be using these days, in terms of multi-factor authentication, is a secondary backup which, once again, involves something you have.  But, in this case, the something that you have is slightly more reasonable, in that it's a cell phone.  Everybody has a cell phone these days.  Everybody has a cell phone, and, indeed, an awful lot of people are getting rid of their landlines.  So, if everybody has a cell phone, then everybody has a cell phone number, and, as a backup to the password, and an implementation of multi-factor authentication, the system can send you a text with a PIN or code that you have to enter in order to verify that it is, in fact, you that knows your password, and just entered your password in authenticating to the system.

Which I find annoying.  Yes, I have a cell phone.  But I also still have a landline.  I'm a dinosaur, and keep technology around far too long, remember?  And I am not the type of person who walks around with my cell phone actually glued to my hand.  I occasionally turn my cell phones off.  As a matter of fact, when I am home, mostly they are off.  So, when I'm sitting at my desktop computer, and trying to sign on to something, it's a royal pain to have to go, get my cell phone, turn it on, and only then be able to do the secondary verification that, yes, it is me trying to sign on to my account.  For which I have long and complicated passwords, thank you very much.

Now I'm really not sure why, but an awful lot of companies have decided to get into the market, selling authentication, but relying on the fact that you have a cell phone.  Yes, I suppose that there is SIM swapping.  And, if some scammer knows your cell phone number, they can go and get a cell phone, and then, yes, when somebody sends you a text with some kind of pin in it, they can get that message as well as, or possibly instead of, you.  So, yes, I suppose that there is a vague point about authentication apps, on your phone, being somewhat more secure than simply texting a PIN.  But, other than that, in terms of the convenience of multi-factor authentication, using these authentication apps, I have the same objection.  Why should I have to keep my cell phone on, and with me, all the time?

(Yes, yes, I am well aware that convenience is the enemy of security.  I have been teaching that for decades as well.)

I actually only use one authentication app.  It is the BC Services Card.  Now, when I talk about the BC Services Card, I have to explain that the BC Services Card is not, in fact, a card.  It is an authentication app.  It runs on your phone.  It is actually a quite well-designed, and very usable, system.  It had better be.  I well remember sitting in on a presentation when they implemented the very first part of what eventually became known as the BC Services Card.  At that point it was just the public key infrastructure for what would, eventually, in the fullness of time, become the BC Services Card.  So, the BC government (and primarily Gary) have had thirty years to work on the background structure, and how it will work, and how it will work with other systems, and how other people will be able to use the BC Services Card, and how other companies will be able to use the BC Services Card, and how even the federal government will be able to use the BC Services Card, for authentication.  I understand (although I haven't yet tried it) that you can actually use the BC Services Card to sign on to your bank.  Congratulations Gary!  It works.  I had to sign up for it for something that I had to do with the death administration when Gloria died.  I can't even remember what it was that I had to do.  As a matter of fact, although I have come across an awful lot of possible uses for the BC Services Card in the intervening years, I have only actually used the BC Services Card about once every two years.  This means that using the BC Services Card isn't exactly a daily occurrence.  So, each time I have to use it, I have to relearn, all over again, how to use it.  Every time I have had to use it, it has actually been much less traumatic than I always expected to be.  It works.  It works well.  And I was even able to switch it from one phone to another without too much trouble, when I got my new phone.  (I did have to take both phones into the Service BC office.  I suppose that I didn't necessarily have to, but I was definitely nervous about the process, and I figured it was easier to just go into the office then to try and figure out how it worked by myself.)

The BC government, and all the people that I know who work in aspects of the BC government programs which use the BC Services Card, insist that it is very useful, and that everybody knows about it, and knows how to use it.  This is absolute nonsense.  Every time I talk about the BC Services Card, I have to explain that there is no actual card.  I have to explain that it is an authentication app.  There are all kinds of things that you can use the BC Services Card for.  But almost nobody actually knows that there is a BC Services Card, and what it is.  For the most part, unless your wife dies, you don't have to use the BC Services Card.  You can sign on to your bank using some other means.  You can sign on to the Canada Revenue Agency using some other system or method.  The BC Services Card could be very useful.  But it isn't required, and so almost nobody uses it.  If more people used it, and if more people had it ... well, that's sort of the problem isn't it?  If more people had it, more companies would use it.  If more companies used it, more people would have it.  It's a really good system, but you have to get both people and companies to actually use it.  Nobody is going to get it until it becomes useful to them, and no companies are going to offer it, as authentication, until more people are using it.  Catch 22.

But there is, of course, fairly widely used, yet another authentication boondoggle.  This is the fact that, if you go to some website where, in order to use it, you are supposed to have an account, but you don't have an account with this particular system, you can sign on with your Facebook account.  Or your Google account.  Or your own account with one of the other systems one of the other information technology giants, where a lot of people do have accounts, and they provide this form of online authentication.  You sign on with your Facebook username and password, and Facebook authenticates, to the system that you actually use, that you are you, and you should be allowed to use their system.

As I say, a number of the tech giants are starting to get into this particular service.  Once again, everybody would like to be the system that everybody else has to rely on.  One company that is interested in getting into this field is Open AI.  Yes, the people behind ChatGPT.  Now, personally, as far as I can tell, large language models, and generative artificial intelligence, are a solution in search of a problem.  About the only service that generative artificial intelligence seems to have been able to get anybody excited about, is code generation.  So ChatGPT is writing a whole bunch of code for a whole bunch of companies.  (Well, really it's more of an "autocomplete on steroids" function that searches existing code bases.)  (And, I suppose in doing that, that they can't do much worse than an awful lot of the programmers out there.)  But, in terms of authentication, I am less sanguine about the capabilities of hallucinatory generative artificial intelligence.  Since we can't trust the text that these systems produce, why should we trust the authentication that they, supposedly, verify?

VM - G - 2.13 - governance - requirements

Functional and Assurance requirements

In the world of information security, we make a distinction, in determining our requirements for a tool or a system to help us, in regard to the requirements.  We specify two types of requirements: functional requirements, which have to do with the actions of the actual tool; and assurance requirements, which answer the question is the tool doing actually performing, and is the tool actually doing what we intend it to do.

These two different types of requirements can, in fact, be applied to pretty much any task that we asked anything, or anyone, to perform.  What is it that we want done, and how do we know that it is being done, and that it is effective.

I I got what I thought was a nice illustration of this idea one day when I was getting lunch.  I was in a store that sold sandwiches of the types known as hoagies, or hobos, or submarine sandwiches (presumably because of the general overall shape).  When you are eating in a restaurant, or getting food from a takeout place, you will know that there are signs, in the washrooms, saying that all staff have to wash their hands after using the washrooms, and in between every order that they prepare.  This is good hygiene, and pretty much everybody understands why it's there.  This has to do with the functional requirements of preparing food.  You want to ensure that people the people involved in preparing, or serving, food, have clean hands, and definitely hands that are not contaminated by germs transferred from somewhere, or something, else.

The thing is, the only *assurance* requirement that there is that this functional rule is followed is the sign in the bathroom.  Sometimes there may be a sign at the counter instructing the staff that they have to wash their hands between each order.  But, if you pay attention, you will realize that the staff are mostly facing *away* from that sign, and that they actually very seldom wash their hands between one order and another.

But in this particular shop, every time the staff made a sandwich for someone, they pulled a couple of disposable plastic gloves out of a box and put them on.  The disposable gloves fulfill the same functional requirements: being sure that any germs that are on the food preparers has don't transfer to the food that is being prepared.  And, indeed, because the use of the gloves is immediate and fairly easy, it's fairly plain to see that, as they move to somebody else's order, they throw away the gloves that they were wearing, and put on a new pair of gloves.

The functional requirement is the same in both cases: making sure that germs don't transfer from the preparer's hands to the food.  But the assurance requirements are much different.  In terms of determining that the food preparers wash their hands every time they use the washroom, well, you really can't check that out unless you go to the washroom with them.  But, with the gloves, you can see that they put on the gloves.  You also can see that they throw away their gloves when finished with your order, and put on a new pair of gloves when they go to prepare somebody else's order.  So, while the functional requirements for both hand washing and gloves are the same, the assurance requirements are much stronger for the gloves than they are for the hand washing.  Gloves have it all over hand washing in terms of the assurance requirements.

This is something that should be applied to the management of pretty much any task, whether for a commercial enterprise, or for volunteers.  There is the functional requirements of the task that you want done.  Those are generally specified.  But the *assurance* requirements, that the job actually has been done, and that the task that is performed has some effective results, is generally given rather short shift.  Very often, when we send volunteers out to perform a task, we asked them to fill out some kind of report as to what task has been done, how many times, and if there were any incidents in the performance of the task.  To a certain extent, this does fulfill the assurance requirement.  The job has been done, and, a certain number of times.

But there is that sort of second half of the assurance requirement: was this task effective?  That is something that relatively few managers actually think about.  There's an awful lot of work, both paid and volunteer, that gets done, and is a complete waste of effort.  No one has ever checked on the assumption that what we are doing is, in fact, having some kind of benefit.  Think about this some time.  How is it that you know that what you are doing is, in fact, effective?

(In other management literature, some of this issue of assurance requirements is covered under what is known as "metrics," or key performance indicators.  But that's a topic for another time.)

One of my volunteer jobs is community policing, and one of the tasks that we undertake is speed watch.  We take down a lot of statistics: how many total cars do we see, how many of them are under the speed limit, how many are roughly at the speed limit, how many of them are driving about ten kilometres an hour over the speed limit, and how many of them are driving twenty kilometres an hour over the speed limit.  (For this last set, that's the group where we take down the license plates, and they get a polite but pointed letter from the local police.)

The data and statistics that we collect go to the provincial motor vehicle authorities.  Presumably, over time, they can see what the average speed is at the different places where we set up speed watch.  A much more immediate, and significant, assurance requirement to which we pay attention is the fact that we can measure the speed of cars more than half a kilometer away.  We can see that someone who comes into our zone at seventy kilometres per hour, by the time they get to us (and have had the time to see that we are set up), may be traveling thirty-seven kilometres per hour.  We can also see when someone, quite far away from us, slams on their brakes, and the front end of their vehicle is suddenly a lot closer to the ground.

We know we are having an effect.

Volunteer management - VM - 0.00 - introduction and table of contents

https://fibrecookery.blogspot.com/2025/05/volunteer-management-vm-000.html

Luggable dream

I had a dream this morning.  Unusually, when I woke up from the dream, I remembered the dream.  Even more exceptionally, in my case, what I could remember of the dream kind of made sense.  It was about ordinary things, as far as I can remember, and it wasn't totally bizarre.

What I can remember of the dream related to the old luggable computers.  Those of you who are as old, or almost as old, as I am, and worked with technology in those dim and distant days, may remember these suitcase sized "portable" computers.  Originally most of them ran on the CP/M operating system, and later versions ran on PC or MS-DOS.  Most of them had dual five and a quarter inch floppy disks for storage.

As I was waking up from the dream, but still in that fuzzy half state where you're not fully into the current world, I was thinking that these machines would have been in a bit of difficulty these days, since it's hard to get five and a quarter inch floppy disks anymore.

Actually, it's pretty much impossible to get five and a quarter inch floppy disk *drives* anymore.  I don't think that they're making five and a quarter inch drives anymore, and, unlike the three and a half inch floppy disks, nobody ever made, or sold commercially, a 5 and 1/4 in floppy drive with a USB adapter.  Somewhere around here, in my much reduced tech junk pile (or piles), I probably still have a three and a half inch floppy drive with a USB connector.  It has, of course, been a long time since anybody sold a computer with either three and a half, or five and a quarter inch, floppy drives actually installed.

I actually had, and was very proud of, one of the relatively rare Canadian made luggable computers.  It was a Canadian made, and physically exceptionally well designed, Hyperion computer.  Dual floppy drives, of course, and a rather beautiful machine in terms of its ergonomics and overall design.  It did have one fatal flaw: the read only memory, the basic programming that ran everything else, was only designed for PC/MS-DOS version 1.0.  That meant that there was absolutely no possibility of ever installing a hard drive in one of these machines.

(It, along with so much other technology that I had hoped to donate to a computer museum one of these days, went in the mass furor and clear out as Gloria was dying [and slightly before we actually knew that Gloria was dying], while the girls were throwing me out of the townhouse, and moving me to Delta.  There were $120,000 worth of, primarily technical, books that went in that clear out, and more than a couple of trunks full of old computers, old laptops, various kinds of boards, and a whole bunch of ancient technology.)

And, speaking of ancient technology, and five and a quarter inch floppy disks, it reminded me of all kinds of ancient storage media, a lot of which went in that clear out.  As well as a whole bunch of three and a half inch discs, and 5 1/4 inch discs, a whole bunch of eight inch floppy disks went.  There were also various formats of tape storage, including some nine track tape reels.  I never actually worked with punch cards, but I did have an opportunity to play with them at one point, and so there were a bunch of punch cards that went, as well.  I didn't still have any, but I do remember doing some educational programming with twelve inch laser video discs.  (As far as I can recall, the total storage capacity of video on those twelve inch discs was about thirty minutes of video.)  All kinds of storage, all kinds of memory, all kinds of files and information.  All lost, like tears in the rain.

And the dream reminded me not only to write down the thoughts about storage, and ancient storage, and luggable computers, and ancient technologies, but also about multi-factor authentication, and also about my dead phone.  And I was awakened out of the dream at four in the morning, and I've got all these ideas swirling around and have to get them down or I'll never get to sleep, so I guess I'm up for the day.