Restrict the display of the Consent banner to certain countries/geographic areas

[mouhb]

The objective of this ticket is to show the Cookie Consent Banner only for users from certain countries or geographical areas. For example, on the Swiss Law it is only mandatory to display the Cookie Consent for users from the European Union because of GDPR.

So, it would be good to improve the application to add an option to restrict the display of the Cookie Consent to pre-configured geographic areas (Using IPRanges ?).

[mouhb]

@ProAppsTeam : I will probably implement this improvement, so, I did an analysis of the need and I have 2 implementation proposals. it can be good if you could review them and give your input about the proposed solutions.

Proposal 1 : Use IP address ranges

Basically, we could add an option on the application administration in order to allow administrators specify the IP address ranges of the countries where they want the Cookie consent Banner to be displayed or hidden. Note that an IP range is composed of a "Begin IP address" and "End Ip Address" (ex : 102.129.143.0 - 102.129.143.255). So, we could add 2 text-area fields, one for included IP ranges and the other for excluded IP ranges. The Excluded IP ranges field is useful for example in the case we want to display the banner everywhere except in a specific country (ex : Switzerland).

So, when a user access the wiki the Cookie Consent Application will verify the user IP address and display/hide the banner based on the configured IP ranges (if any). By default if no IP ranges are configured the banner is displayed everywhere as it is now.

Note that there are websites on the internet from where we can get the list of IP ranges organised by countries, see for example : https://lite.ip2location.com/ip-address-ranges-by-country. There is aven the possibility to export them in CSV format.

The UI could be kept simple by only providing text fields for included/excluded IP ranges with the rule of one IP range by line or we could have something more advanced like adding IP ranges one by one, organise IP ranges in groups (ex : specific country, Europe ....) and the possibility to import IP ranges from a CSV file for example.

Pros :

• No need to rely on an external web service

Cons :

• Require configuration effort from the application administrator
• Its implementation is more complex/long compared to the 2nd proposal (see below)

Proposal 2 : Rely on an external web service to geolocate the user IP address

Basically, on the administration section of the application we could propose a list of world counties and the application administrator will be able to select the list of countries where the banner should be displayed, by default all countries are selected.

When a user access the wiki the Cookie Consent Application will rely on a free external web service to get geolocation information (country) of the user IP address and compare the IP address country with the ones selected on the application administration and if the user IP country belongs to the configured countries the banner will be displayed for that user.

For example this web service https://api.iplocation.net/ provides geolocation data of IP addresses.

Pros :

• Easy to implement

Cons :

• Need to rely on an external web service

[lucaa]

If we want to be completely flexible here, we would create an abstraction layer in between and an API for the cookie consent to be displayed or not based on that abstraction, and then the actual implementation of the abstraction would not matter that much and could be multiple (in separate extensions).

Said otherwise: we shouldn't bundle the country detection method (restriction detection method) in the cookie consent app itself, we would just add an API. Then, the method itself can be installed as a separate application and plugged in, could be using api.iplocation.net or some other service that the user of the cookie consent has.

The difficulty here would be the definition of the abstraction, that would need to be generic enough to allow any sort of detection...

A: I'm wondering if a boolean API is enough: an API to which the cookie consent would provide the current user and context + request (page?) and the API would just answer "yes" or "no" whether the consent should be displayed or not. This means that all implementations of this API may need to provide their own configuration section in administration, if admin config is needed for it deciding what countries we show it to and what not.

B: Or whether it would be interesting to introduce the concept of country in this abstraction: the API would provide a country based on the current user and context + request, and then the cookie consent would have a feature of filtering by country (along with a configuration for it). The problem of this second choice is that we basically bind the concept of country in the filtering, while, in theory, the filtering could be done by any other criteria (such as IP range, for example, as you mentioned).

If we do this abstraction, the choice of the actual implementation you do now doesn't matter that much as a new implementation would be easily pluggable.

[mflorea]

I agree with @lucaa that an abstraction layer would be nice, but I'm thinking it could be implemented like this:

• Introduce a "CookieConsentFilter" component role. It could have zero parameters and simply check the context, or pass the current HTTP request as parameter.
• Introduce a "CookieConsentFilterManager" component that injects the list of available CookieConsentFilter implementations and calls them one by one until one rejects the current request

CookieConsentFilter could also return a 3-state "boolean", as in "show", "don't show" and "don't care" (let other filters decide).

Regarding the proposed implementations of "CookieConsentFilter", I'm wondering if the free service doesn't have any limits (how many requests we can make per unit of time). And we'll probably have to implement some caching on our side to not call the remote service multiple times for the same IP address. I'm leaning more towards the first solution.

[oanalavinia]

Hi, @mouhb ! For me the second proposal would be best, since it requires less configuration effort from admins so it's less error prone. But we need to make sure that the API we chose is reliable on the long term.

Regarding the implementation, it would be nice to go with what Anca proposes, to have a level of abstraction so we can be flexible for future needs. But we need to see how to approach the configuration part of these implementations, to not make it more complicated that it needs to be. To be more specific, since Anca was mentioning that each implementation might need it's own configuration section, I am thinking to have only one configuration section for all. It could have the simple countries dropdown (+ a checkbox for including or excluding the provided list), and later on we could add an advanced free text config (which will have priority) which can have documentation for different implementation needs. No matter what configuration is used, the API would receive IP ranges.

But I feel like it's ok to start for now only with the second proposal.

[mouhb]

Hi @lucaa, @mflorea, @oanalavinia,

I checked your proposals and comments, so,

I agree with the Anca's proposal to have an abstraction layer, and as Marius suggested the abstraction could be implemented by introducing :

A "CookieConsentFilter" component role that will check the current context and return a state of the cookie consent banner (Show, Hide).

I don't think that a 3rd state ("don't care") is needed because the cookie consent banner is shown by default, so, returning ("don't care") as a state is IMO similar the "Show" state.

Concerning the configuration section, Lavinia suggested to have one configuration section for all, IMO, if we go this direction, we should provide a more complete configuration section that also offers the possibility to include/exclude IP ranges, this way we cover most use cases. We could also implement an AbstractCookieConsentFilter class and CookieConsentFilter implementations could inherit from that class. AbstractCookieConsentFilter class will expose APIs to retrieve configuration informations (included countries, excluded countries, included ip ranges, excludes ip ranges)

Introduce a "CookieConsentFilterManager" component that injects the list of available CookieConsentFilter implementations and calls them one by one until one rejects the current request.

IMO, it can be good to implement caching on our side regardless of the verification method used (CookieConsentFilter). We could provide an API the clean the cache on demand.

Regarding the implementations of "CookieConsentFilter", I prefer the first solution as I did not find any information concerning the limits of the free service (https://api.iplocation.net/). So, it's a little it bit risky to rely on it.

Anyway, I think that we should start by implementing the abstraction layer (CookieConsentFilter role + CookieConsentFilterManager) and after that maybe implement a default configuration UI. WDYT ?