feat: make video embeddings optional.

[CheariX]

As discussed in #1181, I suggest to make embedding videos an optional feature.

This behavior aligns well with recently merged PR #2312.

Open questions:

1. I added a youtube link to papers.bib. Is this link okay?
2. I set enable_video_embedding: false as the default. I argue that privacy settings should be the default. Also, the current implementation of video.liquid only works for some very specific video URLs. For example, to embed youtube, specialized links must be used to avoid X-Frame-Option issues. This behavior can lead to a broken embedding, which would not look very nice.

Feedback welcome.

[george-gca]

I added a youtube link to papers.bib. Is this link okay?

Yes.

I argue that privacy settings should be the default.

You also mean the one that downloads the 3rd party libraries?

Also, the current implementation of video.liquid only works for some very specific video URLs. For example, to embed youtube, specialized links must be used to avoid X-Frame-Option issues. This behavior can lead to a broken embedding, which would not look very nice.

This PR solves this issue? If not, I believe this would be a nice addition to our README, maybe in FAQ.md?

Also, I believe the current solution (displaying the video below in a small collapsible area) for the bib part is not worth it. It is not even displaying properly, also the video is too small to be useful. I think we should change it to always open in a new window. What do you think?

[CheariX]

I argue that privacy settings should be the default.

You also mean the one that downloads the 3rd party libraries?

Yes. Basically, I'd like to change these settings in _config.yml:

enable_publication_badges:
  altmetric: false
  dimensions: false
  google_scholar: false

third_party_libraries:
  download: true

By implementing these settings, the website will not send requests to any third-party domains (a desirable feature in compliance with EU/GDPR laws, as there is no need for a consent banner). However, I have noticed one exception: https://distill.pub/third-party/katex/katex.min.js. Unfortunately, I could not find any means to disable this particular connection.

People who are fine with third party requests can then easily enable these features in the config.

Maybe we can open a PR or Issue to address and discuss this issue separately.

Also, the current implementation of video.liquid only works for some very specific video URLs. For example, to embed youtube, specialized links must be used to avoid X-Frame-Option issues. This behavior can lead to a broken embedding, which would not look very nice.

This PR solves this issue? If not, I believe this would be a nice addition to our README, maybe in FAQ.md?

• video.liquid works for https://www.youtube.com/embed/aqz-KE-bpKQ => /embed/
• video.liquid does not work for https://www.youtube.com/watch?v=aqz-KEP-bpKQ => /watch?v=
• Please note that I used youtube-nocookie.com instead of youtube.com in paper.bib. But the result is the same for both domains: one must use the embed link to use youtube in an iframe.

I'm not sure what one should expect here.
I always had youtube links in my video tag, but no dedicated embedding links.
We could do some find/replace magic to allow regular links, but I did not want to touch video.liquid since I'm not gonna use the embedding feature anyway.

Also, I believe the current solution (displaying the video below in a small collapsible area) for the bib part is not worth it. It is not even displaying properly, also the video is too small to be useful. I think we should change it to always open in a new window. What do you think?

I'd be totally happy with that. If you like, I can add this removal to this PR.

Not sure about youtube, but I think one use case was that some people hosted their own *.mp4/webm/ogg files and refered them in the video tag

[george-gca]

People who are fine with third party requests can then easily enable these features in the config.

I would vote for the opposite, at least regarding the publication badges. It is useful to demonstrate how this would look like in our demo site, in case the user wants to keep it. Maybe add something citing how/why to disable this regarding privacy issues, probably including some of the information already cited here, in one of our README files, maybe CUSTOMIZE.md.

I'd be totally happy with that. If you like, I can add this removal to this PR.

Not sure about youtube, but I think one use case was that some people hosted their own *.mp4/webm/ogg files and refered them in the video tag

I think this addition would be nice to have. Even though someone might embed their own videos there, the viewport is too small to be useful (I think). If the user wants, it would be more useful to open it in a new tab, or even open it in a way similar to a zoomed image works.

[CheariX]

I think this addition would be nice to have. Even though someone might embed their own videos there, the viewport is too small to be useful (I think). If the user wants, it would be more useful to open it in a new tab, or even open it in a way similar to a zoomed image works.

What kind of addition do you mean?
Do you want any further changes in this PR?

The embedding feature can be enabled with the enable_video_embedding: true option.

Edit: Maybe I should solve the merge conflict first...

[george-gca]

Also, I believe the current solution (displaying the video below in a small collapsible area) for the bib part is not worth it. It is not even displaying properly, also the video is too small to be useful. I think we should change it to always open in a new window. What do you think?

I'd be totally happy with that. If you like, I can add this removal to this PR.

I was talking about this part.

[george-gca]

Thanks for the changes.