After it was first learned that with some success that people could predict Zoom meeting IDs and “bomb” the meeting, I was curious if it were possible to likewise have someone do the same in Google Meet. Just recently, we had our first instance of someone with an inappropriate name joining one of our school’s Google Meets, but how it happened was not because of a technological glitch or “guessing” the meeting code … While this may be possible in future, this post addresses a specific scenario when a Google Meet organizer allows a Google account outside your domain to join a meeting.
To avoid peppering this post with references to bombs and “bombing” when referring to undesired Google Meet participant entry, I am going to refer to the act simply as “sleuthing”, or to the individuals themselves as “sleuths”. I’ve grown to love this word, and since the object ultimately is to discover and gain access to a meeting this just makes sense to me.
TL;DR: If a meeting organizer allows a Google account outside your domain to join a Google Meet, the organizer is never prompted again to approve/prevent this same Google account from joining that particular meeting.
UPDATE 5/20/20: If a Google Meet organizer shares the dial-in phone number and PIN along with the meeting ID, anyone with the phone number and PIN can join the meeting without any approval whatsoever.
Click past the jump for more info.
Sleuthing a Google Meet
So how does one sleuth a Google Meet?
For one, it’s easiest when dealing with an ongoing or periodic meeting. This is usually accomplished by the organizer creating a single multi-day event in Google Calendar and configuring it with conferencing (which can be added by default when guests are added to an event) or via a recurring meeting. In both cases, a single Google meeting ID is used, which allow the meeting to likewise be used as many times as needed until the configured event end date. While this makes it easier for participants to join since it’s the same link every time, as well as prevents the organizer from needing to regularly create and send out new meeting links, this makes it more prone to would-be sleuths.
Assuming your would-be sleuth happens to be a mischievous user within your domain but who’s smart enough not to use their domain account, it’s possible that the domain’s default Google Calendar settings allow internal (and even external) users from seeing full calendar event details by default. If this were the case, the sleuth could use their domain account to get the Google Meet IDs for any user and another account for attempting to access the meetings.
Secondly, you need to have a Google account. These are not difficult to create, and while you do not need a Google account in order to join a Google Meet, there is a difference in behavior when joining a Google Meet with a Google account that is important for being able to perpetually sleuth a meeting.
Lastly, and this is critical, you have to be approved to join the meeting by the meeting organizer. As of this writing, I have not heard or experienced an issue with someone with an account outside the organization domain being able to join a Google Meet without being admitted by the organizer.
When someone is not signed in with a Google account and attempt to join a Google Meet, the user is prompted to enter a name and request to join the meeting. This name is what the meeting organizer sees and ultimately what other participants see if admitted to a meeting. If that same user leaves the meeting and attempts to join again, even if previously admitted, they are once again prompted to enter their name and request access by the organizer.
If the user is instead signed in with a Google account, the first time s/he attempts to join the meeting they are likewise forced to request access to meeting. In this case, the event organizer sees both the user’s first and last name listed on their Google account.
However … and this is the kicker … once a Google account is admitted to a meeting, this individual can leave and join the same Google Meet meeting at will without requiring subsequent organizer approvals. This is the case for any Google account outside your domain. Once the door is opened to a meeting, it can never be closed without creating a new meeting.
Furthermore, because the Google account is outside your domain the user can also likely change their listed name. As a result, a would-be sleuth could be admitted by having a friendly name like “<Your CEO or Head of School’s name here>” and a picture. Once admitted, they can leave the meeting, change their name and/or picture to something nasty or inappropriate, and then rejoin the meeting, again without organizer approval.
UPDATE 5/20/20: Another way sleuths can get themselves into a meeting without requiring organizer approval is via the Google Meet call-in option. Normally, when already a part of a meeting the dial-in option ties the call to the specific user. However, Google Meets also have a generic phone and PIN that if shared would give any would-be sleuth the ability to avoid organizer approval altogether. All that’s needed is the dial-in number, generic PIN, and in the case of a scheduled Google Meet with Google Calendar, knowledge of when the meeting is taking place. A would-be sleuth can join a Google Meet via phone starting 15 minutes before the scheduled meeting time.
Apart from users reporting the presence of a meeting sleuth, the Google Meet Quality Tool can be a helpful ally in identifying them. While opening the meeting details will reveal a ton of useful information including all meeting participants, when they connected and disconnected, when they muted / unmuted, network traffic details, etc., it is difficult to be proactive in identifying potential sleuths.
Organizational users will have their full email listed under participants. In cases where an organizational user calls in via phone for Google Meet audio, this will appear as being from outside the domain. Once the user leaves the meeting, the phone number will be correctly tied to the user.
Anonymous users (those not using a Google account) will have the entered display name listed. These are most easily identified by an adjacent device icon with a question mark.
Google accounts from outside your domain will be listed with the first 4 characters of the email address visible, but the full address – including the domain – is identified only by asterisks.
In my experience, the only way to get these emails and a comprehensive list of all off-domain users that join any of your organization’s Google meetings is to use the Google Meet Audit report (Reports > Audit log > Google Meet).
Once you’ve filtered based on your desired OU and/or date range, you’ll have a lengthy list of entries, including several important fields:
Participant Outside Organisation,
Participant Identifier, and
Participant Name. Of note, is the fact that this list will include some full email addresses, but not all (Google apparently has this information, but just doesn’t share it with us). I’m not 100% certain why this is, but at least some of the data is there. Any columns you don’t want, like the various network traffic information you can exclude them by clicking the gear icon on the right side and removing them.
Once removed, download the report by clicking the download button on the right side. Depending on your range, this will take some time to process with the progress appearing under your G Suite console tasks button at the top.
Once processed, download the file and open it in your spreadsheet program of choice. Applying a filter across multiple columns will allow you to exclude those from your domain. This includes:
Participant Outside Organisation= Yes
Participant Nameis not blank
With these filters in place, you can see the Google account emails and/or names of the users, as well as the meeting IDs and meeting organizer. From there, you can scroll through the list to find any potential sleuths and inform the organizer.
So how does one avoid these sleuths from potentially joining your meetings and causing mischief? I offer a number of recommendations and/or options:
1) Verify your GSuite Google Calendar sharing settings. Configuring the default settings of internal and external event sharing to “Free/Busy only” (Apps > G Suite > Settings for Calendar > Sharing settings) will prevent those who wish to make mischief from seeing the full Google Calendar event details, including the Google Meet link.
End users can still change this access on individual calendars to allow individuals to have greater visibility, if they wish. As you would expect, any guest on a Google Calendar event can see the full details.
2) Avoid creating ongoing and/or recurring Google Calendar meetings. The obstacle here is ultimately about convenience, and frankly a difficult one to overcome, especially within the context of schools. Unfortunately, creating a recurring meeting (weekly, daily, or on a custom interval) despite being separate but linked events, all use the same Google Meet link. And if you happen to be a school that is on a schedule other than a 5-day rotation, this becomes even more challenging to create without using a single ongoing event for each group / meeting / class. Tools like the 6-Day Calendar tool can help in this regard, but ultimately it’s just not as easy to setup as it should be.
The only way then to avoid having to periodically create a new long-term Google Meet meeting whenever a sleuth obtains access is to create individual events. This is much more tedious and a pain for the meeting organizer, but the end result is a different Google Meet ID for each event. So, if a would-be sleuth is accidentally given access to a meeting by the organizer, the sleuth cannot join subsequent meetings without being admitted again, even if they are using a Google account.
Alternatively, users can create a Google Meet on the fly as needed at https://meet.google.com and share via the link via your organization’s preferred communication method.
3) Communicate to users that everyone should be using their org / domain account for meetings. In order to get the most data through the Google Meet Quality Tool and Audit reports about your organization’s meetings, everyone must be using their domain account.
4) Avoid sharing dial-in information unless absolutely necessary. Disable this feature if possible. Because Google as given non-paid GSuite domains the same Meet features as paid domains, all GSuite domains have the dial-in option when creating Google Meets. This must be enabled in the Google Meet Admin Console settings at the OU level and cannot be enabled or disabled on a per-Meet basis.
Unlike accessing Google Meet via URL on a computer or mobile device, anyone with the generic dial-in number and PIN can join the meeting without organizer approval. From a scheduled Google Calendar Meet, the dial-in info listed in the event is the generic dial-in. This differs from someone who has already joined via a computer and goes to the dial-in option from the meeting, which is unique to each user. As a result, there are a few ways to avoid sharing this info.
- Given any guests on a Google Calendar configured with Meet can see dial-in number and PIN, don’t add guests to the calendar event. Email them the Meet URL instead. Clicking the copy button adjacent to the Meet link from the calendar event will only include the Meet URL.
- If already in a meeting, don’t click the meeting name at the bottom left to copy the meeting info, or the initial prompt that appears when creating a Google Meet on the fly. Unlike with Google Calendar, clicking ‘Copy joining info’ will include both the Meet URL and the dial-in information. Copy the Meet URL from the address bar in your browser and send to the participants.
- Encourage users to communicate with participants ahead of time about needing to dial-in and only send this when absolutely needed.
Unfortunately, once someone inside or outside your domain is allowed into a meeting, this gives them access to the full meeting info, including the generic dial-in when they click the meeting info at the bottom left. So, it is still possible for this information to be shared. Depending on your organization, you might consider completely disabling the dial-in option altogether, or at the very least enabling it only for select OUs.
5) Communicate to users to not allow outside participants to meetings. For some this may simply not be possible, as you or your organization may work and meet regularly with individuals outside of it. That being said, the only way a sleuth is able to actively join a meeting is they are allowed in by the organizer.
Alternatively, have users that insist on having perpetual or recurring meetings with the same Google Meet ID create a separate meeting just for when there are outside guests. This way, non-domain users are given access to a temporary meeting and not the larger long-term meeting regularly used by the organizer.
6) Use Google Meet Nicknames. An overlooked aspect of Google Meet (at least for me) is that when you create a meeting from https://meet.google.com, you are prompted to enter a nickname for the meeting. In addition to displaying this nickname at the bottom left for those in the meeting, it also provides a shortcut for joining:
The benefit of using the above method for joining a meeting is the link can be used as many times as needed and so long as the nickname is unique within your domain it will create a new Google Meet ID for each meeting. Once all meeting attendees have left a meeting, after about 30 seconds the meeting is reset and the next time the same link with a nickname is used a new meeting with a different ID is created.
The downside of this method however is that if the meeting organizer does not join the meeting first it’s possible for a participant to become the meeting organizer. In the context of a school, this is particularly problematic since a student obtaining organizer access would mean s/he could mute or remove participants at will, as well as control and own the meeting recording.
At the end of the day, admins and the organizations they serve should be aware of how the video conferencing tools they use can be exploited. It’s ultimately on the organization to dictate policy and clearly communicate best practices in order to balance the needs of day-to-day operations with security. Increasingly, security has become synonymous with prompting users to allow something or someone to do something. The resulting acknowledgement fatigue is undoubtably producing users who mindlessly allow anything and everything they interact with instead of carefully reading the security warnings as they appear. While it’s unlikely that we can fully negate these types of issues for our users, especially those who blindly click ‘Allow’ in every prompt they interact with, communication from both technology and upper-level organization stakeholders is key.