-
-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid usage of third party CDN due to legal reasons #3353
Comments
Copies from flarum/issue-archive#8 as this topic is quite important if your Flarum instance is accessible to EU users. |
Hey, we actually wrote a post about this https://www.jsdelivr.com/blog/how-the-german-courts-ruling-on-google-fonts-affects-jsdelivr-and-why-it-is-safe-to-use/ |
Excellent news, thank you for the legal analysis on this (and for jsDelivr itself, of course!). With this in mind, we've decided to close this issue for now. We might eventually revisit this topic, but for now we're only keeping issues for items that we definitely plan on tackling in the close future, and for which we've settled on a technical approach. We'll be posting an explanation of the new issues/discuss discussions soon. |
Thanks for the input. I guess jsDelivr is not the most unbiased source to decide whether it is a good idea to use jsDelivr. This is not about panic but risk management. At the moment there is a non-zero chance for legal trouble if you provide Flarum to EU users. The risk is higher if the admin lives in Germany, as it is now know which court to go to. On the other hand I do not see any significant benefit in using jsDeliv for just a few files. There are even downsides besides potential legal issues regarding performance and security. I'd propose to have Flarum self-contained by default and not depend on third party services. It should be up to the users/admins to use a CDN or not. @askvortsov1 Please reconsider if you are open to use patches. It worries me that this was just closed without discussion and lacking any information why users should be put at risk here. |
@pierres We are always open to PRs. We are closing this issue as we've determined that the jsDeliver legal teams analysis is fair and reasonable.
In the case of the Emoji library images (the only thing I can find that uses jsDeliver at the moment) the sheer number of images makes the required amount of storage (and thus download size of Flarum) more than triple it's current size. We could in theory possibly reduce this by using a sprite based system, however that would require mapping all of the emoji to their sprite location, and keeping that up to date. |
I'd like to clarify @pierres that using the flarum/emoji extension is completely optional. Most mobile and desktop operating systems have their own emoji integration already (windows + . for instance). The emoji extension can be easily disabled and uninstalled should there be any security or privacy concerns which we cannot confirm after careful review. The extension is meant to simplify the use of emojis mainly on desktops, but without it emojis can still be used and Flarum remains fully working. |
Feature Request
Is your feature request related to a problem? Please describe.
Some first party extensions load resources from third party CDNs like jsdelivr. This might violate EU laws like GDPR. As these files can easily be hosted locally this puts Flarum hosters at unnecessary risc. See recent rulings like https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/ Note: I am not a lawyer and from a technical perspective I might not agree with such rulings.
This affects the following extensions:
Describe the solution you'd like
By default Flarum should provide all necessary resources locally and not rely on third party hosts.
Justify why this feature belongs in Flarum's core, rather than in a third-party extension
This would require forking core components just to provide some additional files and a different CDN url. Actually utilizing a third party CDN should be provided by an extension and not the other way round.
The text was updated successfully, but these errors were encountered: