[wp-trac] [WordPress Trac] #55278: Fix Support for embed.ly with Odysee.com (half working)
WordPress Trac
noreply at wordpress.org
Fri Mar 4 04:56:43 UTC 2022
#55278: Fix Support for embed.ly with Odysee.com (half working)
-------------------------+------------------------------
Reporter: tomatodysee | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Embeds | Version:
Severity: normal | Resolution:
Keywords: has-patch | Focuses: ui
-------------------------+------------------------------
Comment (by tomatodysee):
Replying to [comment:4 peterwilsoncc]:
> The [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
#attr-sandbox 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 https://core.trac.wordpress.org/changeset/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!
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55278#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list