Name Squatting Policy

Workflow for releasing a namespace deemed dormant by GitLab’s Name-squatting Policy

Overview

According to the statement of support, namespaces may be released when they meet the appropriate criteria, and requested by a paid customer (member of a paid namespace or a self-managed customer migrating to SaaS).

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::Gitlab.com::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 a Personal Namespace).
  3. Answer all questions in the Internal Checklist (Yes/No) ensuring to cross-check the information found in the admin section.
  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) by following this specific workflow to create ticket and user
  2. Apply the macro General::Outbound Contact Request that ensure the new ticket routes properly and the end-user we wish to contact receives the correct notification.
  3. Apply the Support::SaaS::Gitlab.com::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.

If the group contains multiples owners, contact one owner per ticket. Limit to 3 owners if more (you can pick the owners that have the most recent Last activity in the page https://gitlab.com/groups/<group_name>/-/group_members or/and the owner(s) that is(are) listed as Source if still an owner at the time of the namesquatting request).

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::Gitlab.com::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. Use the following snippet as the response in the namespace owner’s ticket and set the ticket to solved:
Namespace Owner Response - Received

Hi,

Thank you for confirming that you wish to maintain control of the requested namespace. Per our [Name Squatting Policy](/handbook/support/workflows/namesquatting_policy#namespace-owner-responded), we have cancelled this request and will not release your namespace.

I'll mark this ticket as solved, please reach out if you have any further questions.

  1. Apply the Support::SaaS::Gitlab.com::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::Gitlab.com::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 has made 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::Gitlab.com::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::Gitlab.com::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

Automations

Last modified February 13, 2024: Update macro names/URLs in Namesquatting Workflow page (af140288)
View page source - Edit this page - please contribute. Creative Commons License