[policy, no patch] Secondary subdomain for viewing oEmbed content is confusing and pointless

As 3. point in proposed resolution also avoid display of duplicate content of your Drupal site is a very critical SEO related issue, when settings this up in a right way.

I've made two edits that I would appreciate comments/feedback on from the community:

1) I propose that ASAP we should remove the existing warning. It has likely wasted 1000s of hours of site builder and developer time trying to follow the instructions, which a very low likelihood of actually providing anyone with any protection at all. It's so complex to do correctly and so lacking in documentation that I doubt even 1% of those who try do it succeed; they might even introduce security bugs by doing it incorrectly.

2) I have expanded the proposed resolution to automatically take care of as many aspects of the solution as possible to give site builders the best possible chance of getting it working.

Feedback on #19:

1) I fully agree removing the warning. I spent hours myself trying to solve that warning without luck.

2) Full fix description sounds reasonable sounds reasonable but I don't know all the nuances of cookie behavior so I can't have a strong opinion.

Discovered this issue while looking into this warning, which I have seen and ignored hundreds of times, in light of Starshot.

After reading through this and ✨ [PP-1] Validate alternate domain for oEmbed iFrame Postponed I totally agree that the warning should be removed given that 1) it's extremely difficult to implement and 2) of dubious value. I understand that it's a recommendation but as it stands this feels like Drupal saying "This is a potential thing that you should maybe worry about, and we can't help you but we told you so now it's on you". In other words, very un-Drupal!

What do we need to do to get a decision on this?

Discussed with @xjm at Drupalcon Barcelona. As this policy needs review, I'm marking this needs review - so far we haven't heard any opposing voices that want to keep this feature, but I will raise this with the rest of the security team and give them chance to comment here.

I propose that ASAP we should remove the existing warning too. +1

+1 too. Please remove it

+1 for removing. Folks that know how to fix it probably don't need the reminder.

The outcome of this issue could make the following one "closed, won't fix".

I discussed this issue with @mcdruid. Some notes from the discussion:

• Injected JavaScript cannot steal session cookies if the httpOnly flag is correctly applied to those cookies which mitigates some possible attacks.
• It is possible to harden iframes with the sandbox attribute, which WordPress apparently does: https://core.trac.wordpress.org/ticket/44400 - however this may break existing embeds in some cases so will require testing.
• Credentialless iframes look like a possible future solution, but they are not yet supported in Firefox or Safari.

We agreed that this could be broken into three issues:

1. Remove the warning message, given the difficulty to implement the suggestion and the lack of documentation on how to actually do it.
2. Experiment with adding the sandbox attribute to the OEmbed iframe
3. If #2 succeeds, remove the alternate domain setting

Was reminded of this today and decided to try to move it along. Updated ✨ Expose a way to suppress oEmbed security warnings Active to be about removing the warning as the first step in #27.

I think this policy issue can be fixed?

Maybe we can convert this issue to a meta ticket holding all suggested child tickets?

Since this is a policy issue, I think it should be marked fixed once the policy is agreed. It should be referenced in the follow up issues.

Created a follow up for the sandbox experimentation.

pameeela → credited lauriii → .

Crediting @lauriii for discussion in person in Singapore.

longwave → credited mcdruid → .

Adding credit for @mcdruid for discussing with me and raising some of the points mentioned in #27.

Automatically closed - issue fixed for 2 weeks with no activity.

Adding credit for myself as per #22. Remember to credit in-person discussions, folks. :)

Changing to latest version when this was closed.