This is an idea following up from this brief exchange about disabling onebox youtube / instagram / etc embeds: Disabling youtube and other embeds
I think it makes sense to expose a user preference to disable onebox and display the original link instead. The onebox embeds offer a lot of value for the general case, but individual users may want to avoid it. The current options are either to disable onebox for the whole forum (per above link) or for individual users to use a browser extension like uBlock Origin to block particular domains or iframes altogether. The extension approach is functional but not practical. It leaves big chunks of empty space where the iframe would usually go, doesn’t give any indication as to what is supposed to be there, and if the user wants to see the content they have to try to find the URL by digging into the source code.
My suggestion is to allow users to opt-out of (or maybe opt-in to) seeing the onebox embeds, and instead have the post include the original link. This would retain a consistent look, better indicate the content of the link, and negate the need to dig through the page source to find the link.
(I’m posting this as a newcomer to the meta forum and without looking at the code, so I don’t know if this is practical, but I thought it would be worth discussing – thanks!)
Thanks for the response. The concerns are privacy and security as well as the things users have in place to address those concerns.
As @hellcx9rv4 mentions, iframes can be a security hole, and as mentioned in article in the linked post, the types of site which frequently serve up embeds (Google, Meta, etc) should be considered untrustworthy, and increasingly are.
It’s reassuring to know that the devs are thinking about this, but concerned users will still be suspicious of the iframes on discourse sites just as they are on other sites, and they will be using the same mechanisms to address their concerns.
For instance, uBlock Origin has 6.4 million Firefox users and 10 million Chrome users according to their respective add-on / extension websites. While iframe blocking is not enabled out-of-the-box and I doubt it’s possible to know how many users have it enabled, these usage numbers indicate that a significant number of web users care about this issue. If the cross section of discourse users and uBO users blocking iframes (or iframe provider domains) is 0.1% of those numbers, that’s still 16,000 affected discourse users.
By your own admission though, said paranoid users are likely to already employ some form of blocking solution at their local machine? Said 16k users already have a solution which works for all websites, instead of specifically discourse?
The solution addresses the iframe by preventing its requests from firing (in the case of uBO at least). When the iframe is blocked, there is either no content or a block of empty space, meaning that a part of the conversation content is missing. The problem is that the iframe is there because discourse has replaced the poster’s link with it, and what I’m suggesting is a mechanism to leave that content “as is” for the interested users. (Something like alt text would also be useful but I don’t think it exists for iframes.)
Maybe, but that’s not the issue. Many people have found that content blockers are their value-effort sweet spot.
Fallback text might actually be a more appropriate approach since it doesn’t require the user preference (and would be transparent in cases where the iframe fails to load for other reasons, eg if the src domain is blocked by the network.). If a good implementation can be found it might also be easier to maintain. An idea for an implementation: display the original URL in the post text, instantiate the onebox iframe detached from the DOM, replace the URL with the iframe once it’s clear the iframe is going to load.
