Eliminate fontawesome.com dependency

[soxofaan]

In the jupyter notebook integration, we inject a request to fontawesome.com:

openeo-python-client/openeo/internal/jupyter.py

Line 132 in 83194d7

font.href = "https://use.fontawesome.com/releases/v5.13.0/webfonts/fa-solid-900.woff2"

I am not a lawyer, but as far as I understand e.g. https://law.stackexchange.com/questions/98873/gdpr-compliance-font-awesome, this might be a source of privacy/GDPR issues for entities that provide hosted openEO environments.

Same problem probably with

openeo-python-client/openeo/internal/jupyter.py

Line 6 in 83194d7

SCRIPT_URL = "https://cdn.jsdelivr.net/npm/@openeo/vue-components@2/assets/openeo.min.js"

Regardless of the GDPR/privacy issue, it's also not ideal that we have such hardcoded URLs in the package, without any means to override/disable them (e.g. because they stop working for some reason, or, worse, get compromised, like with the polyfill.io domain attack last year)

How can we improve the situation?

• find GDPR-friendly alternatives?
• reduce/eliminate the need for external hosting of these resources?
  • E.g. can the fonts be replaced with embedded SVG?
  • Or are there ways to allow the user to easily "self-host" on their jupyter environment?
• make the URLs configurable is some way to eliminate the hardcoding problem

[soxofaan]

any quick thoughts here @m-mohr ?

[m-mohr]

We could potentially embed the icons as SVG, should be relatively easy for the Vue Components, but will be quite a bit of work for the Web Editor. We need to follow the license terms, of course.

That solves the issue for one URL, but not for the other URL. We could potentially host the files on openeo.org, but that is just a simple vServer of the university, so pretty prone to outages. And it's just yet another external URL, so that doesn't really solve the issue, I guess. Not sure how to solve this.

For configuration, I guess the Python client (and R) could implement to read from an ENV variable and default to the existing URL?

[soxofaan]

For configuration, I guess the Python client (and R) could implement to read from an ENV variable and default to the existing URL?

Indeed I would do something like that to at least have that escape hatch in place

And it's just yet another external URL, so that doesn't really solve the issue, I guess. Not sure how to solve this.

I should look more into this, but I think it's possible to create some kind of jupyter plugin that includes the desired resources and serves them over the same domain where your jupyter notebooks are running, making the whole thing self-hosted. That would eliminate all privacy issues you get from external domains.