Allow choosing a different purpose/category than the default for an existing built-in service/purpose

Sometimes the purpose associated with a built-in service is simply not accurate or not the best fit for your particular site. 

While the ability to add a service to your privacy/cookie policy from a directory of ready-made services is useful to a point, it really limits its usefulness when you can't customize the service at all.

Sure, you can just create a new custom service, but copying and pasting means we wouldn't benefit from any updates that Iubenda made to the service description on their end. (I assume this might have been one of the reasons this feature was requested.)

Examples of when it would be useful to be able to override the Iubenda-provided default purpose for a built-in service that you're adding to your policy:

1. The AddThis service is hard-coded as being for the "Interaction with external social networks and platforms" purpose, which is hard-coded as being in the "Experience enhancement" (id 3) category.

That might be all well and good for many users, and is probably a reasonable default category to put it in, but it is problematic for two reasons:

1.1. Some people might disagree that AddThis is that innocuous and would be more comfortable listing it under the Targeting & Advertising category instead.

According to Cookiepedia:

> The main purpose of cookies set by this host is: Targeting/Advertising

> The main business activity is: AddThis provides web widgets that site owners embed into their pages or other content, to enable visitors to create and share links to the content across social networks. They also make use of the data collected to provide advertisers and marketers with profile information for targeted, behavioural advertising.

Consistent with that, I noticed that OneTrust auto-categorized them as Targeting Cookies.

So although the intended purpose of AddThis is for social media sharing, it has the unintended side effect of also enabling targeting.

By bundling AddThis with other Experience enhancement cookies, it makes it impossible to opt in to other Experience enhancement cookies without also opting in to these (what could also be categorized as) Targeting/Advertising cookies (id 5).

1.2.  A more practical problem that this classification creates is a bug that is almost impossible to work around currently — but which would be so easy to work around if only it were possible to override the default purpose/category for a given built-in service (just temporarily move it to Measurement category in my cookie policy until the bug is resolved upstream):

Specifically, it looks like the Iubenda Wordpress plugin has AddThis classified under Measurement (id 4). As a result, even though Iubenda itself classifies it under Experience enhancement (and shows it under that category in your cookie policy), if you give consent for that category (id 3), it will not enable the AddThis scripts. And if your cookie consent isn't even configured to include any Measurement cookies, then there would be no way for the user to the AddThis scripts using per-category consent.

You can track this bug here.

2. reCAPTCHA has similar concerns about adding unwanted Targeting/Advertising cookies

(See for example, here and here.)

Since CAPTCHA is usually only needed when a user actually intends to submit a form, it should be possible to override the category of the "Spam protection" purpose from its default category (Strictly necessary) to one that makes the most sense for your specific site:

• On sites where publicly-accessible forms (such as a general contact form) would be considered  a basic interaction, but not an essential one, then Owners should have the option to categorize Spam prevention in the "Basic interactions & functionalities" (id 2) category.
• On other sites where the main (or only) use for spam prevention is for comments, then it should be possible for Owners to instead categorize it as "Experience enhancement" (id 3), to be consistent with the "Content commenting" purpose itself!

But as it is now, having it hard-coded as a Strictly necessary (which by definition is one that cannot be opted out of) means that users cannot opt out of those particular cookies, even if a website Owner wants to give them that choice.

One way that moving that purpose into another category could be leveraged is that users could leave that category turned off until they run across a feature on the site that required it (which, if they never encounter a need to turn it off, they can just leave it off). This kind of just-in-time consent gathering used for reCAPTCHA is described in this article:

> This form uses ReCaptcha. Before sending the form, please accept cookies before sending the form

3.  The "Handling payments" purpose is hard-coded to be in the "Strictly necessary". But that depends on the individual site and is not always accurate!

Sure, it would be accurate for an e-commerce site, or a commercial service that required payment in order to use the core service, for example, but on sites where payment (donation) is optional, it should not be classified as "Strictly necessary".

In those cases, since it absolutely is not strictly necessary to make a payment in order for the site to provide the Service, users should have a meaningful choice (as required by the GDPR) as to whether to consent to such cookies, but because they are classified as "Strictly necessary", they have no such choice.