Name Squatting Policy

1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Workflows
5. Name Squatting Policy

On this page

• Overview
• Workflow
• Namespace needs owner contact
  • Namespace owner responded
  • Namespace owner has not responded
• Request successful
• Namespace is not available
• FAQs

Overview

According to the statement of support, namespaces may be released when they meet the appropriate criteria.

IMPORTANT NOTE: If you have any situation that is unusual, or does not fall under the workflow below, open an Issue with Security Operations. Describe the situation and request them to review and provide guidance.

NOTE: When applying any of the macros ensure to replace the placeholder “REQUESTEDNAME” with the namespace requested.

Workflow

1. Search for the requested namespace in GitLab.com admin: users or groups, once found visit the GitLab admin page for the namespace.
2. Apply the Support::SaaS::Name Squatting Policy::Internal Checklist macro in Zendesk. Please remember, impersonating a user will reset the Last Sign-In values on the user account such as Last Sign-In IP and Last Sign-in at (Impersonation should be avoided when reviewing activity on Personal Namespace).
3. Answer all questions in the Internal Checklist (Yes/No) ensuring to cross-check the information found in the admin section. The SaaS Account Ticket Helper App can be used from within ZenDesk to assist with this.
4. If the namespace is eligible for immediate release, follow Request successful.
5. If the namespace is eligible for release, but requires attempting to contact the owner, follow Namespace needs owner contact.
6. If the namespace is not eligible for release, follow: Namespace is not available.

Namespace needs owner contact

Contact Owner:

1. Create a new Zendesk ticket with the namespace owner's email address as the requester (found in admin).
2. Set the form of the new ticket to SaaS Account.
3. Apply the Support::SaaS::Name Squatting Policy::Contact Namespace Owner macro and mark the ticket as On-hold.
4. Make an internal comment providing a link to the namespace requester's ticket.

Requester's Ticket:

1. Copy the ticket's link and add it to the Internal Checklist.
2. Reply to the requester with the Support::SaaS::Name Squatting Policy::First Response macro and mark ticket as On-hold.

Namespace owner responded

If the namespace owner makes a response (don’t remove my namespace) follow these steps:

1. Apply the Support::SaaS::Name Squatting Policy::Cancel Request Macro to the namespace owner's response.
2. Apply the Support::SaaS::Name Squatting Policy::Failed Namespace Request to the namespace requester's ticket.

Namespace owner has not responded

If after one week there has been no response, apply the Support::SaaS::Name Squatting Policy::Contact Namespace Owner macro a second time (replace within 2 weeks in the macro with the due date. Eg. **before the 25th of March**) and mark the ticket as On-hold.

After two weeks, the ticket will be automatically marked as open and an email sent to the assigned engineer.

If the namespace owner makes no response, follow the Request successful steps.

Request successful

If the request is successful, follow these steps:

For users, change the owner's username with Chatops:

1. In Slack, run /chatops run user idle <owner_username>.
2. Add an Admin note.

If you'd prefer to use admin, or for groups, rename the owner's namespace with these steps:

1. Navigate to the namespace in admin - users or groups
2. Select “Edit” on the profile.
3. Append "_idle" to the username in case of a user, or to the group URL in case of a group.
4. Add an Admin note.
5. Save changes.

In Zendesk:

1. Apply the Support::SaaS::Name Squatting Policy::Successful Namespace Request macro to the Namespace requesters ticket and mark the ticket as Solved.

Namespace is not available

1. Apply Support::SaaS::Name Squatting Policy::Failed Namespace Request macro and mark ticket as Solved.

FAQs

1. Does a login in response to a name squatting request mean that the account is active?

   No, the user has to explicitly reply to the name squatting request saying "I want to keep my namespace". If the user hasn't responded and has just logged in, send a final message saying something like, "I see you logged in at X, but you need to let us know here if you want to keep your namespace".

2. What constitutes data in the account?

   A group, a project, etc. means data. Unless the project or group is empty, or there's been no activity for 2 or more years.

3. Is namespace squatting permitted?

   Namespace squatting is not permitted as explicitly stated in our terms. User and group names are provided on a first-come, first-served basis and may not be reserved.

4. Does using a trademark in a way that has nothing to do with the product or service for which the trademark was granted considered a violation of trademark policy?

   Using another's trademark in a way that has nothing to do with the product or service for which the trademark was granted is not a violation of trademark policy. Claiming trademark infringement is a legal process, and we will not release a namespace for trademark violation without a court order.

5. Should we release a namespace even if the request might seem questionable?

   Yes, we should always release the namespace as long as it meets the release criteria. Trust and Safety will take the necessary steps to mitigate any abusive activity which may subsequently originate from the namespace. See Support Team Meta issue 3145 for discussion and additional context from Support, Legal, and Trust and Safety.

Macros

• Support::SaaS::Name Squatting Policy::Failed Namespace Request
• Support::SaaS::Name Squatting Policy::Internal Checklist
• Support::SaaS::Name Squatting Policy::First Response
• Support::SaaS::Name Squatting Policy::Contact Namespace Owner
• Support::SaaS::Name Squatting Policy::Successful Namespace Request
• Support::SaaS::Name Squatting Policy::Cancel Request

Automations

• Status::Open::Reopen namesquatting On-hold tickets after 1 week