Welcome! This forum has a treasure trove of great info – Scouters helping Scouters! Just a heads up, though - all content, information, and opinions shared on this forum are those of the author, not the BSA.
Last year, I re-reported an issue that was originally described to SB a couple years before that, where any unit admin can give themselves read and edit access to any other Scoutbook adult’s profile through means so simple, they could be accidental. A fix was promoted but then rolled back, and nothing’s been done to address this privacy loophole, since. What is the plan to protect Scouters’ personally-identifiable information (PII)?
Hi there! This is very concerning. I’m exploring ScoutBook as an alternative to the clunky set of websites our pack currently uses, but if the privacy settings are so lax, I will not recommend to our pack. Please let us know when fix will be relaunched.
This was my thought process, too. I’ve advised my unit adults who want to use Scoutbook to remove all contact info from their profiles until we know this is fixed.
Here’s something interesting. When I tested to confirm SB still lets us do this, I noticed that the user I gave myself access to, doesn’t have any option to reject the access, even if they can see the connection shouldn’t have been made. So - users have to accept my admin rights, and know how to find the site setting that lets them remove themselves from my control, in order to prevent me from keeping it.
If this fix is going to drag on, I do think the email that notifies users their profiles have been linked should be updated to read that admins already have access to their profile (where now it reads that Admins “will have limited access” if they choose to join the unit).
I’m not sure I understand what the issue is. Generally speaking, unit leadership will have access to PII like address, contact methods like email and phone number, etc. This is how units contact the other leaders, the scouts, and their families. I assume that’s not what you’re concerned about.
Are you still seeing that, as soon as the invite is sent (i.e. without clicking “Join”), if the account already exists in Scoutbook then the unit admins have access to the PII? Or does the user on the other end have to click Join?
And, once they see the email invitation, they ONLY have the option to approve me having the access (that is my screen shot above). They cannot remove it (unless they know how to go into their profile and modify their own leadership positions). The email does not in any way indicate that the unit admin ALREADY has access to their PII, nor does it provide instructions on how to remove the connection if it is unwanted.
That’s why I was asking the question. The “accept” button makes sense if there’s no connection before they accept.
I wonder if it would be easier to program a “decline” button as a stop-gap for now, so that people can at least remove the connection. That might improve the situation, at least for people who are on-the-spot about checking their emails.
I agree that making the connection prior to approval, irrespective of the message contents, is a bug.
Decline only helps if someone clicks it. In the meantime, I’ve got all the PII loaded to Scoutbook for that person. We should keep in mind that the user may not have ever used Scoutbook, if their admin created their account. They might not know what data is out there, that someone else loaded.
This appears to be the only topic in the entire new bugs forum where nobody from the Scoutbook Advisory team has responded. @edavignon or anyone, do you know why that is?
I agree that it’s an imperfect solution, but it may be more easily coded than a full solution, so that at least the user has the ability to easily remove the connection. That would act as a partial resolution while the true fix it’s implemented.
The right solution is to require opt-in for the connection.
A new-to-scouting youth and parent join the unit. The adult gives the unit the scout’s name, address, phone numbers, date of birth, school, and grade. The unit adds the scout to their roster; if using Scoutbook, an admin enters the scout into the system. [Waiting for the council takes too long.] The parent also gives the unit their contact info - name, address, phone numbers, email. The unit adds them to the unit roster. In Scoutbook, the admin creates an account for the adult, which starts with name and email. Until the adult logs into Scoutbook for the first time, the admin can enter the account and change name, address, and email. After the adult logs in, the admin has no ability to edit the email address. Adult ssn and bith date are not accessible.
So an admin has the ability to edit the name and address of all the adults on their unit roster. However, the admin may not remove a parent connection, nor tamper with the login or the email address.
Where is the security flaw? The adult hands the unit their contact info and expects the unit to keep it. And if the adult gives updates, the adult would expect the unit to keep their roster current.
Unit admins have basic edit rights to all adult profiles on their roster, to maintain contact info. This does not include removing parent connections, changing email address, accessing date of birth or ssn.
The issue is that, in principle, I could invite you to connect to my unit, Doug, and immediately have access to any personal information you have in your profile, despite you not accepting the invite. This is one thing where, as you pointed out, the person is a member of the unit. However, I verified with a friend of mine that I could invite her to connect and could immediately see all of the admin-visible data in her profile, before she had accepted the invite.
The developers have worked on this since it was originally reported, but it has proven to be rather challenging to correct without creating additional bugs. I’m not exactly sure where it stands presently, but we’ll be sure to keep pushing the development team for it.
Yes - this fix has been pushed 4-5 times - but everytime it broke Scoutbook due to the complexities of the connection system - there are so many variables that is why we are taking more time now to resolve it
Shouldn’t the email notification be updated, then, so recipients at least know the connection is already made, and provide directions on how to break it?