Privacybadger: On "Allow Once" dialog for blocked embeds, display link to embedded content

[keener31]

Apologies if this has been addressed, but I was not able to find a related issue.

My feedback is in the form of a simple feature request. When Privacy Badger blocks embeded content and replaces that content with an "Allow Once" dialog and button, I think it would be both informative AND handy for there to be a clickable link provided below the button that links directly to the embeded content itself, if that link is not obscured. Even if it is, having that information would still be very useful, even if the link itself is not functional as given. I understand that there could be complications in parsing a URL to make it more useful or understandable, so even excepting any type of special handling, just having the exact URL or GET request echoed onto the dialog would still be a big help.

An example of this would be embeded Vimeo videos. By default they trigger the "Allow Once" dialog. For the sake of convenience, it would be very helpful to have the link to that video included in the dialog. While the outcome might not be functionally different, I know that I would prefer to simply click through to Vimeo and watch the video there, rather than to allow the embed.

For other objects, it is simply helpful to have details on what the content in question is, specifically. This can inform whether or not the user wants to allow it, or can give the user the ability to follow up on that content outside of the page they are currently visiting.

--
Great extension, and great work. Thanks for your continued effort.

[ghostwords]

Hello and thanks for the suggestion!

Looks like we should be able to do this at least for some widgets (Vimeo, probably YouTube), as the link to the widget page on the provider's site is either present in the embed HTML (best), or can be inferred based on widget IDs/predictable provider URLs (less good but probably OK).

Other widgets though may not have this information easily accessible, or may only exist in third-party contexts (commenting widgets, probably).

How exactly should we work this link into our UI? Embedded widgets can get very small; it's tricky to add elements to the replacement in a way that works when the replacement is small. Perhaps we could make one of the words in our description text into a link? "Privacy Badger replaced this Vimeo player".

[keener31]

While I am neither a UX designer, nor likely the intended party for the question, I figured I'd at least drop in a suggestion as far as displaying the information in question.

I think a link within the text of the widget, as you've suggested, is a fine solution.

Off the top of my head, without considering the dynamic size of the widget itself, I assumed the necessary information could simply be appended below the text about the button itself. However, in assuming that visual real estate within the widget is extremely limited, my next best idea (and perhaps a more robust choice) would be something to the effect of a small icon (perhaps an "!" or "?" in a circle, or a small "More Info" button) or button that would then overlay a small dialog box with whatever details were deemed relevant. This would allow reasonable amounts of space to display information, but it would hide it all behind a button/link that could be very small, if need be.

Examples:

[vomitHatSteve]

+1. I would very much like to see the info about the blocked iframe too.

I could see how maintaining instructions for reaching the original YT/Soundcloud/whatever page based on ID could be a hassle. Even just including the iframe's url would allow us to follow-up and make an informed choice about the link.

[ghostwords]

The current plan is to make the words "this XXX widget" in "Privacy Badger has replaced this XXX widget" into a no referrer link that points to the embedded frame URL for the widget, but only when we have a frame URL (so, widgets like YouTube, Vimeo, SoundCloud and Spotify, but not Disqus).

For example, the frame URL for the central Vimeo widget on https://landslovsprosjektet.w.uib.no/ is https://player.vimeo.com/video/174123498?title=1&byline=1&portrait=0&fullscreen=1.

We may want to improve on this plan by converting embedded frame URLs to "full" URLs (the canonical URL for the content on the provider's site;https://vimeo.com/174123498 for the example above). To do this, we would keep mappings of how to convert frame URLs to full URLs for each provider. We probably don't need to do this for the initial implementation of this feature.

[wis]

Have you thought about what you could do later in the future, for trackers that use scripts, not iframes, like Disqus?
for Disqus specifically, you can generate the URL for the embedded content like this:
``.js export function produceWidgetURL(pageURL, pageTitle) { var url = new URL("https://disqus.com/embed/comments/"); var { host, origin, pathname, search } = new URL(pageURL); url.searchParams.append("f", host.replaceAll(".", "-")); // host with dots replaced with hyphens url.searchParams.append("t_u",${origin}${pathname}${search}`); // embedding-page URL
url.searchParams.append("t_d", pageTitle);
url.searchParams.append("t_t", pageTitle);
url.searchParams.append("s_o", "default");
url.searchParams.append("base", "default");
return url;
}

then in the content script (socialwidget.js):
``` .js
  var openInNewTabButton, openInNewTabButton_id;
  if (widget['Has Content Widget URL Producer'] === true) {
    var path = chrome.runtime.getURL(`${name}/URL-producer.js`)
    const { produceWidgetURL } = await import(path);
    openInNewTabButton = document.createElement('a'),
      openInNewTabButton_id = _make_id("btn-newtab");
    openInNewTabButton.id = openInNewTabButton_id;
    openInNewTabButton.href = produceWidgetURL(window.location.href, window.document.title);
    openInNewTabButton.target = '_blank';
    openInNewTabButton.rel="noreferrer"
    openInNewTabButton.appendChild(document.createTextNode(TRANSLATIONS.open_in_new_tab));
    widgetDiv.appendChild(openInNewTabButton);
  }

for other script/non-iframe trackers, I think you can reverse engineer how to produce the (what I call) "embedded content's URL" from their scripts, though is that kind of not much different for privacy then running the scripts? of course the tracker doesn't get to run their scripts and set tracking cookies etc. but they know that you visited the page/article where that comments-page/embedded-content is embedded.

[ghostwords]

If I understand you correctly, you suggest to generate a clickable link for Disqus comments by constructing it out of the current page's URL and title, basically reimplementing parts of Disqus' own script. This sounds reasonable for a future improvement.

I suggest we first provide links for widgets like YouTube (and other video/audio players) that are both easier to handle and have already been specifically requested by our users.

[ghostwords]

Direct links to widget content in replacement placeholders have been released as part of the 2020.12.10 update. Please let me know if you have any feedback, either here or in a new issue.