Fix Support for embed.ly with Odysee.com (half working)

[tomatodysee]

Hey guys, we recently added oembed / embedly support but odysee.com links don’t work properly due to the iframe settings you are pulling in.

Can they be setup to match youtube? Either need to remove the allow-scripts, or add: sandbox=’allow-scripts allow-same-origin allow-popups allow-presentation’

Example: ​https://tomzarebczan.wordpress.com/2022/02/28/test-odysee-post/ – you’ll see the errors in console.

Adding odysee oembed provider. You can validate it working here: ​http://debug.iframely.com/?uri=https%3A%2F%2Fodysee.com%2F%40TheRingOfFire%3Ac%2Fwhy-is-the-manhattan-da-sabotaging-the%3A8

Not sure if additional changes have to be made in order to remove the iframe security = restricted or allow for proper iframe options.

Trac ticket: (https://core.trac.wordpress.org/ticket/55278)

[peterwilsoncc]

Can you please answer each of the questions of the ​checklist for adding new oEmbed providers to the allow list?

The quickest way to get embeds working for your site would be to limit the HTML to the allowed list of tags for auto-discovery, this includes links, blockquotes and iframes with a limited set of attributes. See ​https://github.com/WordPress/wordpress-develop/blob/107050f7a34d0b728e4c38bfc946e3339578ea6f/src/wp-includes/embed.php#L921-L936

For iframes, you'd also need to ensure any JavaScript and other code within the embed can be run in iframes with the attributes sandbox="allow-scripts" security="restricted".

By enabling auto-discovery, your site's embeds will work on both WordPress versions below 6.0 and you won't need to go through the checklist above.

[tomatodysee]

Replying to peterwilsoncc:

Can you please answer each of the questions of the ​checklist for adding new oEmbed providers to the allow list?

The quickest way to get embeds working for your site would be to limit the HTML to the allowed list of tags for auto-discovery, this includes links, blockquotes and iframes with a limited set of attributes. See ​https://github.com/WordPress/wordpress-develop/blob/107050f7a34d0b728e4c38bfc946e3339578ea6f/src/wp-includes/embed.php#L921-L936

For iframes, you'd also need to ensure any JavaScript and other code within the embed can be run in iframes with the attributes sandbox="allow-scripts" security="restricted".

By enabling auto-discovery, your site's embeds will work on both WordPress versions below 6.0 and you won't need to go through the checklist above.

Hey Peter, thanks so much for the reply!

From our research about how "allow same origin" works with sandboxing, it should be safe to use if site A and embed site B are on different domains. Source: ​https://stackoverflow.com/questions/28332829/can-an-iframe-release-itself-from-allow-same-origin / ​https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/

"Note, however, that you need to be very careful when dealing with framed content that comes from the same origin as the parent. If a page on ​https://example.com/ frames another page on the same origin with a sandbox that includes both the allow-same-origin and allow-scripts flags, then the framed page can reach up into the parent, and remove the sandbox attribute entirely."

I have read other places that say it's not recommended, but they usually don't mention the same origin caveat.

Do you have any more information on this?

Right now our iframes fail with: Uncaught DOMException: Failed to read the 'cookie' property from 'Document': The document is sandboxed and lacks the 'allow-same-origin' flag. since we use cookies on the site.

[peterwilsoncc]

The ​sandbox attribute documentation on MDN is pretty clear about this:

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

(my emphasis)

Locking down access to window.parent within auto-discovered embeds is quite intentional. The sandbox attribute's settings were discussed in #32522 but it's quite lengthy.

[tomatodysee]

Replying to peterwilsoncc:

The ​sandbox attribute documentation on MDN is pretty clear about this:

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

(my emphasis)

Locking down access to window.parent within auto-discovered embeds is quite intentional. The sandbox attribute's settings were discussed in #32522 but it's quite lengthy.

My emphasis:

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

So since wordpress and odysee are not the same origin (domain), this doesn't apply from what I understand.

From [34903], it also sounds like it's possible to embed wordpress on other sites, and that embed has the proper security restrictions.

Is the concern that someone may embed a wordpress page on odysee, and then that is embedded on another wordpress site? Or someone embedding a wordpress site that has an odysee embed, on Odysee? The first isn't possible because we don't support iframes/oembed consumers, and the 2nd would be protected by the wordpress iframe security settings.

I don't mean to stir up confusion or rehashing of an old decision about this, it's just that iframes + iframe security are fairly complicated, and hence, misunderstood. All my research has shown similar findings to the above arguement about it being on different domains.

Our embeds also work via iframes if users have a paid wordpress account, so we'd have the same security vulnerability there if this were true (and it would also apply to other, more malicious sites/actors).

We're just trying to make it easier out of the box by using the Odysee URLs vs embed code. If going down the oembed provider path is the only way, we can try to do that, but it sounds overkill + will take quite a bit of time.

Appreciate your time and feedback once again!

[tomatodysee]

@peterwilsoncc answering the questions as you asked, let me know if this works:

Is the service is popular enough for core developers to have heard of it before? Is it “mainstream?”
Odysee has been around for 1.5 years now and evolved from lbry.tv (~2019, now sunset) and a LBRY Desktop application in 2016. Today, Odysee.com has over 32M+ monthly unique visitors and is used by prominent content creators, many of which have millions of youtube subscribers.

If similar services are already supported, how does this service compare in terms of size, features, and backing?
No, this is new.

Does this service have a large following on Twitter, Facebook, or other social media? Is its Twitter account verified?
Twitter account is verified and has over 55K followers: ​https://twitter.com/OdyseeTeam . This is our main social media platform, and on our own site, we have over 1.3M followers: ​https://odysee.com/@Odysee:8

Is its oEmbed endpoint clearly established and properly documented? (Sometimes, they are just a developer’s pet project that may not be supported.)
Oembed implementation can be found here: ​https://github.com/OdyseeTeam/odysee-frontend/blob/master/web/src/oEmbed.js
We are also supported on embed.ly, and you can validate our URLs here: ​http://debug.iframely.com/?uri=https%3A%2F%2Fodysee.com%2F%40veritasium%3Af%2Fwe%27re-building-computers-wrong-%28for%3Af

Does the oEmbed endpoint work with WordPress’ oEmbed auto-discovery? If not, could it be made to work with additional HTML tags or attributes being added to the allow-list?
No, only works via paid wordpress accounts + via our embed code. Our iframes use cookies, and require the same-site origin flag which, as discussed
above, is not secure enough based on WordPress standards.

Does the service make an effort to build relationships with developers, such as through robust APIs?
Majority of our code is open source, and we work with outside contributors all the time!

How old is the service?
1.5+ years, but LBRY has been around since 2016.

Does it have a well-established Wikipedia article? (Seriously.)
Right now it’s under LBRY, but we hope someone will correct that. Odysee is now a separate company outside of LBRY Inc (for the past ~6 months). ​https://en.wikipedia.org/wiki/LBRY

Has anyone written a WordPress plugin that leverages the service in some way, whether adding it as an oEmbed provider, creating a shortcode, or leveraging other APIs of the service? Do these plugins have any noticeable adoption or traction that would indicate usage and demand?
There’s a wordpress plugin for LBRY: ​https://github.com/lbryio/lbrypress, but it didn’t get much traction. LBRY Inc is revamping it to make it easier to use/integrate.

Is the provider frequently proposed?
We get many requests from users and creators to support Odysee links on WordPress!

[tomatodysee]

Wondering if anyone had the time to review the above or has any questions?

[peterwilsoncc]

I don't think the service is popular or stable enough to be added to the allow list.

I suggest either modifying your embed so it doesn't set cookies on the parent page or create a plugin for the official ​WordPress plugins repository to see if it gets traction there.

[tomatodysee]

May I ask what made you come to a conclusion about stability?

35M+ unique visits a month is not enough for a video site? Only a few long standing alternatives can say the same, and this area needs competition for Google and the other big tech. Who can we escalate this to?

[peterwilsoncc]

Replying to tomatodysee:

May I ask what made you come to a conclusion about stability?

The name was changed recently, which suggests branding is still sorted out.

35M+ unique visits a month is not enough for a video site? Only a few long standing alternatives can say the same, and this area needs competition for Google and the other big tech.

No, it's not really enough visitors to add the site to the allow list. WordPress needs to be sure a service is going to stick around long term before adding a site to the supported embeds. Adding sites too early increases the risk we will need to remove them later.

Who can we escalate this to?

There's not an escalation procedure. I did discuss your site with another committer/maintainer prior to my earlier reply for a logic check.

As I said earlier, you're welcome to put a plugin in the official repository to see if if it gains traction.