When a registrant visits their Data Sharing Preferences page, they find an up-to-the-minute list of all the active products they have registered and any products pending consent for the order to complete.
TLDs and products on the Your Data Sharing Preferences page
Actionable or essential items are presented to the registrant first based on our dynamic generation.
When the user has a new pending consent product and an old product with the consent choice complete, the new product appears first.
We display asynchronous products before synchronous products since consent for asynchronous products is required to complete orders.
Data groupings
Each service or product offered through Tucows falls into a particular consent group within our system. Once the consent preference is logged for a group, that choice applies to future product purchases within that same group.
For two products to fall within the same consent group, they must be offered through the same service provider, contractually require the same data elements, and request the same consent-based data elements.
For example, a registry might operate multiple TLDs, and each of them contractually requires the registrant’s name, email, and country and request consent to process the registrant’s phone number. These TLDs fall into the same consent group, and once the registrant sets their consent preferences for one of these TLDs, the registrant’s choice applies to all future purchases of other TLDs within this group. This means that no future consent request emails are sent to the registrant for purchases within this group. When this same registry offers another TLD for which they request consent to process the registrant’s postal address in addition to their phone number, the registrant receives a consent request upon purchasing this TLD since it falls into a distinct consent group.
Tucows groups products this way, so we’re able to reduce the number of consent requests the registrant receives while ensuring the registrant has complete control over which of their personal data are shared and with whom.
Asynchronous and synchronous TLDs
The data elements that Tucows or the GDPR-compliant provider require are collected and processed on a legal basis.
For some TLDs and services, the provider requests additional data for which there is no legal, contractual basis to process. When this is the case, we will ask the registrant for consent to share these additional pieces of data with the provider.
In most cases, even if the registrant should withhold or fail to provide consent, Tucows can immediately register the domain by sending the registry a combination of the contractual data and placeholders for any data elements that can only be processed with consent. We refer to such services as synchronous—they can be registered right away, without additional personal data beyond that covered in the contract.
For some TLDs, placeholder data will not be accepted by the registry. We don’t have assurance from the registry that the data will only be used in ways that conform with data privacy regulations, so Tucows cannot provide the data to the registry without the registrant’s consent. We refer to these services as asynchronous. The service cannot be provided without sharing certain registrants’ personal data with the service provider. There is no GDPR-compliant contract to protect the data; we need the registrant’s permission to share it before we proceed. This permission must be provided in the form of affirmative consent.
Asynchronous domains with yes-consent
To provide an intuitive and transparent experience for the registrant, the consent status for any previously active asynchronous service is set to “yes-consent” by default. The client has consented to the data processing by purchasing the service before these enhanced data protection requirements went into effect. Although consent has not yet technically been provided, an affirmative consent status accurately indicates the current data use settings: the end user’s personal data has already been processed and shared with Tucows and our registry partner(s).
For registrants wishing to revoke consent, a yes-consent status also clarifies the required action: they must uncheck the box and submit. At this point, they are directed to the reseller to complete the request and cancel the service. We want to replace the consent-based data with placeholder data until consent is provided, but we are not permitted to do so by the registry. The service needs to be cancelled for the withdrawal of consent to have any real effect.
In synchronous services for which placeholder data are accepted by the registry or service provider, the consent checkbox starts in an empty state. It only shows a checked state indicating that consent is given when the registrant provides consent.
Back to top
Providing or revoking consent
Synchronous products
If the registrant withholds or revokes consent, any existing services remain active, and any pending orders are processed normally. Tucows substitutes placeholder data for any consent-based personal data.
Asynchronous products
When an order is pending, failure to provide consent within ten days or the decision to withhold consent results in the order being placed on hold.
Note: We cannot complete orders for asynchronous products without consent from the registrant.
Placeholders for consent-based data are rejected at the registry level due to personal data not being handled in a GDPR-compliant manner.
For asynchronous services currently active, when the registrant chooses to withdraw the consent, they are instructed to work with their service provider to cancel the service. While Tucows does not require this consent-based data, it is required by the registry or service provider. That registry or provider has not offered a GDPR-compliant data erasure request process. We are not permitted to replace these consent-based data with placeholder data by the registry or provider. The service needs to be cancelled for the withdrawal of consent to have any real effect.
Refunds due to consent
Tucows does not provide a refund when the end-user decides to cancel an active service because they wish to revoke consent. Tucows logs the registrant’s choice to revoke consent and directs the end-user to work with their reseller to cancel services.
Tucows refunds pending orders that are cancelled when the end-user chooses to withhold consent. The cost of the transaction is returned to the reseller’s account once the order is cancelled. Consent requests remain pending for ten days, after which the order defaults to a non-consented status, and the pending order is cancelled.
Consent contact
Multiple contact messages
Once a purchase is made, the Tucows system waits one minute before sending a consent request email. Multiple purchases within one minute of each other have a single consent request email being sent. Purchases over one minute apart result in multiple consent request emails being sent.
Consent message timeout
The consent request times out when not acted upon. This only poses an issue for registrants of asynchronous services.
Ten days following the initial consent request, the registrant’s consent status defaults to non-consent when we haven’t received a response.
For synchronous services, this holds no consequences, as Tucows continues to use placeholders for any data elements that we process only with consent to do so. Pending orders for asynchronous services are cancelled at the 10-day mark when we don’t have a registrant’s response.
Message triggers
The initial consent request is triggered by the registration, update, or transfer of a domain.
When the registrant sets their consent preferences, their choices are logged and applied to any products’ future purchases within the same consent group. They may receive another consent request if they purchase a service. The provider requests additional data beyond those for which the registrant has already granted or withheld consent to process.
GDPR Consent statuses
For synchronous TLDs, there are four possible consent options.
| Pending | This status means that the registrant has not yet provided their consent choice. |
| Response provided - contract only. | This status indicates that the registrant has declined to share consent-based info; therefore, we only share contract-based data with the registry. |
| Response provided - consent and contract. | The registrant has provided consent to share data elements requested by consent and those requested by the contract. We share both contract- and consent-based data elements with the registry. |
| N/A - all contractual data | In this scenario, the registry requires all data contractually, and none of the data elements depend on the registrant’s consent. |
A registrant’s consent status for a domain is indicated as a gdpr_consent_status value in the get_domain API command response. Please refer to GDPR API changes to define all possible gdpr_consent_status values.
Back to top
Was this article helpful? If not please submit a request here
